USP
Eliminates the context window bottleneck by abstracting hundreds of tools into a compact Meta-MCP surface, saving up to 89% tokens and enabling unlimited tool access. Features dynamic configuration, easy REST API integration, and advanced…
Use cases
- 01Connecting numerous MCP servers without exceeding context window limits.
- 02Integrating external REST APIs as AI tools quickly and efficiently.
- 03Securing AI agent interactions against tool poisoning and data exfiltration.
- 04Dynamically managing and updating AI tool configurations without session restarts.
- 05Reducing LLM operational costs by minimizing token usage for tool definitions.
Detected files (1)
CLAUDE.mdclaude_mdShow content (13595 bytes)
<!-- gitnexus:start --> # GitNexus — Code Intelligence This project is indexed by GitNexus as **mcp-gateway** (11486 symbols, 27961 relationships, 300 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely. > If any GitNexus tool warns the index is stale, run `npx gitnexus analyze` in terminal first. **Bet Responsibility**: mcp-gateway owns Bet 4 — shared platform primitives for integrations, tool routing, hooks, policy, and gateway-mediated capability reuse. ## Always Do - **MUST run impact analysis before editing any symbol.** Before modifying a function, class, or method, run `gitnexus_impact({target: "symbolName", direction: "upstream"})` and report the blast radius (direct callers, affected processes, risk level) to the user. - **MUST run `gitnexus_detect_changes()` before committing** to verify your changes only affect expected symbols and execution flows. - **MUST warn the user** if impact analysis returns HIGH or CRITICAL risk before proceeding with edits. - When exploring unfamiliar code, use `gitnexus_query({query: "concept"})` to find execution flows instead of grepping. It returns process-grouped results ranked by relevance. - When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use `gitnexus_context({name: "symbolName"})`. ## When Debugging 1. `gitnexus_query({query: "<error or symptom>"})` — find execution flows related to the issue 2. `gitnexus_context({name: "<suspect function>"})` — see all callers, callees, and process participation 3. `READ gitnexus://repo/mcp-gateway/process/{processName}` — trace the full execution flow step by step 4. For regressions: `gitnexus_detect_changes({scope: "compare", base_ref: "main"})` — see what your branch changed ## When Refactoring - **Renaming**: MUST use `gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true})` first. Review the preview — graph edits are safe, text_search edits need manual review. Then run with `dry_run: false`. - **Extracting/Splitting**: MUST run `gitnexus_context({name: "target"})` to see all incoming/outgoing refs, then `gitnexus_impact({target: "target", direction: "upstream"})` to find all external callers before moving code. - After any refactor: run `gitnexus_detect_changes({scope: "all"})` to verify only expected files changed. ## Never Do - NEVER edit a function, class, or method without first running `gitnexus_impact` on it. - NEVER ignore HIGH or CRITICAL risk warnings from impact analysis. - NEVER rename symbols with find-and-replace — use `gitnexus_rename` which understands the call graph. - NEVER commit changes without running `gitnexus_detect_changes()` to check affected scope. ## Tools Quick Reference | Tool | When to use | Command | |------|-------------|---------| | `query` | Find code by concept | `gitnexus_query({query: "auth validation"})` | | `context` | 360-degree view of one symbol | `gitnexus_context({name: "validateUser"})` | | `impact` | Blast radius before editing | `gitnexus_impact({target: "X", direction: "upstream"})` | | `detect_changes` | Pre-commit scope check | `gitnexus_detect_changes({scope: "staged"})` | | `rename` | Safe multi-file rename | `gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true})` | | `cypher` | Custom graph queries | `gitnexus_cypher({query: "MATCH ..."})` | ## Impact Risk Levels | Depth | Meaning | Action | |-------|---------|--------| | d=1 | WILL BREAK — direct callers/importers | MUST update these | | d=2 | LIKELY AFFECTED — indirect deps | Should test | | d=3 | MAY NEED TESTING — transitive | Test if critical path | ## Resources | Resource | Use for | |----------|---------| | `gitnexus://repo/mcp-gateway/context` | Codebase overview, check index freshness | | `gitnexus://repo/mcp-gateway/clusters` | All functional areas | | `gitnexus://repo/mcp-gateway/processes` | All execution flows | | `gitnexus://repo/mcp-gateway/process/{name}` | Step-by-step execution trace | ## Self-Check Before Finishing Before completing any code modification task, verify: 1. `gitnexus_impact` was run for all modified symbols 2. No HIGH/CRITICAL risk warnings were ignored 3. `gitnexus_detect_changes()` confirms changes match expected scope 4. All d=1 (WILL BREAK) dependents were updated ## Keeping the Index Fresh After committing code changes, the GitNexus index becomes stale. Re-run analyze to update it: ```bash npx gitnexus analyze ``` If the index previously included embeddings, preserve them by adding `--embeddings`: ```bash npx gitnexus analyze --embeddings ``` To check whether embeddings exist, inspect `.gitnexus/meta.json` — the `stats.embeddings` field shows the count (0 means no embeddings). **Running analyze without `--embeddings` will delete any previously generated embeddings.** > Claude Code users: A PostToolUse hook handles this automatically after `git commit` and `git merge`. ## CLI | Task | Read this skill file | |------|---------------------| | Understand architecture / "How does X work?" | `.claude/skills/gitnexus/gitnexus-exploring/SKILL.md` | | Blast radius / "What breaks if I change X?" | `.claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md` | | Trace bugs / "Why is X failing?" | `.claude/skills/gitnexus/gitnexus-debugging/SKILL.md` | | Rename / extract / split / refactor | `.claude/skills/gitnexus/gitnexus-refactoring/SKILL.md` | | Tools, resources, schema reference | `.claude/skills/gitnexus/gitnexus-guide/SKILL.md` | | Index, status, clean, wiki CLI commands | `.claude/skills/gitnexus/gitnexus-cli/SKILL.md` | <!-- gitnexus:end --> # mcp-gateway Universal MCP Gateway | Rust 1.88+ | Edition 2024 | ~101K LOC | MIT ## Product Vision mcp-gateway sits between any AI client and any set of MCP tools. Instead of loading hundreds of tool definitions into every request, the AI sees a compact **Meta-MCP surface** — 14 tools minimum, 16 in the README benchmark, 17 when webhook status is surfaced — and discovers the right backend tool on demand. This cuts ~89% of context-token overhead on a 100-tool stack, removes the "pick which tools to connect" tradeoff, and makes `Unlimited` a practical answer to `how many tools`. The gateway is a **tool + capability router**, not a general chat-completions / embeddings gateway. When a backend asks for `sampling/createMessage`, the connected client still performs the model call. OpenAI-compatible prompt-cache helpers exist only so `gateway_invoke` can preserve `prompt_cache_key` behavior for backends that call LLM APIs internally. **Dual-protocol**: MCP + A2A transport adapter. **OWASP Agentic AI Top 10**: 10/10 covered. **Safety posture**: `#![deny(unsafe_code)]`, SHA-256 integrity pinning on every capability, mTLS option, message signing, agent identity. ## Current Status - **v2.10.0** · Rust 1.88+ · Edition 2024 · ~101K LOC · MIT - Published on crates.io + Homebrew + Glama + VS Code + Cursor one-click install - **Meta-MCP surface**: 14-16 tools in production scenarios (README benchmark scenario) - **Capability backends**: 110+ REST capabilities + MCP backends routed via the same surface - **Security**: unsafe forbidden; dependency-status badge; OWASP Agentic AI 10/10 docs at `docs/OWASP_AGENTIC_AI_COMPLIANCE.md` - **Benchmarks**: machine-readable claims in `benchmarks/public_claims.json` with CI drift check - **Independent reviews**: Ruach Tov Collective's five-tool comparison + mcp-gateway deep dive (linked in README) ## Plan Forward (near-term, technical) - **Cross-provider agent-bus** (MIK-2970) — shipped in #145; continue raw-POST body support - **Capability breadth** — HeyGen connector just landed; pattern established for new REST providers - **MCP 2025-11-25 annotation policy** — see MIK-2985: decide pass-through vs override for downstream annotations; ensure gateway meta-tools (`gateway_execute`, `gateway_search_tools`, `gateway_list_tools`) always carry full hints - **Clippy drift** — Rust 1.95 landed (#149); keep lint baseline green - **Dependabot cadence** — high-volume automated PRs; rebase-and-ship once CI is green ## Decisions Locked (do not re-litigate) | Decision | Rationale | Do not | |---|---|---| | **Meta-MCP surface is compact** (14-16 tools target) | Context-token savings are the entire value proposition | Add meta-tools that could be dynamic-discovery tools | | **mcp-gateway is NOT a chat / embeddings gateway** | Scope boundary; model calls stay with the connected client | Add OpenAI chat-completion proxying as a first-class feature | | **`#![deny(unsafe_code)]`** | Gateway sits on the trust path for every tool call | Introduce unsafe to chase performance | | **SHA-256 integrity pinning on every capability** | Supply-chain safety; capability tampering must be detectable | Load capabilities without hash verification | | **OWASP Agentic AI Top 10 compliance** | Security posture is a shipped differentiator | Regress a covered control without an ADR | | **Dual MCP + A2A transport** | Cross-provider agent messaging (#145, MIK-2970) | Treat A2A as an afterthought; avoid compiling it out of default builds | | **Capability definitions public (mcp-gateway) / private (mcp-gateway-private)** | Public catalog for community; private API credentials / deploy configs | Mix private capabilities into the public catalog | | **`cargo clippy --all-targets -- -D warnings` + `cargo fmt --check`** gates | Zero-debt discipline in Rust source | Ship code with lints suppressed ad hoc | | **Mixed per-file licensing: MIT core + PolyForm Noncommercial 1.0.0 EE** | Core gateway stays MIT for adoption; security firewall, agent-identity, data-flow, message-signing, policy, response-inspect/scanner, scope-collision, tool-integrity, cost-accounting, key-server, and transparency-log paths require commercial terms for commercial use (see [LICENSE-EE.md](LICENSE-EE.md), v2.11.0+) | Collapse package metadata back to plain MIT | ## Anti-Patterns (things agents get wrong in this repo) - **Bloating the Meta-MCP surface** — every new meta-tool eats the context-savings story. Default to dynamic discovery; add a meta-tool only if the user-visible workflow demands it. - **Treating the gateway like an OpenAI proxy** — it is not. Model calls go to the connected client via `sampling/createMessage`. The prompt-cache helpers are a compatibility shim, not a product surface. - **Skipping SHA-256 integrity pinning on a new capability** — the capability system depends on hash verification end-to-end. - **Adding `unsafe` without an ADR** — the `forbid(unsafe_code)` gate is deliberate; any exception needs `docs/architecture/` justification. - **Duplicating MIK-2985 annotation policy work across mcp-gateway and mcp-gateway-private** — resolve the pass-through vs override decision once in an ADR and apply to both. - **Ignoring `benchmarks/public_claims.json` drift** — the CI check is there because README numerical claims have drifted before. ## Guidance for Agents - **Before editing core router**: check `gitnexus_impact` (see section below) to understand the blast radius. - **When adding a capability**: mirror existing `capabilities/*.yaml` pattern; add SHA-256 hash; update `capabilities/README` if the inventory is indexed. - **When changing the Meta-MCP tool surface**: update README, `benchmarks/public_claims.json`, and the tool-count in all badges in one PR (known drift source). - **Security-sensitive changes**: re-run OWASP Agentic AI checklist in `docs/OWASP_AGENTIC_AI_COMPLIANCE.md`. - **Dependabot PRs**: rebase-and-ship once green; do not batch-block them. ## Where to Look | You want to… | Read | |---|---| | Onboard a human user | `README.md` | | Meta-MCP tool surface | `src/gateway/` | | Capability definitions | `capabilities/*.yaml` | | Security / firewall | `src/security/` | | A2A transport | `src/a2a/` | | Benchmarks + claims | `docs/BENCHMARKS.md` + `benchmarks/public_claims.json` | | OWASP compliance | `docs/OWASP_AGENTIC_AI_COMPLIANCE.md` | | Upgrade migrations | `commands/upgrade/` | ## Build & Test ```bash cargo build # debug build cargo build --release # release build cargo test --quiet # all tests cargo test --quiet -- test_name # single test cargo clippy --all-targets -- -D warnings # lint (must pass clean) cargo fmt --check # format check cargo fmt # auto-format ``` ## Architecture Single-binary gateway: AI client -> compact Meta-MCP surface (13-16 tools) -> dynamic discovery of 500+ backend tools. ~90% token savings by not loading all tool definitions into every request. OWASP Agentic AI Top 10: 10/10 covered. MCP + A2A dual-protocol. 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), `cost_accounting/`, `scheduler/`, `skills/`, `tool_profiles/`, `config_reload/`, `a2a/` (A2A transport adapter), `commands/upgrade` (post-upgrade migration framework). ## Features (Cargo) `default`, `a2a`, `config-export`, `cost-governance`, `discovery`, `firewall`, `metrics`, `semantic-search`, `spec-preview`, `tool-profiles`, `webui` ## Quality Gates - `cargo clippy --all-targets -- -D warnings` must be zero warnings - `cargo fmt --check` must be clean - `cargo test --quiet` must pass - No `unsafe` code (`#![deny(unsafe_code)]`) - 0 TODO/FIXME in Rust source
README
MCP Gateway
Give your AI access to every tool it needs -- without burning your context window or building MCP servers.

