What is an MCP gateway?

An MCP gateway is a service that sits between an AI application's MCP client and the MCP servers it uses. The client connects to one gateway endpoint instead of to each server. The gateway holds the server connections and their credentials, decides which tools each agent may see and call, forwards permitted requests, and records what happened. The servers still provide the tools and data; the gateway controls how agents reach them. Toolstile runs this model as a managed service.

MCP stands for Model Context Protocol. It gives AI applications a common way to discover and use capabilities supplied by servers: tools that perform actions, resources that provide context, and prompts that supply reusable templates. The official MCP architecture overview explains those building blocks, and what is an MCP server? walks through them with real messages. A gateway speaks MCP on both sides. To your client it looks like an MCP server, and to each upstream server it looks like an MCP client.

The request path through a gateway

With direct connections, every AI app on every machine carries its own list of servers, URLs and tokens. With a gateway, the app knows one URL and one sign-in. The server list lives in the gateway.

 Without a gateway                     With a gateway

 Claude Code ──┬── GitHub MCP          Claude Code ──┐            ┌── GitHub MCP
               ├── Linear MCP                        │            │
 Cursor ───────┼── GitHub MCP          Cursor ───────┼── Gateway ─┼── Linear MCP
               └── Sentry MCP                        │  (auth,    │
 Codex ────────┬── Linear MCP          Codex ────────┘   rules,   └── Sentry MCP
               └── Sentry MCP                            logs)

 Each app holds its own server         Each app holds one URL and one sign-in.
 list and tokens.                      Servers and credentials live in the gateway.

A typical request goes like this:

1. The agent authenticates to the gateway. Usually this is an OAuth sign-in in the browser; some gateways also accept a bearer token for scripts.
2. The client asks for the catalog. It sends tools/list (and the equivalents for resources and prompts). The gateway gathers capabilities from its connected servers and returns only the ones this agent is allowed to use.
3. The model picks a tool and the client sends tools/call. The gateway checks the call again: is this agent still authorized, is the tool still permitted, does it need a person to approve it first?
4. The gateway forwards the call to the upstream server using that connection's own credential, then returns the result.
5. The gateway records the operation: which agent, which server, which tool, the outcome and how long it took.

Step 3 matters more than it looks. A client can cache a tool name or a model can guess one, so a gateway should check every call, not just filter discovery.

For example, a coding agent and a support agent share one gateway connection to an issue tracker. The coding agent can search and create issues; the support agent can only search. The support agent never sees create_issue in its tool list, and a call to it would be refused anyway. The upstream account's permissions still apply: if the tracker account can't delete issues, no gateway rule can give an agent that ability.

MCP gateway vs server, proxy, registry, API gateway and LLM gateway

These terms overlap in marketing copy. What separates them is what each one decides.

A few clarifications:

• Gateway vs proxy. Some products called proxies aggregate servers, and some gateways call themselves proxies. Ask whether it enforces per-agent permissions and manages credentials, whatever the noun.
• Gateway vs registry. A registry isn't in the request path, so it can't stop a call. A gateway may include a catalog, but the catalog isn't what enforces access.
• MCP gateway vs API gateway. An API gateway understands HTTP routes. An MCP gateway understands MCP methods, so it can filter tools/list per agent and decide by tool name. If an API gateway advertises MCP support, check whether that includes tool-level rules.
• MCP gateway vs LLM gateway. An LLM gateway governs traffic to the model; an MCP gateway governs traffic from the agent to tools. You may run both.
• MCP server vs the API behind it. An MCP server can wrap an existing API; MCP vs API covers when an agent should call one or the other.

Authentication layers

A gateway adds a hop, so be precise about who authenticates to whom. There are three separate layers.

Client to gateway. The agent proves to the gateway who it is and which workspace or tenant it belongs to. For remote MCP this is normally OAuth, following the MCP authorization specification. Scripts and headless jobs may use a long-lived bearer token instead; treat that token like any other credential.

Gateway to upstream server. The gateway authenticates to each MCP server with that connection's credential: an OAuth token from the provider's sign-in, or an API token you supplied. This credential belongs to the gateway's connection record, not to the agent.

