How do I install MCP Gateway?

Copy the stdio config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.

Does MCP Gateway need an API key?

No required environment variable is listed on this record.

What transport does MCP Gateway use?

MCP Gateway runs locally over stdio.

When was MCP Gateway last checked?

Last checked 2026-11-09. Universal MCP gateway with Meta-MCP discovery, routing, and REST API capabilities.

MCP Gateway MCP server

MCP Gateway

One gateway between your AI and every tool it needs, without flooding the context window.

MCP Gateway is a single Rust binary that sits between an AI client and all of its tools. Connect MCP servers and REST APIs behind it, and the agent sees a compact meta-surface of 9 to 17 tools instead of every backend definition. It discovers and calls backend tools on demand. A small live-agent benchmark found no completed-task token saving from that extra hop, so the value is catalog capacity plus policy and routing—not a blanket token claim. See Benchmarks.

demo

Personal and noncommercial use is free, including running the full gateway. Running it commercially needs a commercial license.

The problem this removes

Every MCP tool an AI client connects costs roughly 150 tokens of context overhead, loaded into every request whether the tool gets used or not. Connect 20 servers with 100 tools between them and you spend about 15,000 tokens before the conversation starts. Context limits then force a second cost: you have to decide up front which tools to connect and leave the rest out, so the agent makes worse decisions because it cannot reach data you chose not to load.

MCP Gateway moves the full catalog out of the exposed tool list. The agent loads a small fixed set of meta-tools, searches with gateway_search_tools, and invokes a backend tool with gateway_invoke. This creates room for larger catalogs, but the extra search hop can cost more tokens and time on a completed task.

flowchart LR
    AI["AI client<br/>(Claude, Cursor, ...)"]
    subgraph GW["MCP Gateway (single binary)"]
        META["Compact meta-surface<br/>9-17 tools"]
        DISC{"Discover on demand<br/>gateway_search_tools<br/>gateway_invoke"}
    end
    T1["MCP backend<br/>Tavily (stdio)"]
    T2["MCP backend<br/>Context7 (http)"]
    C1["REST capability<br/>GitHub"]
    C2["REST capability<br/>Stripe"]
    Cn["110+ capabilities"]

    AI -->|"9-17 tool defs"| META
    META --> DISC
    DISC --> T1
    DISC --> T2
    DISC --> C1
    DISC --> C2
    DISC --> Cn

Quick Start

Four commands:

brew trust --tap MikkoParkkola/tap   # Homebrew 6.0+
brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client  # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run
mcp-gateway doctor                           # 4. verify everything is healthy

That is it. Your AI clients now talk to the gateway, and the gateway routes to every backend you already had configured, at a flat 11 tools instead of ~150 — 11 is the default HTTP configuration counted for an administrator; an ordinary client is shown four fewer. Start with gateway_search_tools from your AI client to find any backend tool, then invoke it with gateway_invoke.

Nothing to import yet? mcp-gateway init --with-examples writes a working gateway.yaml with public capabilities so you can confirm the gateway is alive before adding your own servers.

Or tell your AI assistant (recommended):

Read https://github.com/MikkoParkkola/mcp-gateway and install mcp-gateway to consolidate all my MCP servers behind one gateway

Your agent will install the binary, run the setup wizard, import your existing MCP servers, and wire itself up. This works in Claude Code, Cursor, Windsurf, Codex, and any AI with terminal access.

Install

Method	Command
Homebrew (macOS/Linux, recommended)	`brew install MikkoParkkola/tap/mcp-gateway`
Cargo	`cargo install mcp-gateway`
cargo-binstall	`cargo binstall mcp-gateway`
Direct binary download (Windows x64)	Download `mcp-gateway-windows-x86_64.exe` from the latest release
Docker	`docker run -p 127.0.0.1:39400:39400 -e MCP_GATEWAY_SERVER__ALLOW_UNAUTHENTICATED_NETWORK_BIND=true -v $(pwd)/gateway.container.yaml:/config.yaml:ro ghcr.io/mikkoparkkola/mcp-gateway:latest --config /config.yaml --host 0.0.0.0 --port 39400`
Docker, `npx`/`uvx` backends	Same, with `:latest-full` — the default image carries no Node or `uv`, so a stdio backend that shells out to either cannot spawn. See Docker Deployment.

On Linux, the image runs as UID/GID 1001. Make an owner-only deployment copy instead of changing ownership on your working config: install -m 600 gateway.yaml gateway.container.yaml && sudo chown 1001:1001 gateway.container.yaml. Do not make a credential-bearing config world-readable. Docker Desktop handles bind-mount identity differently on macOS and Windows.