Independent Reviews
- Five MCP hot-reload tools compared -- Ruach Tov Collective's BPD-based comparison of mcp-gateway against four restart-focused alternatives. Includes a feature matrix and architectural analysis.
- mcp-gateway deep dive -- Detailed walkthrough of the capability system, SHA-256 integrity pinning, and the v2.5-to-v2.9 development arc.
MCP Gateway sits between your AI client and your tools. Instead of loading hundreds of tool definitions into every request, the AI gets a compact Meta-MCP surface -- 14 tools minimum, 16 in the README benchmark scenario, 17 when webhook status is surfaced -- and discovers the right backend tool on demand.
Public quantitative claims in this README are sourced from docs/BENCHMARKS.md and the machine-readable benchmarks/public_claims.json, with CI checks to catch drift.
What MCP Gateway is / is not
MCP Gateway is a tool and capability gateway. It routes MCP tool/resource/prompt traffic to backend MCP servers and 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 gateway session.
MCP Gateway is not a general OpenAI/Anthropic chat completions or embeddings gateway. When a backend asks for sampling/createMessage, the connected client still performs the model call. The OpenAI-compatible prompt-cache helpers in the gateway exist only so gateway_invoke can preserve prompt_cache_key behavior for backends or capabilities that happen to call LLM APIs internally.
Why
The context window is the bottleneck. Every MCP tool you connect costs ~150 tokens of context overhead. Connect 20 servers with 100+ tools and you've burned 15,000 tokens before the conversation starts -- on tool definitions the AI probably won't use this turn.
Worse: context limits force you to choose which tools to connect. You leave tools out because they don't fit -- and your AI makes worse decisions because it can't reach the right data.
MCP Gateway removes that tradeoff entirely.
| Without Gateway | With Gateway | |
|---|---|---|
| Tools in context | Every definition, every request | 16 Meta-MCP tools in the README benchmark (~1600 tokens) |
| Token overhead | ~15,000 tokens (100 tools) | ~1600 tokens -- 89% savings |
| Cost at scale | ~$0.22/request (Opus input) | ~$0.024/request -- $201 saved per 1K |
| Practical tool limit | 20-50 tools (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 AI session, lose context | Restart gateway (~8ms), session stays alive |
| When one tool breaks | Cascading failures | Circuit breakers isolate it |
The base discovery quartet (gateway_list_servers, gateway_list_tools, gateway_search_tools, gateway_invoke) stays constant. The README benchmark scenario also surfaces stats, cost report, playbooks, profile controls, disabled-capability visibility, and reload for a 15-tool surface. Surfacing webhook status adds the 16th tool.
Why not...
| Alternative | What it does | Why MCP Gateway is different |
|---|---|---|
| Direct MCP connections | Each server connected individually | Every tool definition loaded every request. 100 tools = 15K tokens burned. Gateway: a small fixed 13-16 tool surface instead of every backend tool. |
| Claude's ToolSearch | Built-in deferred tool loading | Only works with tools already configured. Gateway adds unlimited backends + REST APIs without MCP servers. |
| Archestra | Cloud-hosted MCP registry | Requires cloud account, sends data to third party. Gateway is local-only, zero external dependencies. |
| Kong / Portkey | General API gateways | Not MCP-aware. No meta-tool discovery, no tool search, no capability YAML system. |
| Building fewer MCP servers | Reduce tool count manually | You lose capabilities. Gateway lets you keep everything and pay the token cost of the compact Meta-MCP surface. |
Security
Connecting N MCP servers to an agent means accepting N attack surfaces. Tool poisoning, rug pulls, and exfiltration via 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,sidenoteexfiltration language,curl .* https?://,base64in exfil context. MEDIUM patterns warn: 40+ consecutive spaces, zero-width / bidi-override Unicode, oversized descriptions. Implementation:src/validator/rules/tool_poisoning.rs(19 tests). - SHA-256 capability hash-pinning.
mcp-gateway cap pin <file>writes asha256:line over the file's canonical hash (grep -v '^sha256:' capability.yaml | sha256sumis reproducible from any shell). The loader refuses any mismatched file 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. Implementation:src/capability/hash.rsanddetect_rug_pullsinsrc/capability/backend.rs. - Centralized audit surface. Capability YAMLs are plain text, diffable, grep-able, PR-reviewable. The agent only ever sees the compact Meta-MCP surface (13-16 tools). No N-server tool-list pollution means no N-server attack surface.
Full walkthrough, PoC snippets, and roadmap: docs/blog/security-aware-mcp-gateway.md.
- OWASP Agentic AI Top 10. Controls are mapped across all 10 risks, with explicitly tracked partial/out-of-scope gaps for multi-gateway signing, tool-result sandboxing, collusion detection, and remote-server provenance. 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:
22 tests acrossmcp-gateway cap import https://petstore3.swagger.io/api/v3/openapi.json --output capabilities/ --prefix petstoresrc/capability/openapi.rsandtests/openapi_import_tests.rs.
Quick Start
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. Works in Claude Code, Cursor, Windsurf, Codex, and any AI with terminal access.
Or four commands:
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's it. Your AI clients now talk to the gateway and the gateway routes to every backend you already had configured — at a flat ~15 tools instead of ~150. 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-exampleswrites a workinggateway.yamlwith public capabilities so you can confirm the gateway is alive before adding your own servers.
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 -v $(pwd)/gateway.yaml:/config.yaml ghcr.io/mikkoparkkola/mcp-gateway:latest --config /config.yaml |
Direct binary download
# 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; and writes the gateway entry back into each detected client config so they route through the gateway instead. 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 claude mcp add / codex mcp add compatible:
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's configured. mcp-gateway remove <name> removes one.
Option C — Hand-write gateway.yaml
For the full schema reference, see docs/QUICKSTART.md#configuration. Minimal example:
server:
port: 39400
meta_mcp:
enabled: true
backends:
tavily:
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.
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 # all detected clients
mcp-gateway setup export --target claude-code # one client
mcp-gateway setup export --target all --dry-run # preview without writing
mcp-gateway setup export --target all --watch # regenerate on gateway.yaml changes
| 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 health endpoint, fall back).
Manual JSON snippet (if you prefer to edit by hand)
{
"mcpServers": {
"gateway": {
"type": "http",
"url": "http://localhost:39400/mcp"
}
}
}
Key Benefits
1. Unlimited Tools, Minimal Tokens
The gateway exposes 14 Meta-MCP tools minimum, 16 in the README benchmark scenario, and 17 when webhook status is surfaced. The base discovery quartet stays fixed; the rest are operator helpers for stats, cost, playbooks, profile control, disabled-capability visibility, reload, and webhook status.
Token math (Claude Opus @ $15/M input tokens, reproducible via python benchmarks/token_savings.py --scenario readme):
- Without: 100 tools x 150 tokens x 1,000 requests = 15M tokens = $225
- With (README benchmark): 16 Meta-MCP tools x 100 tokens x 1,000 requests = 1.6M tokens = $24.00
2. Any REST API to MCP Tool -- No Code
Turn any REST API into a tool by dropping a YAML file (~30 seconds) or importing an OpenAPI spec:
mcp-gateway cap import stripe-openapi.yaml --output capabilities/ --prefix stripe
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.
HeyGen video connector
mcp-gateway now ships HeyGen video-generation capabilities in capabilities/media/:
video_agent_createvideo_createvideo_getvideo_downloadvoice_listavatar_list
Setup:
export HEYGEN_API_KEY=your-api-key
Make sure your config loads the built-in capability directory:
capabilities:
enabled: true
directories:
- ./capabilities
The request schemas ship hand-written for the initial connector, but HeyGen's CLI can act as the schema source of truth for future regeneration:
heygen video-agent create --request-schema
heygen video create --request-schema
Map that JSON into each capability's schema.input block when refreshing the connector.
Example end-to-end workflow:
# 1. Create the video with the Video Agent
CREATE=$(curl -s http://127.0.0.1:39401/mcp \
-H 'Content-Type: application/json' \
-d '{
"jsonrpc":"2.0",
"id":1,
"method":"tools/call",
"params":{
"name":"gateway_invoke",
"arguments":{
"backend":"capabilities",
"tool":"video_agent_create",
"args":{"prompt":"A presenter explaining our product launch in 30 seconds"}
}
}
}')
VIDEO_ID=$(printf '%s' "$CREATE" | jq -r '.result.content[0].text | fromjson | (.data.video_id // .video_id)')
# 2. Poll until completed and fetch the downloadable URL
VIDEO_URL=$(while true; do
BODY=$(curl -s http://127.0.0.1:39401/mcp \
-H 'Content-Type: application/json' \
-d "{
\"jsonrpc\":\"2.0\",
\"id\":1,
\"method\":\"tools/call\",
\"params\":{
\"name\":\"gateway_invoke\",
\"arguments\":{
\"backend\":\"capabilities\",
\"tool\":\"video_get\",
\"args\":{\"video_id\":\"$VIDEO_ID\"}
}
}
}")
STATUS=$(printf '%s' "$BODY" | jq -r '.result.content[0].text | fromjson | (.data.status // .status)')
if [ "$STATUS" = "completed" ]; then
printf '%s' "$BODY" | jq -r '.result.content[0].text | fromjson | (.data.video_url // .video_url)'
break
fi
sleep 5
done)
# 3. Download and save a local MP4
curl -s http://127.0.0.1:39401/mcp \
-H 'Content-Type: application/json' \
-d "{
\"jsonrpc\":\"2.0\",
\"id\":1,
\"method\":\"tools/call\",
\"params\":{
\"name\":\"gateway_invoke\",
\"arguments\":{
\"backend\":\"capabilities\",
\"tool\":\"video_download\",
\"args\":{\"video_url\":\"$VIDEO_URL\"}
}
}
}" \
| jq -r '.result.content[0].text | fromjson | .data' \
| base64 --decode > heygen-explainer.mp4
3. Change Your MCP Stack Without Losing Your AI Session
Your AI connects once to localhost:39400. Behind it, capability YAMLs plus reloadable gateway config sections (including backend add/remove/update and routing/profile changes) can reload live via file watching, gateway_reload_config, or POST /ui/api/reload. Listener address changes report restart_required; env_files list changes stay startup-only and take effect after restart. Your AI session stays connected.
4. Production Resilience
Circuit breakers, retry with backoff, rate limiting, health checks, graceful shutdown, and concurrency limits. One flaky server won't take down your toolchain.
Architecture
┌───────────────────────────────────────────────────────────────┐
│ MCP Gateway (:39400) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Meta-MCP: 13-16 Tools + Surfaced Tools │ │
│ │ • gateway_list_servers • gateway_search_tools │ │
│ │ • gateway_list_tools • gateway_invoke │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Failsafes: Circuit Breaker │ Retry │ Rate Limit │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────┼──────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Tavily │ │ Context7 │ │ Pieces │ │
│ │ (stdio) │ │ (http) │ │ (sse) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└───────────────────────────────────────────────────────────────┘
Features
Web Dashboard
Embedded web UI at /ui -- live status, searchable tools, server health, config viewer. Operator dashboard at /dashboard. Cost tracking at /ui#costs. All served from the same binary and port, no frontend build step.
Security & Governance
| Feature | Description | Docs |
|---|---|---|
| Authentication | Bearer tokens, API keys, explicit admin keys, per-client rate limits and opt-in per-client circuit breakers | examples/per-client-tool-scopes.yaml |
| Per-Client Tool Scopes | Allowlist/denylist tools per API key with glob patterns | examples/per-client-tool-scopes.yaml |
| Security Firewall | Credential redaction, prompt injection detection, shell/SQL/path traversal scanning | CHANGELOG |
| Cost Governance | Per-tool, per-key, daily budgets with alert thresholds (log/notify/block) | CHANGELOG |
| Session Sandboxing | Per-session call limits, duration caps, backend restrictions | CHANGELOG |
| mTLS | Certificate-based auth for tool execution | CHANGELOG |
Integration & Discovery
| 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/JSON. mcp-gateway config export |
Protocol & Transport
- MCP Version: 2025-11-25 (latest spec)
- Transports: stdio, Streamable HTTP, SSE, WebSocket
- Hot Reload: Capability YAMLs plus reloadable gateway config sections are watched and reloaded live
- Reload Outcomes:
gateway_reload_configand/ui/api/reloadreturnrestart_requiredfor listener changes (for exampleserver.host/server.port);env_fileslist edits remain startup-only - Config Discovery: Auto-finds
gateway.yamlin cwd,~/.config/mcp-gateway/,/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/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 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+code search for any GitHub repo) |
Remote MCP servers plug in by URL — 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.
API
| Endpoint | Method | Description |
|---|---|---|
/health | GET | Health check with backend status |
/mcp | POST | Meta-MCP mode (dynamic discovery) |
/mcp/{backend} | POST | Direct backend access |
/ui | GET | Web dashboard |
/dashboard | GET | Operator dashboard |
/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 / 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/jsoncode blocks extracted as structuredSkillCodeBlockentries - Progressive-disclosure resources:
SKILL.advanced.md,reference.md,README.md, and anyresources/*.mdfiles 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/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. If you need 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 · agentskills.io
Documentation
| Document | Contents |
|---|---|
| Quick Start | Zero to running in 2 minutes |
| Configuration Reference | All config options |
| OAuth Configuration | OAuth 2.0 setup with Slack and Figma examples |
| Deployment Guide | Docker, systemd, TLS/mTLS, scaling |
| OpenAPI Import | Generate capabilities from OpenAPI specs |
| Webhooks | Event integration setup |
| Community Registry | Share and install capabilities |
| Benchmarks | Performance measurements |
| Changelog | Release history |
| OWASP Agentic AI Compliance | Risk coverage matrix |
Troubleshooting
Backend won't connect? Test the command directly (npx -y @anthropic/mcp-server-tavily), then check gateway logs with --log-level debug.
Circuit breaker open? Check curl localhost:39400/health | jq '.backends'. Adjust thresholds in failsafe.circuit_breaker.
Tools not appearing? Verify the backend is running (gateway_list_servers). Tool lists are cached for 5 minutes.
Contributing
- Fork and branch (
git checkout -b feature/your-feature) - Test (
cargo test) and lint (cargo fmt && cargo clippy -- -D warnings) - PR against
mainwith a clear description and 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 — compact 13-16 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 + anti-bot bypass |
| axterminator | macOS GUI automation — 34 MCP tools via Accessibility API |
License
mcp-gateway is dual-licensed as of v2.11.0:
| Scope | License | File |
|---|---|---|
| Core gateway, capabilities, transport, CLI, and everything not listed below | MIT | LICENSE |
| Designated Enterprise Edition modules (see below) | PolyForm Noncommercial 1.0.0 | LICENSE-EE.md |
EE-designated paths (every file carries // SPDX-License-Identifier: PolyForm-Noncommercial-1.0.0):
src/security/firewall/— egress filteringsrc/security/agent_identity.rs— identity-based access control (OWASP ASI03)src/security/data_flow.rs— data flow tracking (EU AI Act Art. 12)src/security/message_signing.rs— HMAC inter-agent signing (OWASP ASI07)src/security/policy.rs— advanced policy enforcementsrc/security/response_inspect.rs,response_scanner.rs— outbound credential / exfil detectionsrc/security/scope_collision.rs— scope conflict detectionsrc/security/tool_integrity.rs— tool poisoning detection (OWASP ASI04)src/cost_accounting/— cost governancesrc/key_server/— OIDC-backed scoped key issuance
What this means in practice:
- Free for noncommercial use, modification, redistribution.
- Commercial use of EE modules requires a separate commercial license — contact
mikko.parkkola@iki.fi. - All releases prior to v2.11.0 remain entirely MIT and stay MIT forever.
Credits
Created by Mikko Parkkola. Implements Model Context Protocol version 2025-11-25.