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.
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.
- 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
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.
One command — pip install mcp-hangar