MCP-Compose
phildoughertyLABSCO SUMMARY
One endpoint, one token, and a name prefix that tells you which server answered.
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.
What it is
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.
What you get
- 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
Requirements
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.
Setup effort
One command — docker run -d --name mcp-gateway -p 8080:8080 ghcr.io/lucky-aeon/mcp-gateway
USE CASES
01
Adding a server for everyone at once
Post the server's command, args and environment to the gateway; every connected client picks it up without a local config change.
02
Giving a client one address for everything
Point the client at the aggregated stream and let it list tools across every downstream server in one call.
03
Putting authentication in front of local servers
Turn on Bearer-token auth and let clients discover the authorization server from the protected-resource metadata.
04
Migrating clients off SSE
Switch the exposed protocol to Streamable HTTP, or serve both while clients catch up.
BEFORE YOU INSTALL
What to know first
Requires
docker on PATH
INSTALLATION
Connect your client
This project publishes no client configuration, so the entry for your client is yours to write.
Server setup
TERMINAL
docker run -d --name mcp-gateway -p 8080:8080 ghcr.io/lucky-aeon/mcp-gatewayThen register downstream servers with POST /deploy and point your MCP client at http://localhost:8080/stream (Streamable HTTP) or http://localhost:8080/sse. Authentication is on by default: while Auth.Enabled is true in config.json, every MCP request must carry an Authorization: Bearer token, issued by the OAuth server set in Auth.AuthorizationServers or, in saas mode, by the gateway's own account login. For local use without a token, set Auth.Enabled to false.
