The gateway has no tools of its own — what it gives you is the fan-out: deploy a server once, and every client behind the gateway sees it without editing four config files. The authentication story is the reason to run it in a team: Bearer tokens with real OAuth discovery, and session ids kept strictly as transport identifiers rather than credentials.
A reverse proxy for MCP servers. You deploy servers into it over an HTTP API, and it exposes them either individually or as one aggregated endpoint, prefixing each tool name with the server it came from so a client can tell them apart.
- POST /deploy — register a server by uvx or npx command with args and env, or by an SSE URL
- A per-server path — GET /{mcp-server-name}/sse and POST /{mcp-server-name}/message — to talk to one downstream server
- An aggregated path — GET /sse and POST /message — that merges every downstream stream and answers tools/list across all of them
- Streamable HTTP with session management through the Mcp-Session-Id header, alongside the legacy SSE transport
- Dynamic capability aggregation: the gateway advertises only the capabilities at least one downstream server actually supports
- OAuth 2.1 resource-server authentication with Protected Resource Metadata discovery at /.well-known/oauth-protected-resource
- A built-in account mode that can act as its own authorization server, exposing /oauth/authorize, /oauth/token and /oauth/register
Docker — pull ghcr.io/lucky-aeon/mcp-gateway and publish port 8080, or build the image yourself. Configuration is a config.json read from the config directory: Bind, GatewayProtocol (all, sse or streamhttp, also settable with --protocol), and an Auth block. With Auth.Enabled true every MCP request must carry a Bearer token; set it to false for local unauthenticated use.
One command — docker run -d --name mcp-gateway -p 8080:8080 ghcr.io/lucky-aeon/mcp-gateway