LabscoMCP early access ↗
mcp-hangarMCP SERVER · OFFICIAL PROJECT

Hangar MCP

Put every MCP server your agents use behind one mediated call path, with allow/deny policy and an attributed audit record on each call.

by mcp-hangar ↗Agent Guardrails, Content Safety & Audit✓ Official

LABSCO SUMMARY

The call path is the only surface a provider mediates in real time, and this sits on it.

A client caches the tool list, so anything decided at listing time is advisory — revocation, per-tenant scoping and audit only bind if they attach to the call itself. Hangar mediates that seam for a whole fleet: deterministic allow and deny down to the argument, a verified principal on every audit record, and schema pins that fail closed when an upstream changes underneath you.

What it is

A policy enforcement plane for a fleet of MCP servers. Agents connect to Hangar; Hangar starts, health-checks and calls the upstream servers, applies egress policy on the way through, and writes an identity-attributed audit record for every call. Self-hosted, MIT, no SaaS.

What you get

  • Allow and deny expressed in MCP terms — which upstream, which tool, which arguments — decided deterministically, with no anomaly scores and no learned baselines, so a verdict can be reproduced from the policy that produced it
  • Schema pinning that fails closed: an upstream that changes a pinned tool's schema stops serving instead of quietly serving something else, via tool_projection.pins
  • API-key and OIDC/JWT identity with role-based access and RFC 8707 audience binding, bootstrapped by mcp-hangar auth bootstrap-admin
  • A different executable surface per tenant, fail-closed on an identity it does not recognise
  • Human approvals that gate a call on an explicit decision attributed to a real principal
  • Audit exported to SIEM as CEF, LEEF 2.0, RFC 5424 syslog or JSON-lines, and to OTLP
  • Fleet mechanics: hangar_call fans one request out to many servers concurrently, hangar_load pulls a server from the official registry at runtime, hangar_warm pre-starts them, hangar_health and hangar_metrics report on them
  • Lazy start, health checks, single-flight cold starts, idle shutdown and per-server circuit breaking, plus hot config reload from a file watch

Requirements

Self-hosted with no account and no key: pip install mcp-hangar, then mcp-hangar serve --config config.yaml for stdio, or add --http --port 8000 for HTTP with a REST API at /api/. MCP_CONFIG points at the config.yaml declaring your upstream servers and policy — without it Hangar starts on a demo config that serves no real upstream. It refuses to bind a non-loopback interface unless the auth block is configured. One trap in that config file: the per-server tools: key means two different things. A list is a pre-start visibility projection that the provider's own tools/list replaces entirely at startup; only the dict form with allow: and deny: is an access policy.

Setup effort

One command — pip install mcp-hangar