# macOS Apple Silicon
curl -L https://github.com/MikkoParkkola/mcp-gateway/releases/latest/download/mcp-gateway-darwin-arm64 -o mcp-gateway && chmod +x mcp-gateway

# macOS Intel
curl -L https://github.com/MikkoParkkola/mcp-gateway/releases/latest/download/mcp-gateway-darwin-x86_64 -o mcp-gateway && chmod +x mcp-gateway

# Linux x86_64
curl -L https://github.com/MikkoParkkola/mcp-gateway/releases/latest/download/mcp-gateway-linux-x86_64 -o mcp-gateway && chmod +x mcp-gateway

# Windows x64 (PowerShell)
Invoke-WebRequest -Uri https://github.com/MikkoParkkola/mcp-gateway/releases/latest/download/mcp-gateway-windows-x86_64.exe -OutFile mcp-gateway.exe

Set up, three ways

Option A: auto-import everything (recommended)

mcp-gateway setup wizard --configure-client

Scans Claude Desktop, Claude Code, Cursor, Zed, Continue.dev, Codex, and running MCP processes; lets you pick which servers to import into gateway.yaml; previews the gateway entry; writes it into each detected client config; verifies the write; and prints backup and rollback paths when an existing client config changes. Add --yes to skip the prompts and import everything.

Option B: add servers from the built-in registry

48 popular MCP servers are pre-registered with the right command, args, and env-var template. mcp-gateway add is compatible with claude mcp add and codex mcp add:

mcp-gateway add tavily                                       # known server, fills env vars
mcp-gateway add my-server -- npx -y @some/mcp-server --flag  # arbitrary stdio command
mcp-gateway add --url https://mcp.sentry.dev/mcp sentry      # HTTP server
mcp-gateway add -e API_KEY=xxx my-server -- npx my-mcp-server

mcp-gateway list shows what is configured. mcp-gateway remove <name> removes one.

Option C: hand-write `gateway.yaml`

For the full schema, see the annotated examples/gateway-full.yaml, which covers env_files, server, auth, meta_mcp, streaming, failsafe, cache, capabilities, and backends. The remaining top-level sections (playbooks, security, webhooks, routing_profiles, code_mode, mtls, key_server, agent_auth, runtime, marketplace, control_plane, cost_governance) have no prose reference yet; the Config struct in src/config/mod.rs is the authoritative list. Minimal example:

server:
  port: 39400

meta_mcp:
  enabled: true

backends:
  tavily:
    # `command` is parsed with host-platform rules: POSIX shlex on unix,
    # CommandLineToArgvW on Windows (so `C:\Windows\py.exe …` keeps its
    # backslashes; quote paths that contain spaces).
    command: "npx -y @anthropic/mcp-server-tavily"
    description: "Web search"
    env:
      TAVILY_API_KEY: "${TAVILY_API_KEY}"

  sentry:
    http_url: "https://mcp.sentry.dev/mcp"
    description: "Sentry issues"

Run and verify

mcp-gateway serve                  # start the gateway
mcp-gateway doctor                 # diagnose config, port, env vars, backend health
mcp-gateway doctor --fix           # auto-fix issues where possible

The web dashboard is at http://localhost:39400/ui once serve is running. The operator dashboard at /dashboard needs the admin credential, and a browser cannot send one on a navigation — so serve prints a single-use link to open it with, on a loopback bind. A network-bound gateway prints none and is managed through /ui with the token instead. See Opening the dashboard.

Connect AI clients (if you skipped Option A)

setup export writes the gateway entry into client config files for you. It auto-detects the right path per client:

mcp-gateway setup export --target all --dry-run       # preview without writing
mcp-gateway setup export --target all                 # write, back up, verify
mcp-gateway setup export --target claude-code         # one client
mcp-gateway setup export --target all --watch         # regenerate on gateway.yaml changes
mcp-gateway setup export --rollback <backup-file>     # restore one client config

Existing client files are backed up before mutation. The command prints the exact rollback command beside each updated client.

Client	Config path
`claude-code`	`~/.claude.json`
`claude-desktop`	platform-specific
`cursor`	`.cursor/mcp.json` (workspace)
`vs-code-copilot`	`.vscode/mcp.json` (workspace)
`windsurf`	`~/.codeium/windsurf/mcp_config.json`
`cline`	`.cline/mcp_servers.json` (workspace)
`zed`	`~/.config/zed/settings.json`

Modes: --mode proxy (HTTP), --mode stdio (subprocess), --mode auto (probe the health endpoint, then fall back).

{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:39400/mcp"
    }
  }
}

Why use MCP Gateway?

