MCP Gateway vs Running MCP Servers Directly

Every team that adopts the Model Context Protocol starts the same way. A developer adds a filesystem server and a GitHub server to Claude Desktop, edits a JSON config file, pastes in a token, and it works. This is the correct way to start. It is fast, it has no moving parts, and it teaches the team what MCP actually does before anyone commits to infrastructure.

The question is not whether to start there. It is when to stop. The direct model has a failure curve that is invisible at small scale and brutal at medium scale, and most teams hit the knee of that curve without noticing, usually around the point where the second team wants to use the same server and nobody can say who has the credentials for it. This post is about where that knee is, how to see it coming, and what actually changes when you put a gateway in the middle. If you want the ground-level definition first, what an MCP gateway is covers the shape of the thing; here we focus on the decision.

Outgrowing direct MCP connections? See what one gateway replaces. Book a demo.

The two architectures, concretely

"Direct" means each client is configured to talk to each server it needs. In Claude Desktop, Cursor, VS Code, or a custom agent, that is a per-client config file listing each server, its transport, and its credentials. The client holds the connection and the secret. There is no shared layer. If ten clients use the same server, that server's address and token live in ten places.

A gateway means each client is configured once, to talk to the gateway. The gateway holds the registry of which servers exist, terminates the connection to each backend server, and decides per request whether this caller may reach this tool. Clients never hold backend credentials; they authenticate to the gateway, and the gateway authenticates to the servers. The topology changes from a mesh to a star.

That picture is the whole argument in one image, but the picture understates it, because the lines are not just network connections. Each line in the mesh is also a credential to provision, a config entry to maintain, and a path with no audit. The star does not just reduce lines; it changes who owns each concern.

Where the two models differ, dimension by dimension

The differences are not evenly distributed. Some matter at any scale; some only bite past a threshold. Here is the honest breakdown.

Read the "adding a server" and "scaling" rows together and the dynamic becomes clear. In the direct model, every unit of growth multiplies work. In the gateway model, growth is additive and the per-item cost stays flat. That is the difference between a model that scales and one that merely functions.

The worked example: 30 developers, 6 servers

Numbers make this concrete. Take a mid-sized platform team: 30 developers, each using a mix of clients (some Claude Desktop, some Cursor, some a homegrown agent), and 6 MCP servers the organization wants everyone to be able to use. A GitHub server, a Jira server, an internal documentation server, a database-read server, an observability server, and a deployment server.

Direct. Each developer configures each of the 6 servers in each client. Ignore the multi-client complication and assume one client each: that is 30 × 6 = 180 configuration entries, spread across 30 machines, maintained by hand. More to the point, the three servers that need real credentials, the database-read server, the deployment server, and the GitHub server, now have their tokens copied onto 30 laptops each. That is 90 live credential copies for three sensitive systems, sitting in plaintext config files, with no central record of which copy is where.

Now run the operations that actually happen. The database server's token is rotated: 30 developers must each edit a file, and until the last one does, some are broken and some are using a stale secret. A developer leaves the company: someone has to know that their laptop held copies of three sensitive tokens and revoke each one, except there is no record that says so, so in practice nobody does, and three credentials walk out the door. A seventh server is added: 30 more config edits. A security review asks "who called the deployment server last Tuesday": there is no answer, because nothing logged it centrally.

Gateway. Each developer configures one endpoint: the gateway. That is 30 configuration entries, and they almost never change, because the thing they point at does not move. The 6 servers are registered once, in the gateway's registry. The sensitive credentials live in the gateway, in zero developer laptops. Token rotation is one change in one place. The departing developer is removed from the gateway's access control, and every path they had is closed in one action, with an audit record of what they had accessed. The seventh server is one registry entry, and it appears in the catalog for everyone entitled to it through dynamic discovery. The security question is a query against the audit log.

The config count drops from 180 to 30, but that undersells it. The number that matters is credential copies, which drops from 90 to 0, and the number of places a change must be made, which drops from "every affected laptop" to "one." The direct model did not fail because 180 is a big number. It failed because every operational event, rotation, offboarding, growth, audit, scaled with the mesh.

When direct is genuinely fine

Here is the part most gateway vendors skip. For a large and legitimate set of situations, you should not run a gateway, and installing one would be pure overhead.

Run servers directly when all of the following hold. One developer, or a few who do not share servers. One or two servers. Local servers, running on the same machine as the client over stdio, not remote servers reached over the network. No shared credentials, because each person uses their own. No compliance or audit requirement, because it is experimentation or personal tooling. This is the laptop case, and for the laptop case a gateway adds a hop, a dependency, and a thing to operate, in exchange for solving problems you do not have.

