One endpoint for each client, team or project
A project gateway publishes the tools of the servers you pick, up to fifty of them, at one address with its own sign-in. The MCP Gateway covers the whole install; a project gateway covers one slice of it, and the people who use it see only the tools that belong to them.
A single URL per client, and nothing of anyone else's
An agency running servers for ten clients, or a company with a billing team and a support team, does not want one endpoint that publishes everything. A project gateway groups the servers that belong together and hands out one address for them. Configure the client once; the tools of every member server arrive under it, and a server you add to the gateway later shows up without another setup step.
- Name it, and the slug becomes its address
- Pick the member servers on the gateway's own page
- Each gateway has a switch on the list, so you can pause one without deleting it
Gateway, project gateway or server?
All three speak the same protocol and connect the same way. They differ in what they publish and who signs in.
| MCP Gateway | Project gateway | A server | |
|---|---|---|---|
| Publishes | every server on the install | the servers you pick, up to fifty | its own tools |
| Address | /mcp | /mcp/your-gateway | /mcp/your-server |
| Sign-in | its own | its own | its own |
| New servers | appear automatically | only when you add them | |
| Remote MCP servers | never included | never included | connect directly |
Tool names that say where they came from
Inside a gateway each tool is prefixed with the slug of the server that owns it. Two servers can both have a search tool without a clash, and an AI client can tell which system it is talking to.
- A call is routed to the owning server and runs under that server's own settings, rate limit and logs
- The log entry names the gateway it came through, and the CSV export has a Via column
- Every member keeps its own /mcp/your-server address as well
// tools/list from https://mcp.yourapp.com/mcp/harbor-dental "tools": [ { "name": "harbor-bookings__list_appointments" }, { "name": "harbor-bookings__reschedule" }, { "name": "harbor-site__search_posts" }, { "name": "harbor-site__update_page" }, { "name": "harbor-reviews__list_reviews" } ]
Each gateway has its own sign-in
How a client proves who it is to a project gateway is set on the gateway, not on its members. The members' own authentication does not apply inside it.
OAuth
The client registers itself and opens a browser sign-in to your install. Claude, ChatGPT and Cursor run the flow themselves, and the person approving is a user on your install.
API key
Create a key for the gateway and the client sends it in the X-API-Key header. For scripts and agents that cannot open a browser; each key can expire and be revoked on its own.
WordPress sign-in
On WordPress, list the accounts that may connect. An empty list lets nobody in, administrators included, and the list is checked on every request.
No sign-in, for local testing
Anyone with the URL can call the published tools. A new gateway starts this way, so at first only servers that need no sign-in themselves can join it.
Members, in order, and which ones are ready
The gateway's Servers tab lists its members in the order clients see them, lets you publish all of a member's tools or only the ones you choose, and tells you before a client finds out which servers cannot join yet. A gateway never passes a caller's credential on to a member, so a member needs a credential of its own.
- An open gateway refuses a member that requires sign-in until you protect the gateway, and says so next to the server
- A member that forwards the client's own credential to its API is listed under Not ready, with a link to the setting that changes it; one that stores its upstream credential works as it does on its own
- Saving a gateway whose sign-in is weaker than a member's own shows a warning naming the members it would expose; the save goes through, so the choice is deliberate
Built so a gateway cannot weaken a server
Grouping servers behind one URL raises an obvious question: can it hand a protected server to a client that never signed in to it? These rules say no.
Credentials stop at the gateway
A caller's key or token is checked by the gateway and goes no further. A member either stores its own upstream credential or returns a clear error through the gateway, never a call made with somebody else's credential.
Open carries only open
A gateway with no sign-in accepts only members that were open themselves. Protect it with OAuth, a key or WordPress sign-in, and servers with their own sign-in can join.
Off keeps the configuration
Switching a gateway off refuses its clients and keeps its members and settings for when you switch it back on. Deleting it removes the gateway only, never the servers in it.
Remote servers stay direct
A remote MCP server is never part of the MCP Gateway or a project gateway. Clients connect to it on its own address, so someone else's tools never ride behind your gateway's sign-in.
Logged with the route
A call that a gateway passed on is logged on the member server with the gateway's name, so you can see which gateway a client used. The CSV export carries it in a Via column.
Counted like a server
Creating or duplicating a project gateway counts against your plan's server limit, like a server does, and a gateway needs at least two members. Below two, the Create button is disabled and says why.
Questions about project gateways
How is this different from the MCP Gateway?
The MCP Gateway publishes every server on the install at /mcp and picks up new servers automatically. A project gateway publishes only the servers you add to it, at its own address, with its own sign-in. You can run both at once, and as many project gateways as your plan's server limit allows.
How many servers can a project gateway hold?
Between two and fifty. A gateway groups servers, so with fewer than two the Create button stays disabled and tells you why.
Which clients can connect?
Any MCP client that speaks Streamable HTTP. With OAuth, Claude, ChatGPT, Cursor and VS Code register themselves and open the sign-in; with an API key, anything that can send a header works. The address is on the gateway's card.
Does a gateway change how a member server signs in its own clients?
No. Each member keeps its own address and its own authentication for clients that connect to it directly. Inside the gateway, only the gateway's sign-in is checked, and the gateway never forwards a credential to a member.
Which plan do I need?
Project gateways are on the Pro plan and above, on both the WordPress plugin and the standalone app. The MCP Gateway for the whole install is on every plan.
See it in use
All use casesRun every client project in Kitchen.co from Claude
Connect the Kitchen.co API to your own MCP server once. Then ask Claude what's overdue across every client board, who you're waiting on, and have it post the update in the right conversation.
HMWrite the weekly client report from HubSpot and Mailchimp
Pull each client's new deals from HubSpot and their campaign results from Mailchimp, then have Claude write the week up in your words. Ask for it on Monday morning and send it on.
WLook after every client WordPress site from one chat
Give each client site its own server from the WordPress template, all behind one Gateway address. Then ask which sites have drafts waiting, or fix a page on any of them, without signing in to each one.
One address per client.
Group the servers that belong together, pick a sign-in, and hand each client a single URL that shows them only their own tools.