Larger catalog, smaller exposed surface. The agent loads a fixed meta-surface instead of every backend definition. In the checked-in live run, both paths completed every task, but the meta path used 1.2–16.1% more input tokens and added one turn. See Benchmarks.
Unlimited tools, discovered on demand. No more choosing which servers fit the budget. The agent searches (gateway_search_tools) and invokes (gateway_invoke) tools as it needs them.
Add any REST API in minutes. Drop in a YAML file or import an OpenAPI spec with mcp-gateway cap import. 110+ capabilities ship built in.
Per-user identity to backends. Multitenant backends can receive the verified end-user identity with no gateway-stored long-lived credential. See Multitenant identity.
Secure by construction. A tool-poisoning validator scans every backend tool description before it reaches the agent. SHA-256 capability pinning is optional: unpinned files load, pinned files fail closed on mismatch. OWASP Agentic AI Top 10 coverage is self-assessed in-tree, not a certification. The crate sets #![deny(unsafe_code)], so any unsafe block needs an explicit #[allow] opt-in, with optional mTLS, message signing, and agent identity.
Swap your MCP stack without losing your session. Hot-reload backends and config in about 8ms while the AI stays connected. No restart, no lost context.
Production resilience. Circuit breakers, retries with backoff, rate limiting, and health checks keep one flaky server from taking down the whole toolchain.
Dual protocol. MCP plus an A2A (agent-to-agent) transport adapter, so the same gateway routes tool calls and cross-provider agent messages.

What MCP Gateway is, and what it is not

MCP Gateway is a tool and capability router. It routes MCP tool, resource, and prompt traffic to backend MCP servers and to capability-backed REST APIs, and it can proxy MCP server-to-client requests like sampling/createMessage, elicitation/create, and roots/list back to the connected client over the existing session.

It is not a chat-completions or embeddings proxy. When a backend asks for sampling/createMessage, the connected client performs the model call, not the gateway. The OpenAI-compatible prompt-cache helpers exist for one narrow reason: so gateway_invoke can preserve prompt_cache_key behavior for backends that call LLM APIs internally. That boundary is deliberate. The value here is routing hundreds of tools through a small surface, not sitting in the model path.

Compared with the default approach of loading every tool definition into every request, the gateway trades a one-time discovery hop for a flat, small context cost. Compared with generic transport bridges that expose one server at a time, it aggregates many backends behind one namespaced surface with integrity checks, ranking, and per-user identity.

Multitenant identity

A multitenant backend (email, memory, calendar) that runs its own OIDC normally sees only "the gateway," so it cannot enforce per-user access or produce a per-user audit trail. mcp-gateway propagates the verified end-user identity to the backend through one of three configured strategies. It can mint a short-lived gateway-signed assertion, forward the caller's own token, or run an RFC 8693 token exchange for OAuth-native backends. It keeps no long-lived credential for anyone. A backend marked required fails closed rather than serve a shared key when no verified identity is present, and per-user results stay isolated in the cache. See ADR-007, ADR-008, and docs/UPGRADING-3.0.md. For the full propagation sequence, each strategy's wiring, the safety invariants, and the 2.x upgrade path, see What is new in v3.1.0: end-user identity to backends.

Independent reviews

Five MCP hot-reload tools compared: Ruach Tov Collective's BPD-based comparison of mcp-gateway against four restart-focused alternatives, with a feature matrix and architectural analysis.
mcp-gateway deep dive: a walkthrough of the capability system, SHA-256 integrity pinning, and the v2.5 to v2.9 development arc.

Quantitative claims in this README are sourced from docs/BENCHMARKS.md and the machine-readable benchmarks/public_claims.json, with a CI check that fails on drift. The public Trust Fabric plan is tracked in docs/roadmap/mik-6550-trust-fabric-roadmap.md.

Why the token math matters

Every MCP tool you connect costs about 150 tokens of context overhead. Connect 20 servers with 100 tools and you have burned roughly 15,000 tokens before the first message, on definitions the AI probably will not use this turn. Worse, context limits force you to choose which tools to connect at all, so the agent makes weaker decisions because the right data is out of reach.

	Without gateway	With gateway
Tools in context	Every definition, every request	11 meta-tools in the README benchmark (~1,100 tokens)
Schema footprint	~15,000 modeled tokens (100 tools)	~1,100 modeled tokens before discovery; not completed-task cost
Measured task cost	Direct path was lower at every tested size	Meta path used 1.2–16.1% more input tokens and one extra turn
Practical tool limit	20 to 50 tools under context pressure	Unlimited, discovered on demand
Connect a new REST API	Build an MCP server (days)	Drop a YAML file or import an OpenAPI spec (minutes)
Changing MCP config	Restart the AI session, lose context	Restart gateway (~8ms), session stays alive
When one tool breaks	Cascading failures	Circuit breakers isolate it

