mcp-hangar 1.5.1

Production-grade infrastructure for Model Context Protocol

MCP Hangar

Open-source control plane for MCP servers -- lifecycle, governance, and observability for your server fleet.

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 control 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

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/

The 1.5 server refuses to bind a non-loopback interface without auth. For a quick/insecure demo, pass --unsafe-no-auth; for anything real, configure the auth block.

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

• Parallel tool calls -- one hangar_call fans 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.
• Per-tenant tool projection -- front-door mode presents a different executable surface per caller, fail-closed on unknown identity.
• OAuth ingress -- advertise as an RFC 9728 protected resource and challenge external agents for verified tokens.
• Auth & RBAC -- API-key and OIDC/JWT identity with role-based access; bootstrap the first administrator with mcp-hangar auth bootstrap-admin, and every call carries a verified principal into the audit trail.
• Observability built in -- OpenTelemetry traces, Prometheus metrics, structured logs, and an event-sourced audit trail.

Configuring tools:

The per-server tools: key is overloaded and accepts two distinct forms:

• A list of tool schemas is a pre-start visibility projection. It lets a tool be listed before its provider has started, so callers can see it up front. It is not an access policy. On start, the provider's dynamic tools/list is authoritative and replaces this projection entirely — a statically-listed tool that the provider does not return becomes uncallable and fails with Tool not found: <name> at invocation (a warning naming the unconfirmed tool is logged at start).

• A dict with allow: / deny: is an access policy (glob-pattern, three-level merge) that filters which discovered tools are exposed.

mcp_servers:
  math:
    mode: subprocess
    command: [python, -m, examples.provider_math.server]
    tools:                     # list form: pre-start schema projection
      - name: add
        description: "Add two numbers"
        inputSchema: { type: object, properties: { a: { type: number } } }
  github:
    mode: subprocess
    command: [uvx, mcp-server-github]
    tools:                     # dict form: allow/deny access policy
      allow: [create_issue, list_issues]
      deny: [delete_repository]

Documentation

• Getting Started · Configuration · Python API
• Governance & Front Door · Authentication & RBAC · Observability
• Kubernetes operator · Helm charts · All docs

License

MIT