The upstream service's own permissions. The account behind the upstream credential still has its own roles and scopes. The gateway can narrow what an agent does with that account. It cannot widen it.

Keep the first two layers separate. A design where the agent's token is passed straight through to the upstream API is known as token passthrough, and the MCP specification forbids it: servers must not accept tokens that weren't issued for them. The MCP security best practices explain why it breaks audience checks, audit trails and rate limits. MCP authentication walks through the OAuth discovery, client registration and token rules behind each layer.

Tool allowlisting, approval and blocking per agent

A server might offer forty tools when an agent needs four. Per-agent rules usually take these forms:

• Allow. The agent may see and call the tool. A strict setup lists exact tool names. Some gateways also offer "allow everything on this server", which is convenient but means tools the server adds next month become available without review.
• Require approval. The agent may call the tool, but each call waits until a person reviews it. This suits tools that send messages, spend money, or change production data.
• Block. The agent can't see or call the tool, whatever other rule might allow it.

How rules combine matters as much as the rules themselves. A sane default is that a block beats an approval requirement, which beats an allow, regardless of which policy each rule came from. Otherwise a broad team policy can quietly undo a narrow restriction.

Client apps have their own versions of these controls. Claude Code, for example, supports allow, ask and deny rules for MCP tools, but those rules live on each developer's machine. The MCP allowlist guide compares client-side and gateway-side lists, and the Claude Code permissions guide shows how to combine the two.

Credential handling

Without a gateway, every developer keeps a token for each server in a local config file, sometimes in a repository by accident. Rotating a shared token means asking everyone to update their config.

A gateway stores credentials once per connection, ideally encrypted at rest, and agents never receive them. A team can share an approved account without handing out its token, and when someone leaves you revoke their agents at the gateway.

Centralizing credentials also concentrates risk. The gateway has to decrypt credentials to use them, and it sees traffic in transit. Ask where that happens and who can access it.

Activity logging

When an agent does something surprising, the first question is what it actually called. Every call passes through the gateway, so it can record the agent, server, method, outcome and timing of each one. Storing full arguments and results is a separate decision: useful for debugging, sensitive otherwise. A common pattern is metadata by default and payload capture only for a short, deliberate window. Check retention and export options too.

Tool-list bloat and context size

Each connected server adds tool definitions to the model's context. Five servers with thirty tools each means 150 definitions the model has to read before doing anything, and similar names across servers make it more likely to pick the wrong one. Some clients set hard limits: VS Code, for example, caps a chat request at 128 enabled tools. Others, like Claude Code, defer tool definitions and load them on demand.

A gateway helps from the other direction. Because discovery is filtered per agent, a support agent receives only the dozen tools it's allowed to use. The smaller list comes free with access rules you probably wanted anyway.

Security risks a gateway helps with, and ones it doesn't

A gateway is one layer. It addresses some of these problems and not others. MCP security risks covers each attack in more depth, with the controls that belong in the client, the server and the gateway.

Where a gateway helps:

• Over-broad access. Per-agent allowlists keep an agent to the tools its job needs, even when the upstream token is broad.
• Destructive calls. Blocking or requiring approval for delete, send and payment tools limits what a confused or manipulated agent can do.
• Credential sprawl. Tokens stay in one place instead of on every laptop, and agent access can be revoked centrally.
• Visibility. A single activity log shows what each agent called across servers.
• Some network attacks. A managed gateway that refuses private-network and localhost destinations reduces the server-side request forgery risk described in the MCP security best practices.

Where it doesn't:

• Prompt injection. Text in an email, issue or web page can still instruct the model to misuse a tool it's allowed to call. A gateway can limit the damage by limiting tools; it can't make the model ignore malicious content.
• Tool poisoning. A server can put misleading instructions in a tool's description or results. Allowing a tool means trusting its server. The MCP specification says clients must treat tool annotations as untrusted unless they come from trusted servers, and a gateway doesn't change who you trust.
• Over-broad upstream tokens. If the upstream account is an org admin, an allowed tool acts with admin rights. Pick upstream accounts and scopes with least privilege in mind.
• Harmful use of permitted tools. An agent allowed to update records can update the wrong ones. Approval for risky tools and narrow allowlists reduce this; they don't eliminate it.
• Traffic outside the gateway. If the agent also has a direct connection or a local token, the gateway's rules don't apply to that path.