The gateway exposes 9 tools minimum, 11 in the README benchmark scenario, counted for an administrator; a caller without admin standing is shown four fewer. The base discovery quartet stays fixed. Everything else is listed only where it can answer: stats, cost reporting, playbooks and profile control appear once the configuration that backs them exists, and webhook status where a webhook registry is attached, which the stdio transport never has. A deployment that turns all of them on is served 17. It costs context exactly where it is useful.

Code Mode: two tools instead of the meta-tool set

Setting code_mode.enabled: true makes tools/list return exactly two tools, gateway_search and gateway_execute, instead of the meta-tool set. Everything else is reached through those two. Tools named in meta_mcp.surfaced_tools are not appended in this mode, so the count stays at two however many backends are connected. Code Mode is off by default. gateway_search returns L0 by default (tool name, one-line purpose, score). Pass detail=l1 or detail=l2 for more, or explain=true for ranking diagnostics. include_schema=true is deprecated and maps to L2.

code_mode:
  enabled: true

Security

Connecting N MCP servers to an agent means accepting N attack surfaces. Tool poisoning, rug pulls, and exfiltration through hidden instructions in tool descriptions are demonstrated attacks, not hypotheticals. Invariant Labs' writeup (MCP Security Notification: Tool Poisoning Attacks) and Simon Willison's summary (MCP has prompt injection security problems) lay out the threat model.

mcp-gateway puts every backend tool description behind one audit surface and defends it structurally:

Tool-poisoning validator (AX-010). Every backend tool description is scanned before it reaches the agent's context window. HIGH patterns fail closed: <IMPORTANT> blocks, ~/.ssh/~/.aws/id_rsa/.env//etc/passwd, sidenote exfiltration language, curl .* https?://, and base64 in an exfil context. MEDIUM patterns warn: 40+ consecutive spaces, zero-width or bidi-override Unicode, and oversized descriptions. Implementation: src/validator/rules/tool_poisoning.rs (19 tests).
Optional SHA-256 capability hash-pinning. mcp-gateway cap pin <file> writes a sha256: line over the file's canonical hash (grep -v '^sha256:' capability.yaml | sha256sum reproduces it from any shell). Unpinned files still load. A pinned file that no longer matches fails closed on load and on every watcher event.
Rug-pull detection. When a pinned capability's on-disk content changes after approval, the watcher unloads it and logs RUG-PULL DETECTED. The capability stays quarantined until an operator re-pins it. Implementation: src/capability/hash.rs and detect_rug_pulls in src/capability/backend.rs.
Centralized audit surface. Capability YAMLs are plain text: diffable, greppable, and reviewable in a PR. The agent only ever sees the compact meta-surface, so there is no N-server tool-list pollution and no N-server attack surface.

Full walkthrough, PoC snippets, and roadmap: docs/blog/security-aware-mcp-gateway.md.

OWASP Agentic AI Top 10 (self-assessed). Controls are mapped across all 10 ASI risks at the gateway boundary in-tree. That is not a certification. Hardening follow-ups are tracked separately for SBOMs, release signing, live remote attestation discovery, multi-gateway signing, SQL-sink defaults, and collusion detection. See docs/OWASP_AGENTIC_AI_COMPLIANCE.md.

Recent additions

OpenAPI importer. mcp-gateway cap import <spec-url-or-file> turns an OpenAPI 3 spec into one validated capability YAML per operation. The full Swagger Petstore spec becomes 19 validated capability YAMLs end to end:
```
mcp-gateway cap import https://petstore3.swagger.io/api/v3/openapi.json --output capabilities/ --prefix petstore
```
22 tests across src/capability/openapi.rs and tests/openapi_import_tests.rs.

Architecture

flowchart TB
    subgraph GW["MCP Gateway (:39400)"]
        META["Meta-MCP surface: 9-17 tools<br/>gateway_list_servers · gateway_list_tools<br/>gateway_search_tools · gateway_invoke"]
        FS["Failsafes: circuit breaker · retry · rate limit"]
        META --> FS
    end
    FS --> B1["Tavily<br/>(stdio)"]
    FS --> B2["Context7<br/>(http)"]
    FS --> B3["Pieces<br/>(sse)"]
    FS --> B4["REST capabilities<br/>(110+)"]

