MCP server vs MCP gateway: the request path

The config file that keeps growing

A team starts with one MCP server. Someone on the platform team runs the Linear server locally, adds four lines to ~/.cursor/mcp.json, and it works. Two months later there are five servers in that file, three of them holding a personal API key in plain text.

MCP server vs MCP gateway is the question underneath that mess: whether you need more servers, or something in front of them. The two words get used as if they named the same layer. They do not. One runs tools. The other decides who may run them.

Cursor reads MCP servers from .cursor/mcp.json in a project and from ~/.cursor/mcp.json in the home directory. A remote server entry is defined with a url field, per cursor.com/docs/mcp (checked October 2026). None of the client admin pages documents an inventory of the servers sitting in those files (checked October 2026, code.claude.com/docs/en/managed-mcp). That inventory, if it exists at all, lives wherever each engineer's config happens to be.

MCP, the Model Context Protocol, is the standard way an AI client asks a server what tools exist (tools/list). It then runs one with tools/call, over JSON-RPC 2.0 messages.

What is an MCP server?

An MCP server is one system's execution endpoint. It lists the tools that system offers, takes a tools/call, performs the action against that system's API, and returns the result. That is the whole job, carried over a transport such as stdio (local process) or Streamable HTTP (remote).

What it does not have is any notion of your organization. It does not know that Priya is in support and Marcus is in finance. It does not know that your Member role may read Stripe but not create a coupon. It trusts whoever presents the credential it was given. That credential is usually a token in a file on somebody's laptop, or an OAuth grant the person made for themselves.

Some MCP servers are run by the vendor whose system they expose. Others are packages a developer runs locally. Either way the server executes; it does not govern. If five people each connect to the same Linear server, you have five independent access paths. You also have five places the credential lives. That is five places it can leak, and five places someone has to remember to revoke it.

What is an MCP gateway?

An MCP gateway is one address in front of many servers and connectors. It handles sign-in, resolves which person is calling, and checks what that person may reach. It then runs the call and writes the result to an audit log the organization can read. To the AI client it looks like one large MCP server.

Elaichi is a gateway of that shape. Every request to its endpoint carries an OAuth access token. OAuth is the sign-in handshake where a person approves an app in a browser rather than pasting a key. The grant behind that token records which person, which organization, and which toolboxes the call may reach. The URL carries nothing: https://api.elaichi.ai/mcp is the same string for every organization, and the grant decides the rest.

Four mechanics a gateway adds that a bare server has no way to implement:

The honest corollary: calls a client makes to a vendor's MCP server directly do not pass through Elaichi, so Elaichi does not govern them. A gateway only governs what goes through it. A second, un-proxied config entry to the same server bypasses all four mechanics above.

How does a tool call actually run, with and without a gateway?

The difference shows up as two request paths for the same question, "which Stripe charges failed this week."

Direct to a server. The client reads a config file, finds the Stripe server entry and the credential beside it. It calls tools/list, gets the server's tools, and calls one. The credential travels from the laptop. Whatever that credential can do upstream is what the call can do: the server has no idea the person is in support rather than finance. The record of the call, if there is one, lives in Stripe's own logs, under whatever account the key belongs to. Finding out what the model ran means reading application logs across every app separately.

Through Elaichi. The client sends POST https://api.elaichi.ai/mcp with an Elaichi access token in the Authorization header. Elaichi re-reads the OAuth grant on every request: removing or suspending a member revokes every live grant in the same transaction as the membership change. It resolves the person's role and restrictions and refuses a blocked tool before anything leaves. That check is not a single gate at the door. Restrictions are enforced at every point a member can reach a tool, from listing to the final outbound request. It fetches the connected account's credential from a separate credential service, where connector secrets are encrypted at rest with AES-256-GCM. It applies the credential and calls Stripe. The result comes back capped per value, with secret-named keys scrubbed. In Elaichi, one entry for each connected-tool call that reaches execution (a call refused earlier writes none).

The client never holds the Stripe credential in either direction. That is the practical shift: credentials move off laptops into a service the organization controls. The AI client holds only an Elaichi token that expires in an hour.

Elaichi's MCP endpoint has no prompt-injection defense of its own. The endpoint receives only a tool name and arguments from a tools/call, never the person's own prompt. There is nothing to judge the call against. That defense belongs to the client. A gateway constrains what a call can reach, not whether the model should have made the call.

