What is an MCP gateway, and when does your team need one?

MCP defines hosts, clients and servers, and it puts permission, consent and authorization decisions on the host. There is no gateway role. The nearest thing is the security best practices definition of an MCP proxy server: a server that connects clients to third-party APIs, offering MCP features while delegating operations and acting as a single OAuth client to the upstream service. That definition carries two obligations that shape every honest gateway.

First, no token passthrough. The authorization spec is categorical that an MCP server must not accept tokens that weren't issued for it and must not forward the token it received from the client upstream. So a gateway can't be a dumb pipe with a policy bolted on; it has to obtain and hold its own downstream credential, whether that's a per-person OAuth grant to Linear or a shared key for a database. Second, the confused-deputy rule: a proxy using a static client id upstream must get the user's consent for each client that registers with it before forwarding, so a malicious client can't ride an existing consent. On the practical side, the tools page notes that anything aggregating tools from several servers should disambiguate colliding names, usually by prefixing with a server identifier.

Everything else, including whether calls pause for a person, whether there's a record, and who may change the rules, is design space the spec leaves open. That's why two products both called gateways can behave nothing alike.

Compare three ways to run the same Linear server for a team. Direct means each host talks to mcp.linear.app itself. Host controls means direct plus the host's own permission rules, possibly centrally managed. Gateway means every host talks to one endpoint that talks to Linear.

The last row is the honest cost. A gateway is a single point on every governed call, and if it's down or slow, every agent feels it; Tier Two's own design notes are explicit that the hosted endpoint runs as a single deployment and that a restart makes hosts reconnect. You trade that dependency for the other five rows. Whether it's a good trade is what the rest of this article is about.

Stay direct when three things are true at once: one host per person, the person at the keyboard is the right reviewer for that person's calls, and the upstream server's own authorization already draws the line you want. A solo developer using Claude Code against Linear meets all three. Claude Code's allow, ask and deny rules can hold writes for a prompt, its managed settings file can stop the developer from loosening them, and Linear's read-only endpoint or read scope caps what the token can do. The human approval article walks through those native controls in detail, and they're better than most teams assume.

Adding a gateway to that setup buys administration without solving a problem you have. Write down why you're staying direct, including which host rules and which upstream restriction you're relying on, so that when the second person arrives you can check whether the reasons still hold.

Each of these is a control that can't be expressed on one machine.

• The same rule has to hold in two hosts. Claude Code and Cursor have different rule grammars, and a policy you maintain twice drifts.
• The reviewer isn't the requester. A data owner or a lead should approve, and they don't sit at the developer's keyboard.
• You need one answer to 'what did agents do to this system last week', across everyone, not a folder of transcripts.
• Modes should differ by resource, the finance project versus the sandbox, and the host grammar can only see tool names.
• The credential should be shared and narrow, not copied to every laptop, or should be a personal sign-in the person can revoke in one place.
• A new host shows up every quarter. Tier Two's setup command currently writes config for ten hosts, and only two of them, Claude Code and Cursor, are verified end to end; the rest follow each host's own docs. Every host you add to a direct setup is a new permission model to learn.

One signal is enough to justify looking. Two usually means you're already doing the gateway's job by hand, in a spreadsheet and a Slack channel.

The names collide and the traffic doesn't. An LLM gateway sits between your application and the model provider: it sees prompts and completions, routes between models, caches, meters spend, and redacts. An MCP gateway sits between the agent and the tools it calls: it sees tools/list and tools/call, and the credentials that make those calls real. A prompt injection in a fetched web page travels through an LLM gateway untouched, because it's just text in a completion; the only place it can be stopped is at the tool call it tries to trigger.

Teams sometimes reach for one when they need the other. If the worry is cost and model choice, that's the LLM gateway. If the worry is what an agent did to Linear, that's this one.

Agents connect to one hosted MCP endpoint, trytiertwo.com/mcp, and sign in through the host's normal OAuth flow, so every call arrives attributed to a person and an agent. The workspace adds connections, each one MCP server plus a credential in one of three shapes: the person signs in to the system through the connection and calls run as them; a shared workspace key that's decrypted only for the call that needs it; or a personal API key. Tools appear to agents as connection__tool, for example linear__save_issue, so two servers with a create tool never collide.

The tool list is read once and pinned; refreshing shows a diff, and new tools arrive with the connection's preset mode rather than silently widening what agents can do. Every tool carries one of three modes. Allow runs the call and records it. Ask holds it and shows an admin who's asking, from which agent and host, which tool, and a truncated argument preview, then forwards the original call on approval or refuses it on denial or after fifteen minutes of silence. Block refuses the call and hides the tool from tools/list. Two append-only ledgers record every call and every change to the rules, and on the Enterprise plan they stream to a SIEM about every five minutes. The connections documentation covers the credential shapes and what a shared key implies.

The setup command, npx -y tiertwo, registers the endpoint in each host it finds and then offers to remove the direct entries for servers the workspace now governs, so the agent has one door rather than two; that step is opt-in and reversible. There's no self-hosted version, token revocation can take up to a minute to reach the endpoint, and the Free plan covers three people and three connections.

A gateway governs the calls that pass through it, and only those. If a host keeps a direct entry to the same server, the agent has a second door, and if the agent has a shell, a browser tool or a plain HTTP client, it has doors that aren't MCP at all. No MCP gateway changes that, and one that claims to is describing a different product.

It can't make a server's tool descriptions or annotations trustworthy; the spec says clients must treat annotations as untrusted unless the server is, and a gateway inherits that stance. It can't add access the downstream credential lacks; an approval releases a call, it doesn't grant a permission. It can't filter arbitrary arguments, which is why Tier Two offers a mode per tool and a scope on one declared argument rather than an allow-list of inputs. And a reviewer seeing a call isn't the same as understanding it: the preview is truncated, and a queue long enough to skim gets skimmed. A gateway is worth having for the rows in the table above. It's not a reason to stop reading the permissions matrix.