The MCP tools specification says there should always be a human in the loop with the ability to deny tool invocations. A gateway's approval step is one way to provide that centrally, alongside the confirmation prompts in your client.

When you don't need a gateway

A gateway is another service in the request path, with its own availability, limits and data handling. You can reasonably skip it when:

• You're one developer using a couple of servers on your own machine, and your client's permission prompts already cover what you need.
• Your servers run locally over stdio and touch only local files. A remote gateway can't reach them, and adding one would mean exposing them on the network.
• Every agent needs the same access and nobody else shares the credentials.
• Your organization already enforces server and tool allowlists through client managed settings, and you don't need cross-client logging or shared accounts.

The case gets stronger when different agents need different access, the same servers are configured in several apps, or a team needs to share an account without sharing its token.

How to evaluate an MCP gateway

Start with the servers and clients you actually use, then work through this list:

• Connectivity. Which transports does it support? Can it reach the servers you need (public HTTPS, private network, local stdio)?
• Client support. Does it work with your AI apps' authentication flows, such as OAuth for remote connectors and bearer tokens for scripts?
• Enforcement point. Are permissions checked on every call, or only when filtering the tool list?
• Rule granularity. Can you allow, block and require approval per agent and per tool? Do resources and prompts get the same treatment?
• Rule precedence. When two policies disagree, which wins? Is that documented?
• New tools. What happens when an upstream server adds a tool? Is it allowed automatically or held until someone reviews it?
• Credentials. How are upstream tokens stored? Can a team share an account without exposing the token? Does the gateway avoid token passthrough?
• Logging and retention. What's recorded by default, are arguments stored, for how long, and can you export it?
• Revocation. Can you revoke one agent without disturbing the others?
• Limits and pricing. What counts as a billable unit, and what happens when you hit a limit?
• Operations. Managed or self-run? Where does it process data, and who handles updates and incidents?

If you're comparing products, the alternatives pages apply these questions to ten gateways and tool platforms, including self-hosted options such as Docker MCP Gateway and IBM ContextForge and managed ones such as Runlayer and MintMCP.

How Toolstile implements it

Toolstile is a managed MCP gateway for public HTTPS MCP servers. You add server connections to a workspace, point each AI app at https://mcp.toolstile.com/mcp, and sign in from the app. Each agent authorization belongs to one workspace and starts with no access.

• Per-agent rules. For each agent and connection you choose Allow, Require approval or Block per tool, with allow and block for resources and prompts. Tool entries use exact names. A block wins over Require approval, which wins over Allow or full access, across direct grants and reusable policies. Discovery is filtered with the same rules that are checked on every call. Permissions covers the details.
• Full access vs explicit lists. Full access includes tools the server adds later. Listing tools by name means a new tool stays unavailable until someone allows it.
• Approvals. When an agent calls a tool that requires approval, it gets back a result with a review link. In a personal workspace the connection owner reviews it; in a team workspace, owners and admins do. The approval covers that exact call with those exact arguments, and the agent then retries the same call.
• Credentials. Upstream OAuth tokens and bearer tokens are encrypted at rest. Team members can share an approved account without the dashboard showing its credential.
• Shared accounts. In a team workspace, a member can contribute their upstream account and an admin approves it for team use. Each agent still needs its own grant, and members can pick which approved account their agents use. Shared accounts explains the rules.
• Activity. Metadata is logged for each operation by default and kept for 30 days on Free and Starter, 90 on Team and 180 on Scale. Optional debug capture of arguments and results is off by default and expires within 24 hours. See security and data handling.
• Identity. Workspace members sign in with Google or email. The Scale plan adds SAML or OIDC single sign-on and SCIM user provisioning.
• Limits. Toolstile reaches public HTTPS servers on port 443 only. It doesn't run local stdio servers or connect to private networks.