Single-binary gateway. An AI client talks to the compact meta-surface, and the gateway dynamically discovers and routes to backend tools. Key modules: gateway/ (core router, OAuth, streaming, UI), provider/ (MCP/composite/capability), capability/ (discovery, validation), transport/ (HTTP, stdio), security/ (firewall, mTLS, message signing, agent identity, memory scanner), identity_propagation/, key_server/, cost_accounting/, scheduler/, skills/, tool_profiles/, config_reload/, and a2a/ (A2A transport adapter).

Features

Web dashboard

Embedded web UI at /ui: live status, searchable tools, server health, a read-only control-plane view, and a config viewer. Operator dashboard at /dashboard, which needs the admin credential — on a loopback bind serve prints a single-use link to open it with, since a browser cannot attach an Authorization header to a navigation. Cost tracking at /ui#costs. All served from the same binary and port, with no frontend build step.

Security and governance

Feature	Description	Docs
Authentication	Bearer tokens, API keys, explicit admin keys, per-client rate limits, and opt-in per-client circuit breakers. With auth disabled every caller over HTTP is anonymous and holds no admin; a stdio caller is admin, because the client spawned the process	examples/per-client-tool-scopes.yaml
Cross-site protection	`Origin`, `Host` and `Sec-Fetch-Site` validation refuses web pages reaching the local port. A client that sends no `Origin` is not refused for that, but the `Host` check applies to every request, so a client reaching the gateway by a name it does not answer to is refused whether or not it is a browser	docs/DEPLOYMENT.md
End-user identity propagation	Three configured strategies (`identity_propagation` config): gateway-signed assertion, client-token passthrough, and RFC 8693 token exchange. Fails closed when a backend requires identity. Per-user cache isolation. Enforced on dispatch, Code Mode, and direct routes.	docs/adr/ADR-007-identity-propagation.md
Per-user OAuth isolation	Fail-closed default (v3.0): a backend that requires a per-user OAuth identity refuses a call that lacks one instead of serving a shared stored token. Opt into the previous shared-credential behavior with `auth.single_user: true` (personal gateway) or `oauth.shared_account: true` (a specific backend). Upgrading from 2.x backs up `gateway.yaml` and prints a one-time posture notice; no config changes automatically.	docs/adr/ADR-008-multi-user-oauth-isolation.md, docs/UPGRADING-3.0.md
Cleartext credential refusal	A backend whose configuration is credential-bearing — an section, identity propagation, injected secrets, any static header whatever its name, or userinfo or a query in the URL — over plain to a host off this machine is refused at config load rather than started. Loopback is exempt; on that backend accepts the exposure knowingly

Integration and discovery

The gateway ships with 110+ built-in capabilities: weather, Wikipedia, GitHub, stock quotes, package tracking, and more. Capability YAMLs hot-reload automatically after file changes, no restart needed.

Feature	Description
Capability system	REST API to MCP tool via YAML. Hot-reloaded. 110+ built-in. OpenAPI import supported.
Transform chains	Namespace, filter, rename, and response transforms. Example.
Webhooks	GitHub/Linear/Stripe push events as MCP notifications. Docs.
Auto-discovery	Discover MCP servers from existing client configs and running processes.
Surfaced tools	Pin high-value tools directly in `tools/list` for one-hop invocation.
Semantic search	TF-IDF ranked search across all tool names and descriptions.
Tool profiles	Usage analytics per tool: latency, errors, trends. Persisted to disk.
Config export	Export sanitized config as YAML or JSON via `mcp-gateway config export`.

Protocol and transport

MCP versions: the initialize handshake negotiates up to 2025-11-25. The newer 2026-07-28 revision is reached only on the stateless POST /mcp path, via the MCP-Protocol-Version header; it is served by default and is switched off with server.modern_protocol: false
Transports: stdio, Streamable HTTP, SSE, WebSocket
Hot reload: capability YAMLs and backends are watched and reloaded live. server.public_url and control_plane.role_mapping are re-read per request; everything else needs a restart
Reload outcomes: gateway_reload_config and /ui/api/reload report restart_required, and keep reporting it until a restart, for every field a reload cannot apply — which is every field outside that short live list, auth included. A reload that would leave the tool endpoint reachable without a credential is refused rather than applied
Config discovery: auto-finds gateway.yaml in cwd, ~/.config/mcp-gateway/, and /etc/mcp-gateway/
"Did you mean?": Levenshtein-based typo correction on tool names
Tool annotations: MCP 2025-11-25 title, readOnlyHint, destructiveHint, idempotentHint, openWorldHint; gateway meta-tools are fully annotated, while backend tools use the hybrid pass-through/fill policy in ADR-003
Dynamic descriptions: live tool and server counts in meta-tool descriptions
Tunnel mode: expose via Tailscale or pipenet without opening ports
Shell completions: mcp-gateway completions bash|zsh|fish
Spec preview (opt-in): filtered tools/list (SEP-1821), tools/resolve (SEP-1862), dynamic promotion

