One MCP endpoint for every server you run
The MCP Gateway publishes the tools of every server on your install at a single URL. Configure a client once, and a server you add next month shows up in it without another setup step.
Set it up once, in the client
Without a gateway, every MCP server is a separate connection: a URL to paste, a credential to store and a connector to approve in Claude, Cursor or ChatGPT. The gateway folds all of them into one endpoint, so the client has one connection and sees the merged tool list.
- Your individual server endpoints keep working unchanged
- A server you create later appears in the gateway automatically
- The screen shows the exact tool names clients will see before you connect anything
Tool names that cannot collide
Two servers can both have a tool called search. The gateway prefixes each published tool with the slug of the server that owns it, so the client can tell them apart and the call reaches the right one.
What a client sees
The prefix is the server slug followed by two underscores. You can switch prefixing off on a small install where names never clash, and the Published tools panel shows the final list either way.
- Names are capped at 128 characters, and a long prefix is shortened rather than the tool name
- Each call is routed to the owning server and runs under that server's own settings, rate limit and logs
- Every server stays reachable at its own /mcp/your-slug URL
// tools/list from https://mcp.yourapp.com/mcp "tools": [ { "name": "billing__list_invoices" }, { "name": "billing__create_invoice" }, { "name": "support__search_tickets" }, { "name": "support__reply_ticket" }, { "name": "warehouse__run_query" } ]
The gateway has its own authentication
How a client proves who it is to the gateway is a separate setting from each server's own authentication. Pick the one that fits how the client will connect.
OAuth, recommended
The client registers itself and opens a browser sign-in to your install. Nothing to copy or store, and the person approving is a user on your site. Claude, ChatGPT and Cursor all run this flow themselves.
API key
The client sends one of your API keys in a header. For scripts and agents that cannot open a browser.
Bearer token
The client sends a token you configure, in an Authorization header. Simple to set up in any client that has a headers field.
No authentication, for local testing
Anyone who knows the URL can call the published tools. An open gateway only ever carries servers that were already open themselves; see below.
Choose what it publishes
Publish every server, or only the ones you pick. Once a merged tool list grows past a few dozen tools, an AI picks the right one less reliably, so the selected mode is worth using on a busy install.
- Every server: new servers appear automatically
- Only the servers I choose: tick them, and the screen lists what is included now
- The built-in GetMCP management server is never published through the gateway
Built so a gateway cannot weaken a server
Aggregating servers behind one URL raises an obvious question: can it leak a protected server to an open endpoint? These rules say no.
An open gateway carries only open servers
If the gateway has no authentication, a server that requires its own credential is held back and listed on the screen, rather than silently republished without it. Naming that server explicitly in selected mode is the only way to include it.
Reserved names
gateway, hub, all, portal, aggregate, everything and mcp are reserved as server slugs, so nothing you create can shadow the gateway. A server that already used one of them keeps it.
Off means off
With the gateway switched off, an MCP-shaped request to /mcp gets a JSON-RPC error that points at the Gateway screen, and an ordinary browser request falls through to your site as before.
Discovery a strict client accepts
OAuth discovery is served at the exact URL the gateway's 401 challenge names, and the consent redirect carries the issuer parameter ChatGPT validates. Clients that follow the specification to the letter connect first time.
Same on both builds
The gateway exists identically in the standalone app and the WordPress plugin, with its own entry in the admin menu. On WordPress it never claims the site-root OAuth paths another MCP plugin may use.
Logs stay per server
A call through the gateway is delegated to the owning server, so it lands in that server's call log and analytics with the same detail as a direct call.
Questions about the gateway
Do I have to use the gateway?
No. It is off by default. Every server keeps its own endpoint, and you can hand a single server to a client with Quick Connect exactly as before. Turn the gateway on when a client needs several servers at once.
Which clients can connect to it?
Any MCP client that speaks Streamable HTTP. With OAuth selected, Claude, ChatGPT and Cursor register themselves and open the sign-in; with an API key or bearer token, anything that can send a header works.
Can I use my WordPress accounts as the sign-in?
Yes. The gateway's OAuth is first-party: the person approving the connection signs in to your install with their own account. Publish a server through the gateway, keep the server itself on an API key, and clients sign in with accounts you control.
Does the gateway add a network hop?
No. The servers it publishes run on the same install, so the merged tool list is assembled in process and each call is delegated directly to the owning server's handler.
One URL for all of your servers.
Turn the gateway on, pick an authentication method, and paste a single endpoint into every client you use.