The clearest tell is the transport. A server running locally over stdio, owned by the one person using it, is a process on your machine; wrapping it in a gateway is like putting a load balancer in front of a script. The moment a server is remote, reached over Streamable HTTP by more than one client, the calculus inverts, because now there is a credential that travels, a connection that many clients share, and a question of who may use it, which is exactly the set of problems a gateway exists to answer. The MCP server hosting discussion goes deeper on the local-versus-remote line and why it is the real architectural fork.

The decision tree

If you want a single procedure, this is it. Walk the questions in order; stop at the first strong signal.

The tree encodes a simple idea: the gateway earns its place the moment any concern becomes shared. Shared across clients, shared across people, shared across the network, or shared with an auditor. As long as everything is private to one developer on one machine, direct wins. The instant something is shared, the thing that manages sharing, auth, access, discovery, and audit, has to live somewhere, and "somewhere" is the gateway.

Here is the same logic as a checklist you can score. Count your "yes" answers.

Zero or one "yes" and you are comfortably in direct-connection territory; enjoy the simplicity. Two or three and you are at the knee of the curve, where a gateway is about to pay for itself. Four or more and you are already paying the cost of not having one, in credential sprawl and unanswerable audit questions, whether or not it shows up on a dashboard.

See how TrueFoundry collapses N-by-M MCP connections into one governed endpoint. Book a demo.

What the gateway actually centralizes

It is worth being precise about what moves to the center, because "a gateway" can sound like a vague proxy. Four concrete things relocate.

Identity and auth. The gateway terminates OAuth to the backend servers, handling both two-legged (service-to-service) and three-legged (on behalf of a user) flows, so clients present one credential to the gateway and never hold backend secrets. The mechanics of these flows are covered in MCP authentication; the point here is that they happen once, at the choke point, instead of being re-implemented or copy-pasted per client.

The registry. Instead of each client hardcoding a list of servers, the gateway holds a curated registry of which servers exist, and clients discover tools dynamically from it. Adding or deprecating a server is a registry operation, not a fleet-wide edit. If the registry concept is new to you, what an MCP registry is explains the model.

Access control and guardrails. RBAC decides which users or teams may reach which servers and tools, and guardrails for things like PII and prompt injection apply uniformly, because every request passes through one place. In the direct model, each server enforces whatever it happens to enforce, inconsistently; in the gateway model, policy is written once. The broader control model is laid out in enterprise MCP governance.

Observability and audit. Every call produces a record: who, which server, which tool, when, with what latency and what result. That is the single most common thing teams discover they cannot do in the direct model, and the single hardest thing to retrofit, because you cannot log calls that never passed through a common point.

Where teams get this wrong

They install a gateway for a one-developer, one-server setup. Overhead with no payoff. If you are below the first threshold, a gateway solves nothing and adds a dependency. Start direct, and move when a signal fires.

They stay direct until a credential leaks. The more common and more expensive mistake. The direct model has no offboarding story, so when someone leaves with tokens on their laptop, or a config file gets committed to a repo, the first time anyone notices the sprawl is during the incident. The 90 credential copies were a liability the whole time; they only became visible when one of them was misused.

They treat "we have observability" as covered because each server logs. Per-server logs do not answer cross-cutting questions. "Which user has been hammering the expensive tool across all servers this week" is unanswerable when the logs live in six places with six schemas and no shared identity. Centralized observability is a different thing from six local logs.

They add the gateway but leave a direct path open. If clients can still reach servers directly, the gateway's access control and audit are advisory, not enforced. A choke point only governs what is forced through it. Closing the direct path is what turns the gateway from a convenience into a control.

They conflate "stateless transport" with "no infrastructure needed." Streamable HTTP being stateless makes servers easy to scale, but it does not manage credentials, discovery, or audit. Those are exactly the concerns the gateway owns, and they do not disappear because the wire got simpler.

Conclusion

The choice between a gateway and direct connections is not ideological, and it is not "gateways are enterprise, direct is for hobbyists." It is a function of sharing. As long as a server is private to one person on one machine, direct wiring is the simpler, better answer, and reaching for a gateway is premature. The moment a server is shared, across clients, across people, or across the network, the concerns that sharing creates, auth, access, discovery, and audit, have to live somewhere central, and that central place is a gateway.

The trap is that the direct model does not announce when it has stopped working. It keeps functioning while the credential copies pile up and the audit gap widens, right up until a rotation breaks half the team or someone leaves with tokens nobody tracked. The four questions, more than one client, shared servers, remote servers, any compliance need, are how you see the knee before you hit it. Count your yeses, and move when the count says to, not after the incident.

Move from scattered MCP servers to one control point. Book a demo.