Supported backends

Any MCP-compliant server works. All three transport types are supported:

Transport	Examples
stdio	`@anthropic/mcp-server-tavily`, `@modelcontextprotocol/server-filesystem`, `@modelcontextprotocol/server-github`
HTTP	Any Streamable HTTP server
SSE	Pieces, LangChain, GitMCP (free remote docs and code search for any GitHub repo)

Remote MCP servers plug in by URL, with no extra code. See examples/gateway-full.yaml for a commented GitMCP backend entry and docs/REMOTE_BACKENDS.md for a step-by-step walkthrough.

Public MCP Gateway Comparison

This table compares public, user-facing behavior, not internal roadmap scoring. MCP Gateway entries are grounded in this repo's public docs: quickstart, deployment, OWASP controls, TrustCard/CBOM, CatalogTrustLab, adaptive ranking, identity grants, ADR-007 identity propagation, ADR-008 multi-user OAuth isolation, and the Trust Fabric roadmap. Competitor entries are grounded in public project docs: Docker MCP Catalog and Toolkit, MCPJungle README, mcpo README, and Supergateway README.

Axis	MCP Gateway	Docker MCP Gateway / Toolkit	MCPJungle	mcpo / Supergateway
Primary job	MCP and REST capability router with a compact meta-surface	Docker-managed catalog, profiles, containerized MCP servers, and gateway	Self-hosted gateway that runs many MCP servers behind one endpoint	Protocol bridges: MCP to OpenAPI for mcpo; stdio to SSE/WS for Supergateway
Install	Standalone Rust binary via cargo, Homebrew, VS Code, Cursor, and local build	Docker Desktop / Docker CLI plugin flow	Self-hosted gateway install and server registration	Python/uvx/Docker for mcpo; npm/CLI bridge for Supergateway
Configuration	Wizard, local starter profile, service templates, client export, doctor JSON, backup and rollback	Docker profiles and catalog selection	Centralized server and client configuration	Per-bridge command/config for each exposed server or transport
Security	OWASP Agentic AI matrix, firewall, response inspection, hash-pinned capabilities, mTLS/signing options	Verified container images with versioning, provenance, and security updates in Docker catalog	Centralized access control and observability	Transport/API exposure layer; security depends on bridge auth and deployment boundary
Identity and grants	Local identity-grant contract and CLI; multi-user OAuth isolation is credential-agnostic by default (ADR-008), and a backend configured `required` fails closed rather than serve a shared credential; per-user identity propagation to backends via signed assertion, caller-token passthrough, or RFC 8693 token exchange; the OIDC key server is disabled by default, delegated-bearer acceptance is a separate opt-in, and control-plane role mappings are issuer-scoped	Docker/team controls depend on Docker organization setup	Authenticated clients and server access control	Not a grant engine; delegates identity policy to the surrounding deployment

vs Anthropic MCP tunnels

On 2026-05-19 Anthropic shipped Claude Managed Agents with self-hosted sandboxes (public beta) and MCP tunnels (research preview). An MCP tunnel lets a Claude agent reach a single MCP server inside a private network through one outbound connection from a lightweight gateway, with no inbound firewall rules, no public endpoint, and end-to-end encryption.

mcp-gateway and Anthropic's MCP tunnel sit at different layers and compose. The tunnel is reachability plumbing for one private MCP server. mcp-gateway is the aggregation, routing, capability-namespacing, and observability layer across many MCP and REST backends. Deploy both and mcp-gateway becomes the private MCP server that the tunnel exposes: one tunnel, one outbound connection, every backend behind it.

Concern	Anthropic MCP tunnel	mcp-gateway	Boundary
Backend topology	Single MCP server per tunnel, exposed through one outbound connection (overview)	N-backend aggregation: 110+ REST capabilities plus multiple MCP backends behind a compact 9-17 tool meta-surface (`src/gateway/`, `capabilities/*.yaml`)	Different primitive: 1-server reachability vs many-backend aggregation
Tool routing	Opaque pass-through; the agent sees whatever tool list the tunneled server publishes	Capability namespacing plus dynamic `gateway_search_tools` / `gateway_invoke` discovery (`src/gateway/`); SHA-256 pinning per capability (`src/capability/hash.rs`)	Different layer: transport reachability vs tool-surface curation and integrity
Observability	Per-tunnel session telemetry from Anthropic's side	Unified `trace_id` and cost accounting across every backend invocation (`src/cost_accounting/`, `src/gateway/`)	Scope distinction: per-tunnel session vs cross-backend trace correlation

