An open-source aggregation gateway for the Model Context Protocol. It puts hundreds or thousands of MCP servers behind a single endpoint — without ever flooding your agent's context window with tool definitions.
The MCP ecosystem has a scaling ceiling built into it. Every server you connect dumps its full tool catalog — names, descriptions, and JSON schemas — straight into the model's context at startup. A single rich server can eat 15–20k tokens. Past roughly 10–15 active servers, clients slow, degrade, or crash outright. The ecosystem's growth is throttled by the context window itself.
One-Stop MCP is an intelligent membrane between one AI client and an unbounded fleet of downstream servers. It's a spec-compliant MCP server to the client, and a spec-compliant MCP client to every server behind it. The client sees a lightweight, constant-size interface no matter how many servers are registered.
Connect once to One-Stop MCP. Every OAuth, secret, and downstream server is initiated, redirected, and managed inside the gateway — so your agent stays lean and your credentials live in exactly one place.
Five principles, ordered. When a trade-off is unclear, the earlier principle wins.
Every choice is measured first by its effect on the client's window. If a feature adds startup tokens that scale with server count, it's wrong by default.
A server to the client, a client to every downstream server. Speak the protocol perfectly in both directions. No extensions the ecosystem can't adopt.
Connect once. Every OAuth flow and API key is initiated and stored inside the gateway — a single, auditable trust boundary, not a dozen scattered configs.
The catalog is the moat, and it only grows if contributing is trivial. Adding a server means writing one declarative manifest — no gateway code, no rebuild.
The same binary runs as a desktop proxy and a self-hosted team gateway. We don't build two products. Deployment mode is config, not a fork.
If adding the 1,000th server changes the client's experience at all — in latency, tokens, or reliability — the architecture has failed. Constant-cost scaling is the whole point.
Instead of exposing every downstream tool, the gateway exposes a tiny, fixed set of meta-tools. This is the single most important mechanism for keeping context flat: the client's startup context holds ~4 tool definitions, a constant. Downstream schemas enter context only when a task needs them, then leave.
find_tools(query)list_servers(filter?)invoke(server, tool, args)connect_server(server)~4 tool definitions at startup — a constant. Five servers or five thousand: identical footprint. The catalog can grow without limit because the client never sees it all at once.
Discovery runs in two cooperating layers, marrying the recall of vector search with the precision of explicit tool selection.
Every tool is embedded — name, description, example utterances — into a local vector index at registration. A task query is scored against the index and the top-K candidates are retrieved before any schema touches context.
Only the candidates' full schemas are returned to the model, which makes the final tool choice from a clean shortlist and calls invoke(...). Recall from vectors, precision from the model.
Fallback ladder: exact / keyword match → vector similarity → category browse via list_servers. On low confidence, the gateway widens the shortlist rather than guessing.
This is the one connection, one vault principle in practice. The user authenticates to the gateway once; every downstream connection is brokered internally, and secrets never reach the client config or the model.
The client calls connect_server("notion").
The gateway looks up Notion's auth model in its manifest (OAuth2).
The gateway initiates the OAuth flow and returns a redirect URL to the user.
The user approves in-browser; the callback lands on the gateway, not the client.
Tokens are encrypted and stored in the vault, scoped to that user + server.
All future Notion calls are transparently authenticated by the gateway.
Secrets never live in client config files and are never returned to the model. The vault is the single trust boundary: encrypt-at-rest, per-user / per-org scoping, admin MFA, and a full audit log of every credential use. Downstream keys are injected only into outbound calls.
Registered ≠ running. A downstream server consumes zero resources until a tool from it is invoked. On first invoke, the gateway spawns or connects, pools the live session, and reaps it on a TTL — so CPU and RAM stay flat even with a huge catalog. As a third context defense, an optional compression pass strips redundant JSON-schema boilerplate from the shortlist before it enters context, compounding the savings.
Centralizing every credential in one place is only acceptable if that place is a fortress. So we treat security not as a checkbox but as the product's headline strength — and we hand you the tools to watch, rotate, and cut off every connection yourself.
Every OAuth token and API key lives encrypted in a single vault, scoped to you. It is never written to a client config, never returned to the model, and never exposed to a downstream server beyond the one outbound call it authenticates. One place to secure means one place to lock down — and we hold that boundary to a strict standard.
Every time a credential leaves the vault, it's logged: which server, which tool, when, and the result. If a platform is calling more than it should — or reaching where it shouldn't — you'll spot the misbehaving connector immediately.
Anomalous access is surfaced — a server suddenly exporting in bulk gets flagged, not silently trusted.
One control revokes every active session and freezes the entire vault instantly. All downstream access stops — no per-server hunting, no waiting. Re-enable connectors one at a time once you've found the culprit.
Also scoped: revoke a single server, or every session for one user.
Rotation is normally a per-service chore: log into each dashboard, re-issue a key, paste it into whatever config uses it. Because the vault already brokers every connection, One-Stop MCP turns that into a single action — rotate one server, a group, or everything — and every downstream call keeps working because the gateway swaps the credential inline. Set a policy (e.g. every 90 days) and it happens on its own.
The vault holds the refresh token, so it force-refreshes access tokens on demand or on schedule — fully automated, zero user steps.
Where the provider exposes a key-management API, the gateway issues a new key and retires the old one. Where it doesn't, it walks you through re-issuing and swaps it in.
Hit the kill switch, find the bad actor in the ledger, then rotate everything it might have seen — one flow from suspicion to clean slate.
Honest scope: rotation is automated where a provider supports it, and guided everywhere else — no service is left as a manual blind spot.
Scattering secrets across a dozen client configs means a dozen blind spots, no way to pull the plug, and rotation nobody ever gets around to. One vault flips all three: total visibility into where your credentials go, a single lever to stop them cold, and one-action rotation to refresh them. Centralization is what makes real oversight possible.
Adding a server is one declarative file and one PR. The gateway needs zero code changes. This is the contract that makes the FOSS flywheel spin.
# one file. one PR. the gateway derives the rest. id: notion name: Notion category: [productivity, docs, knowledge-base] description: > Read, search, and write Notion pages, databases, comments. transport: type: streamable-http # or: stdio url: https://mcp.notion.com/mcp auth: type: oauth2 # none | api_key | oauth2 scopes: [read_content, update_content] routing: # powers the semantic index examples: - "find my meeting notes in notion" - "create a page in my workspace" - "search the docs database" health: check: initialize
Derived automatically: the tool list (via MCP initialize + tools/list), embeddings for the router, the OAuth broker config, and the catalog entry. Contributors never touch gateway internals.
v1 is useful on first run. Contributors extend from there. The exact 50 is locked during the RFC — selection weighs popularity, maintenance activity, breadth, and clean spec-compliance.
Reference implementation in TypeScript / Node — first-class official SDK, the ecosystem's lingua franca, lowest barrier for contributors.
coretransportsvector indexvaultcatalogpackagingGo is a strong alternative for the gateway core — single static binary, concurrency, low memory — with a TS manifest layer. This is an explicit RFC question, not a settled decision.
Single downstream server proxied end-to-end over stdio.
Manifests, vector index, JIT injection — N servers behind one endpoint.
The connect_server flow, encrypted storage, per-use logging, one-place rotation, and master revoke.
Manifests for the seed catalog + a registry sync worker.
Org scoping, per-user secrets, audit logs, metrics.
Docs, manifest CI validation, public RFC cadence, governance.
Core language — TypeScript vs Go for the gateway core?
The 50 — which exact servers ship in the seed catalog?
Embeddings — local small model vs pluggable remote for higher accuracy?
Secret isolation — per-user encryption keys vs per-org vault partitions?
Compression — how aggressive before it hurts tool-selection accuracy?
Registry sync — auto-ingest from public directories, or curated-only?
Rotation policy — default cadence, and how to handle providers with no key-rotation API?
Anomaly detection — rule-based flagging for the usage ledger, or a learned baseline per connector?
Governance — BDFL, core-team consensus, or foundation-style from day one?
One-Stop MCP invites contributors from day one. The design deliberately makes the highest-volume contribution — adding a server — the easiest possible action.
Submit one manifest under /servers. CI validates it and probes the endpoint.
Add example utterances to existing manifests to improve semantic retrieval.
Gateway internals, transports, vault backends, compression — tracked as labeled issues.
Weigh in on the seven open questions before the architecture sets.