One catalog, two kinds of connector

Elaichi's catalog holds two kinds of thing, and keeping them apart matters when you are deciding what a gateway buys you.

The catalog holds 650+ connectors. Most of them Elaichi authors and runs itself, built and operated by the same engineering organization that builds Elaichi. For those, Elaichi is itself the MCP server the client calls. There is no second server behind it.

The rest are native MCP connectors. Each one is a vendor's own remote MCP server that the vendor builds and runs, published once by Elaichi staff for every organization. Datadog and Linear are in the catalog this way. For a native MCP connector, Elaichi sits in front of that server. Restrictions and OAuth scopes are checked before a call leaves. The call is written to the audit log, and only a tool on that connection's own active list can run. The vendor builds and runs the server; Elaichi handles sign-in, access and audit. Elaichi does not write, test, or fix those tools, and bug reports about them go to the vendor's own support channel, not Elaichi's.

A team can also bring its own remote MCP server in as a connector, under the same rules. A company that runs an internal MCP server over public HTTPS can add it once and have every call to it governed. Each developer no longer wires it up locally. That bring-your-own path requires a paid plan tier that includes custom connectors; check current plan details before assuming it's included.

From the AI client's side all three look the same. Tools from every connected app come through one address, found with search_tools and run with read_tool or execute_tool. The wrapper buys no privilege of its own: execute_tool unwraps to a name and arguments. It meets the same gates a direct call by that name would meet. In Elaichi, connected tools are never listed one by one, however few there are.

What changes when somebody leaves

With direct servers, revoking access means hunting down the individual keys a person held. That means every server they configured, on machines you may not control. There is no single place the list exists.

Through a gateway, every call made with a grant's tokens acts as the person who approved that grant. Permissions are looked up on each request rather than stored in the token. Removing or suspending a member revokes every live MCP OAuth grant they hold in that organization, and their clients fail on the next call. Reactivating them does not bring the grants back; they consent again. Changing a role or a restriction is a different clock: about two minutes.

Elaichi never tells a client its tool list changed, and clients cache that list, so a withdrawn tool can linger in the picker. It does not linger in the gateway. Every call re-checks the grant, the role and the restrictions at call time. A cached tool that is actually revoked fails when it is called, rather than succeeding quietly. Roles, restrictions and ACLs sets out which of the three layers does what.

MCP server vs MCP gateway: which one do you need?

You need only servers when the blast radius is small and the people are few.

Two engineers building an internal agent against one internal API do not need a control plane in front of it. They are on machines they own, with credentials they already hold for that API. A local server and a config file is lower latency, fewer moving parts, and nothing a gateway adds is a problem they have yet. The same goes for a solo developer wiring Claude Code to a repository tool. Buying governance before you have anybody to govern is a cost with no return. There is a longer version of that argument in when you don't need an MCP gateway yet.

You need a gateway when one of these becomes true:

• More than one person, with different jobs. The moment support and finance want the same assistant pointed at different tools, you need a layer that knows who is asking. A server does not.
• Non-technical teams. Fifty support agents are not going to edit claude_desktop_config.json. One address and a browser sign-in is the only shape that reaches them; MCP without JSON config files walks through it.
• Credentials you cannot account for. If you cannot say which laptops hold which keys, the fix is to stop distributing them, not to distribute them more carefully.
• Somebody is going to leave. One revocation cuts off every connected app at once. Chasing a key out of five config files is a different kind of afternoon.
• You will be asked what the AI did. One audit log across every connector, readable in the console, is the thing an auditor asks for. Elaichi keeps 90 days of audit history, and export to your own Datadog comes with the Black plan.

The cost is real. A gateway adds a network hop and a setup step. It governs only the calls that pass through it. A client with a second, unmanaged config entry to the same server defeats all of it. The decision is not really server or gateway. Servers keep existing either way: a native MCP connector is still the vendor's server, and a remote MCP connector is still yours. The question is whether every call to them goes through one place that knows who is calling.

Quick comparison:

If you are still weighing shapes rather than deciding on one, what is an MCP gateway sets out the four architectures the category has settled into. The connector catalog shows which apps are already there.