They solve adjacent problems. A team that wants Claude Managed Agents to reach a private-network deployment of mcp-gateway uses the tunnel for reachability and mcp-gateway for fan-out, capability hygiene, OWASP Agentic AI controls, and unified cost and trace telemetry.

API

Endpoint	Method	Description
`/health`	GET	Health check with backend status; authenticated admin callers also see per-backend runtime profile lifecycle state
`/mcp`	POST	Meta-MCP mode (dynamic discovery)
`/mcp/{backend}`	POST	Direct backend access
`/ui`	GET	Web dashboard
`/ui/api/control-plane`	GET	Read-only local control-plane projection for inventory, runtime health, decisions, RBAC, and license boundaries
`/dashboard`	GET	Operator dashboard. Admin only; opened with the single-use link `serve` prints on a loopback bind
`/metrics`	GET	Prometheus metrics (with `--features metrics`)

Performance

Metric	Value	Notes
Startup time	~8ms	Measured with `hyperfine` (benchmarks)
Binary size	~12-13 MB	Release build with LTO, stripped
Hot-path microbenchmarks	Included	Criterion suite covers registry, parsing, cache-key, firewall, and semantic-search hot paths
End-to-end latency	Backend-dependent	Measure with your real MCP servers and REST APIs rather than relying on a synthetic single number

SKILL.md / agentskills.io compatibility

MCP Gateway can ingest Agent Skills and Claude Code SKILL.md files and expose them as discoverable skills alongside capability YAML. This lets the gateway consume any SKILL.md, whether authored locally, shipped from agentskills.io, or pulled from a GitHub release, and surface it through the same meta-tool surface used for capabilities.

# Import a local skill directory (auto-discovers SKILL.md + resources/)
mcp-gateway skills import ~/.claude/skills/gws-gmail-send

# Import a single SKILL.md file
mcp-gateway skills import ./path/to/SKILL.md

# Import from an agentskills.io URL
mcp-gateway skills import https://agentskills.io/skills/my-skill/SKILL.md

# List imported skills
mcp-gateway skills list

# Search by name, description, trigger, or keyword
mcp-gateway skills search "gmail"

# Show the full body (including any embedded code blocks)
mcp-gateway skills show gws-gmail-send

# Remove a skill
mcp-gateway skills remove gws-gmail-send

What gets parsed

