What is mcp-hub?

mcp-hub serves many Model Context Protocol servers from one container, published over HTTPS for ChatGPT connectors, Claude (Web and Code), Mistral Le Chat, Cursor and any other Streamable-HTTP MCP client — behind a built-in OAuth 2.1 authorization server protected by a single password, with API tokens for clients that cannot do OAuth.

The problem

Most MCP servers are stdio programs. They read JSON-RPC on stdin and write it on stdout, and they assume a client that starts them as a child process. That works beautifully on a laptop and not at all for a hosted client: ChatGPT connectors, Claude Web and Le Chat speak HTTP and expect OAuth.

The usual fix is to wrap each stdio server in its own auth proxy. That works, but the cost per server is real:

• a container image and a compose stack,
• a hostname and a TLS certificate,
• an OAuth authorization server with its own client registrations and its own state directory,
• a firewall rule, a log stream, a monitoring entry and a backup path.

Nine servers means nine of each. Every one of them has to be updated, scanned and re-authorized separately, and every one is a place where an authorization bug can hide.

What mcp-hub does instead

One Node process holds all of it:

N wrapper containers collapse into one process — the servers themselves are unchanged.

What you get

Your existing config works. /config/mcp.json uses exactly Claude Code's mcpServers schema, ${VAR} expansion included. Copy entries across without translating them. The one extra field, "hub": false, is ignored by Claude Code, so the file stays interchangeable.

Path-based routing. Each server is reachable at /<name> and /<name>/mcp. Register the ones you reach for daily as their own connectors.

The /hub aggregate. Registering nine connectors means nine servers' worth of tool schemas in the model's context before a single question is asked. /hub is one connector that exposes six meta-tools — list_servers, list_tools, get_tool_schema, call_tool — and lets the model page in only the schema it actually needs. Four schemas instead of N×tools.

Client registration that does not need registering. The hub is its own OAuth 2.1 authorization server, and it takes the path the MCP specification now prefers: a client uses an HTTPS URL as its client_id and hosts its own metadata document there, including the keys it authenticates with. Nothing is issued, nothing expires, and a client that reinstalls is still the same client. RFC 7591 dynamic registration stays advertised beside it, so older clients keep working — and one setting retires it when you no longer need it.

Real supervision. Children start at boot, get pinged every 60 seconds and are restarted with exponential backoff when they die. A server that is down answers 503 on its path and shows up in /health — it does not hang.

Hot reload. Editing mcp.json starts, stops or restarts exactly the servers whose entries changed. Everything else keeps its connections.

Stateless transport. No session state is kept between requests, so a client that reconnects without closing its previous session — which claude.ai does, roughly every five minutes — cannot leak processes or memory.

Both MCP revisions, on every endpoint. 2026-07-28 and 2025-11-25; the client picks and cannot tell from the answers which one it got. On the 2026 revision a child server's question reaches the person at the far end, which is the one thing a gateway used to take away from servers like smtp-mcp and imap-mcp.

Changes reach the client that asked, whichever era the server speaks. A client opens a subscriptions/listen stream and hears when a child's tools, prompts or resources change. Upstream the hub asks each child the way that child understands — subscriptions/listen to a 2026 server, resources/subscribe to a 2025 one — so the era gap is the gateway's problem rather than either end's. Most MCP servers in the wild are still on the older revision, which is exactly when this matters.

Light enough for a Raspberry Pi. A stated project goal: one Node process, no database — state is one JSON file plus an Ed25519 key under /data — a six runtime dependencies, and multi-arch images (amd64/arm64). The stateless transport and the missing database are not accidents; they are what keeps the hub comfortable on a single-board computer.

What it is not

• Not a sandbox. Every stdio server configured in the hub container runs as the same operating-system user as the hub and can read its mounted files and environment. Only run stdio packages you trust; put anything else in its own container and connect it as a remote server. See Security.
• Not a notification bridge for 2025-11-25 clients. Change notifications are carried on 2026-07-28, where the client opens the stream and the state is the open response. The older revision delivers them unsolicited on a channel the stateless transport does not keep, so the hub does not offer them there — and says so in its capabilities rather than announcing something that will not arrive.
• Not a multi-user system. There is one password. Anyone who has it can approve a client and reach every server the hub exposes.

Next

• Getting started — a working deployment
• Configuration — writing your mcp.json
• Client registration — how clients get a client_id
• Architecture — what happens inside
• Comparison — when something else fits better