The free plan includes 5,000 operations a month per workspace; pricing lists the paid plans. An operation is a forwarded tool call, resource read or prompt request. Listing tools doesn't count.

Set up Toolstile as your MCP gateway

The whole setup takes one remote MCP server and one AI app. Getting started walks through each step in more detail.

1. Create a workspace. Sign up and you get a free personal workspace. Create a team workspace when other people need the same connections.
2. Add a connection. Open MCP connections, choose Connect an MCP and paste a public HTTPS MCP server URL, then complete the provider's sign-in or enter its bearer token. The integrations directory lists server URLs, and connecting a server covers the options.
3. Point your AI app at the gateway. Add https://mcp.toolstile.com/mcp as a remote MCP server and sign in from the app. The browser asks which workspace this app should use. Each client has its own guide:
   • Claude Code: claude mcp add --transport http toolstile https://mcp.toolstile.com/mcp, then /mcp to sign in.
   • Codex: codex mcp add and codex mcp login, shared by the CLI, IDE extension and app.
   • Cursor: one entry in .cursor/mcp.json.
   • Claude Desktop and claude.ai: a custom connector.
4. Grant access. The new agent starts with no tools. Find it under Devices & agents, then in Access set each tool to Allow, Require approval or Block and save.
5. Check it. Test tool shows the agent's permitted tools without running one. Then ask the app for one read-only lookup and find the call in Activity.

Scripts and apps that can't run a browser sign-in can use an agent token from Connect an agent instead. If something doesn't show up, troubleshooting lists the usual causes.

Guides on MCP access and security

Each of these goes deeper on one part of this page:

• MCP authentication: OAuth 2.1 discovery, client registration, token audiences and agent tokens.
• MCP security risks: prompt injection, tool poisoning, token passthrough, SSRF and the controls for each.
• MCP allowlist: server and tool allowlists in Claude Code, Cursor, Codex and VS Code.
• Claude Code permissions: permission modes and allow, ask and deny rules for MCP tools.
• Claude Code --dangerously-skip-permissions: what bypass mode skips and how a gateway limits MCP tools once prompts are gone.

All guides also covers choosing MCP servers and setting up each AI app.

Frequently asked questions

Is an MCP gateway the same as an MCP proxy?

Not necessarily. Both relay MCP traffic, but "proxy" often means plain forwarding or transport conversion, while a gateway usually adds per-agent access rules, credential management and logging across many servers. Check the features rather than the label.

Does an MCP gateway replace the permissions in Claude Code, Cursor or Codex?

No. Client permissions control what the app does on one machine, including local tools like the shell and file edits. A gateway controls access to remote MCP servers for every app and person that uses it. Using both is normal; the Claude Code permissions guide shows one way to split the work.

Can a gateway give an agent more access than the upstream account has?

No. The upstream service checks its own account permissions on every call. A gateway can only narrow what an agent does with that account.

Does a gateway protect against prompt injection?

Only partly. It can't stop a model from following malicious instructions, but it limits what a manipulated agent can do by restricting tools and requiring approval for risky ones.

Which AI apps work with Toolstile?

Toolstile has setup guides for Claude Code, Codex, Cursor and Claude Desktop. Other clients that support remote MCP servers with browser (OAuth) sign-in can use the same URL, though MCP support alone doesn't guarantee a client's sign-in flow works. Scripts can use an agent token.

Do I need one gateway entry per app, or one per person?

One per app and workspace. Each sign-in creates a separate agent authorization tied to one workspace, so a coding agent and a chat app can have different access even for the same person. If you use a personal and a team workspace, add two separately named entries.

What does a gateway cost?

It depends on the product: per seat, per call, or a flat allowance. Toolstile prices per workspace with no seat fee: Free includes 5,000 operations a month, and paid plans start at $29 a month for 50,000. Forwarding stops at the allowance instead of billing overage. See pricing and how operations are counted.

Can I use a gateway with local MCP servers?

It depends on the gateway. Toolstile connects only to public HTTPS servers, so local stdio servers stay configured directly in your client. Other gateways run locally or inside your network for that purpose.