YAML frontmatter (name, description, version, effort, allowed-tools, triggers, keywords)
Markdown body, with fenced bash/python/json code blocks extracted as structured SkillCodeBlock entries
Progressive-disclosure resources: SKILL.advanced.md, reference.md, README.md, and any resources/*.md files in the skill directory

Security model (read-only)

Imported skills are stored as data, not executed. Embedded bash or python blocks are parsed and surfaced to users and agents via skills show, but MCP Gateway will never run them automatically. A future release may add opt-in execution gated on per-skill user consent. To run a skill's commands today, copy them from skills show and run them in your own shell.

Registry location: ~/.mcp-gateway/skills.json (override with MCP_GATEWAY_SKILLS_REGISTRY or --registry).

Reference: Anthropic SKILL.md spec and agentskills.io.

Documentation

Document	Contents
Quick Start	Zero to running in 2 minutes
Annotated config example	Commented `gateway.yaml` covering the most-used config sections
OAuth Configuration	OAuth 2.0 setup with Slack and Figma examples
Upgrading to 4.0	Per-issuer OAuth storage, strict `env_files` parsing, protocol floor, and the single-license change
Upgrading to 3.0	Per-user OAuth isolation and identity-propagation upgrade path
Deployment Guide	Docker, systemd, TLS/mTLS, scaling
Multi-User Setup	Key server, policy scopes, per-backend identity propagation
OpenAPI Import	Generate capabilities from OpenAPI specs
Webhooks	Event integration setup
Community Registry	Share and install capabilities
Benchmarks	Performance measurements
Changelog	Release history

Troubleshooting

Backend will not connect? Test the command directly (npx -y @anthropic/mcp-server-tavily), then check gateway logs with --log-level debug.

Circuit breaker open? Ask your MCP client for gateway_list_servers: it reports circuit_breaker per backend and works on the shipped config. The HTTP equivalent, curl -H "Authorization: Bearer $ADMIN_KEY" localhost:39400/health | jq '.backends', additionally needs auth.enabled: true and an admin credential — authentication is off by default, and while it is off every caller is anonymous, so the token is ignored and even a bearer-carrying request sees just {count, all_healthy}. Adjust thresholds in failsafe.circuit_breaker (default: opens after 5 consecutive failures, retries after 30s).

One tool went quiet, then came back on its own about five minutes later? That is the per-capability error budget, not the circuit breaker — separate mechanism, separate keys. A capability whose failure rate crosses error_budget.capability.threshold is disabled on its own, leaving the rest of its backend serving, and re-enables itself on the next call once error_budget.capability.cooldown (default 5 minutes) has elapsed. gateway_list_disabled_capabilities names the ones currently suspended.

A whole backend went offline and stayed offline? The backend-level error budget auto-killed it: its failure rate crossed error_budget.threshold over the sliding window. Unlike a capability, a killed backend does not come back by itself — revive it with gateway_revive_server, and raise the threshold or the window if the kill was premature. gateway_list_servers reports a killed backend as "status": "disabled", which is how you tell an auto-kill apart from an open breaker.

Every key of both budgets is documented inline in examples/gateway-full.yaml under error_budget:. Rate-limited responses (429, RESOURCE_EXHAUSTED) are excluded from both budgets: a throttled backend is a working backend, so throttling alone can neither kill a backend nor disable a capability.

Tools not appearing? Verify the backend is running (gateway_list_servers). Tool lists are cached for 5 minutes.

Versioning and stability

This project follows Semantic Versioning over its product surface: the CLI, and the configuration file format. Changes to either are versioned accordingly — a config key that stops being accepted, or a command that changes behaviour, is a breaking change.

The Rust library API is not part of that surface. Types are pub for modularity and testing, not as a supported embedding API, and they may change in any release. The crate ships a binary; at the time of writing crates.io reports zero reverse dependencies. If you embed the library, pin an exact version (=4.0.0) rather than a caret range.

This is stated explicitly because "removing a pub field" and "breaking a supported API" are only the same thing when the API is supported. Here it is not, and that needs to be published rather than assumed.

Contributing

Fork and branch (git checkout -b feature/your-feature)
Test (cargo test) and lint (cargo fmt && cargo clippy -- -D warnings)
Open a PR against main with a clear description and a CHANGELOG entry

See CONTRIBUTING.md for full details. Look for good first issue or help wanted to get started.

Ecosystem

mcp-gateway is part of a suite of MCP tools:

Tool	Description
mcp-gateway	Universal MCP gateway: a compact 9-17 tool surface replaces 100+ registrations
trvl	AI travel agent, 36 MCP tools for flights, hotels, ground transport
nab	Web content extraction: fetch any URL with cookies and anti-bot bypass
axterminator	macOS GUI automation, 34 MCP tools via the Accessibility API

License

mcp-gateway is licensed under the PolyForm Noncommercial License 1.0.0 (LICENSE-NONCOMMERCIAL). Every first-party file carries a copyright line and an explicit // SPDX-License-Identifier: PolyForm-Noncommercial-1.0.0 header. There is no second license and no allowlist.

What this means:

Personal and noncommercial use is free, including running the whole gateway.
Running the gateway commercially requires a commercial license. This covers the whole project — dispatch, transport, backend management, identity, security, governance — including the generic building blocks that earlier 3.x releases shipped under MIT headers. See COMMERCIAL.md.
Rights granted in earlier releases are not revoked. Versions 3.0.0–3.2.1 were published with MIT package metadata, and v3.3.0 onward in the 3.x line shipped a small MIT core under per-file headers. Those copies stay MIT for their recipients; from v4.0.0 there is no MIT core. See NOTICE.md.

Full model: LICENSES.md.

Credits

Created by Mikko Parkkola. Implements Model Context Protocol versions 2025-11-25 and 2026-07-28; the newer revision is served by default and can be switched off.

Changelog | Releases

Add this server

Host a copy with our keys and logs.

Server facts

Tools

Questions

How do I install MCP Gateway?

Does MCP Gateway need an API key?

What transport does MCP Gateway use?

When was MCP Gateway last checked?

Documentation

MCP Gateway

The problem this removes

Quick Start

Install

Set up, three ways

Option A: auto-import everything (recommended)

Option B: add servers from the built-in registry

Option C: hand-write gateway.yaml

Run and verify

Connect AI clients (if you skipped Option A)

Why use MCP Gateway?

What MCP Gateway is, and what it is not

Multitenant identity

Independent reviews

Why the token math matters

Code Mode: two tools instead of the meta-tool set

Security

Recent additions

Architecture

Features

Web dashboard

Security and governance

Integration and discovery

Protocol and transport

Supported backends

Public MCP Gateway Comparison

vs Anthropic MCP tunnels

API

Performance

SKILL.md / agentskills.io compatibility

Documentation

Troubleshooting

Versioning and stability

Contributing

Ecosystem

License

Credits

Option C: hand-write `gateway.yaml`