One container for all your MCP servers, speaking both MCP revisions on every endpoint — 2026-07-28 and 2025-11-25, the client picks. Serve many stdio servers over one HTTPS endpoint for ChatGPT, Claude, Le Chat, Cursor and any other MCP client, with the Claude Code config format you already have, path-based routing, a context-friendly aggregate endpoint, and OAuth 2.1 in both directions.
A client no longer has to register to use this hub. It publishes a Client ID Metadata Document at a stable HTTPS URL and uses that URL as its client_id; the hub fetches the document, reads the client's name and redirect URIs out of it, and shows you the origin that vouched before you approve anything. Nothing is stored, so a client that is reinstalled or moves to another machine is still the same client — and the approval you gave it still holds.
That URL is chosen by an unauthenticated caller, so the fetch is treated as hostile: https only, no redirects, no private addresses, the checked address pinned into the connection, a hard size cap and a short timeout.
Confidential clients authenticate at the token endpoint with private_key_jwt against the keys in their own document. Everything older keeps working: RFC 7591 dynamic registration stays advertised beside it, mcp-hub-admin clients add issues credentials by hand for a client that can do neither, and one setting turns a mechanism off once you no longer need it.
The interesting half is that it works in the other direction too. A remote MCP server that requires OAuth is not a problem to be bridged around — the hub is an OAuth client in its own right:
Machine-to-machine upstreams need no attention at all — the hub fetches a token and renews it. Where a person has to sign in, one command prints a URL, and the server comes up by itself once you have.
The same trick, applied to the protocol itself. Every endpoint answers MCP 2026-07-28 and 2025-11-25 alike, and the client cannot tell from the answers which one it got. Where the two revisions genuinely differ, the hub absorbs the difference rather than passing it on:
Towards a client
Towards a child server
Elicitation — a server asking a person something
returned as a result on 2026-07-28, so it reaches the person instead of dying at the gateway
forwarded to the child that asked, with the answer carried back
Subscriptions — a server announcing that something changed
served as a subscriptions/listen stream
subscriptions/listen to a 2026 child, resources/subscribe to a 2025 one
That second row is the useful one in practice: most MCP servers in the wild are still on the older revision, and their notifications now reach clients that only speak the newer one.
mkdir -p data && sudo chown -R 1000:1000 data # the container runs as uid 1000docker run -d --name mcp-hub \ -p 127.0.0.1:7690:80 \ -e EXTERNAL_URL="https://mcp.example.net" \ -e PASSWORD_HASH="$(htpasswd -bnBC 10 '' 'yourpassword' | tr -d ':\n')" \ -e TRUSTED_PROXIES="192.168.1.0/24" \ -v "$PWD/config:/config:ro" \ -v "$PWD/data:/data" \ ghcr.io/ni-c/mcp-hub:0.10.0
Point a reverse proxy with a TLS certificate at 127.0.0.1:7690, then add https://mcp.example.net/hub as a custom connector in your MCP client — ChatGPT, Claude, Le Chat, Cursor and friends — and log in once with the password.
