MCP Hangar
The policy enforcement plane for MCP -- deterministic admission and egress policy, attributable audit, and SIEM export for your MCP server fleet. MIT, self-hosted, no SaaS.
Why
In MCP, the tool list is a hint the client caches; the call path is the only surface a provider mediates in real time. Every governance primitive worth having -- revocation, per-tenant scoping, audit -- attaches there, or attaches to nothing. Hangar puts a policy enforcement plane on that seam: one mediated path for lifecycle, policy, and telemetry across your whole MCP server fleet.
Background: The Advisory List -- Why MCP Governance Lives at the Call Path
Install
pip install mcp-hangar
# or: uv pip install mcp-hangar
Upgrading rather than installing fresh? The migration steps live in the upgrade guide.
Quickstart
Point Hangar at an MCP server in config.yaml:
mcp_servers:
github:
mode: subprocess
command: [uvx, mcp-server-github]
env:
GITHUB_TOKEN: ${GITHUB_TOKEN}
Then serve it:
mcp-hangar serve --config config.yaml # stdio (Claude Desktop)
mcp-hangar serve --config config.yaml --http --port 8000 # HTTP + REST API at /api/
Hangar refuses to bind a non-loopback interface without auth. For a quick/insecure demo, pass
--unsafe-no-auth; for anything real, configure theauthblock.
Or skip the config entirely -- get filesystem, fetch, and memory servers wired into Claude Desktop in one line:
curl -sSL https://mcp-hangar.io/install.sh | bash && mcp-hangar init -y && mcp-hangar serve
What you get
The enforcement plane — what the call path actually decides:
- L7 egress policy -- allow/deny in MCP semantics: which upstream, which tool, which arguments. Deterministic, with no anomaly scores and no learned baselines, so every verdict is reproducible from the policy that produced it.
- Tool-schema digest pinning -- an upstream that changes a pinned tool's schema fails closed instead of quietly serving a different tool. Pin for every caller with
tool_projection.pins, or per tenant, which needs authentication so a caller arrives carrying one. - Auth & RBAC -- API-key and OIDC/JWT identity with role-based access and RFC 8707 audience binding; bootstrap the first administrator with
mcp-hangar auth bootstrap-admin, and every call carries a verified principal into the audit trail. - Per-tenant tool projection -- front-door mode presents a different executable surface per caller, fail-closed on unknown identity.
- Human-in-the-loop approvals -- gate a call on an explicit decision, authorized and attributed to a real principal. Delivery channels are pluggable; core ships no vendor integration.
- Governed task relay -- Hangar interposes on the SEP-2663 task lifecycle and never becomes an executor: no scheduler, no job runner, no result store.
- Attributable audit -- an identity-attributed audit record exported to SIEM as CEF, LEEF 2.0, RFC 5424 syslog or JSON-lines, and to OTLP.
Everything else it takes to run a fleet:
- Parallel tool calls -- one
hangar_callfans out to many MCP servers concurrently; all results returned together. - Lifecycle management -- lazy start, health checks, single-flight cold starts, idle shutdown, and per-server circuit breaking.
- Hot config reload -- add or withdraw servers and tools via file watch, no restart.
- OAuth ingress -- advertise as an RFC 9728 protected resource and challenge external agents for verified tokens.
- Observability built in -- OpenTelemetry traces, Prometheus metrics, and structured logs.
One config gotcha: tools: is overloaded
The per-server tools: key accepts two forms that look similar and mean
opposite things:
tools: # LIST -- pre-start visibility projection
- name: add
inputSchema: { type: object, properties: { a: { type: number } } }
tools: # DICT -- access policy
allow: [create_issue, list_issues]
deny: [delete_repository]
The list form only lets a tool be listed before its provider has started.
It is not an access policy, and it does not survive startup: the provider's
dynamic tools/list is authoritative and replaces it entirely, so a
statically-listed tool the provider does not return becomes uncallable and
fails with Tool not found: <name> at invocation.
The dict form is the access policy — glob patterns, three-level merge. Reach for it when you mean to restrict something. Full semantics in the configuration reference.
Documentation
- Getting Started · Configuration · Python API
- Governance & Front Door · Authentication & RBAC · Observability
- Kubernetes operator · Helm charts · All docs
- Release compatibility matrix · which core, operator, and chart versions are released and tested together
MCP Registry
Published in the Official MCP Registry
as io.mcp-hangar/hangar. Clients that consume the registry can install it from
there; the entry describes the PyPI package started over stdio, not a hosted
instance — Hangar is self-hosted only.
License
1 maintainer
Release files for mcp-hangar 2.17.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| mcp_hangar-2.17.1.tar.gz | 2.6 MB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| mcp_hangar-2.17.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 3.8 MB
Release files / mcp_hangar-2.17.1.tar.gz
| Download URL | mcp_hangar-2.17.1.tar.gz |
|---|---|
| Size | 2.6 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
a89d4f621060219936e0374fc5a1087c5eb2abdbd09fc608f1f6ed331064b5c0
|
|
BLAKE2b-256 checksum How to use checksums |
2215fd7f894c8e320fc6d4e9ff78d6fbdb50cbb9274e1eaa86c23956d824cf3c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 2, 2026.
Transparency logRelease files / mcp_hangar-2.17.1-py3-none-any.whl
| Download URL | mcp_hangar-2.17.1-py3-none-any.whl |
|---|---|
| Size | 1.2 MB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
04350ae1a2a8dc021c2c48dd8f5842d7af66559f1c76938b17e548ca17230e0f
|
|
BLAKE2b-256 checksum How to use checksums |
c0736b435b460e65db536e970004346042dd8bd2d92c2855a4e4175aaa867747
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 2, 2026.
Transparency log
