Type "mcp proxy" into a search bar and you will find at least four products calling themselves one, each doing something slightly different underneath. That is not marketing sloppiness. It is because "proxy" names a technical pattern, not a single product, and the pattern covers real jobs that genuinely differ from each other. This piece is about the pattern itself: what it is, why teams reach for it, and the specific place it stops being convenient and starts being a liability.
What an MCP proxy actually is
An MCP proxy is dual-natured by definition. To whatever connects to it, agent, IDE plugin, chat client, it presents itself as an ordinary MCP server, answering tools/list and tools/call like any other. To whatever it forwards a request to, it acts as an MCP client, opening its own connection, holding its own credentials, and making the same kind of calls an agent would make directly.
That dual role is the whole mechanism. Once you see the pattern this way, every proxy variant reduces to a question of what happens in between those two hops.
Aggregation
The most common reason to build one is to collapse many servers into one address. An agent that would otherwise need separate connections, and separate credentials, for a filesystem server, a database server and a ticketing server instead talks to one proxy, which fans the call out to whichever backend actually owns the tool being called. This is genuinely useful when the number of servers is large and the client software only wants to manage one connection.
Transport translation
MCP supports more than one transport, and not every client and server agree on which one to use. A client that only speaks Streamable HTTP cannot talk directly to a server that only exposes STDIO. A proxy sitting in between can launch the STDIO server as a subprocess, speak to it locally, and re-expose it over HTTP to the remote client. FastMCP's proxy server, an open-source implementation, is a straightforward example of this: it lets a proxy front an existing server regardless of which transport that server was originally built for.
Policy enforcement
The third job is the one this post cares about most: putting a checkpoint where the protocol itself does not require one. MCP's own specification leaves authorization largely optional and implementation-defined, which is exactly why mcp security explained found such a wide spread of outcomes across real deployments. A proxy is one place teams add the check the spec does not mandate, whether that is verifying a caller's identity, rate-limiting a noisy client, or logging every call for an audit trail a single unguarded server would never produce on its own.
Where a proxy earns its keep
None of the three jobs above are theoretical. A team running a dozen internal MCP servers, one per data system, has a real operational reason to want one address instead of a dozen. A team migrating an older STDIO-only tool into a fleet of cloud agents has a real reason to want transport translation rather than a rewrite. And a team that has read the authentication numbers, 40.55% of measured live servers with no authentication at all, has a real reason to want a single, auditable checkpoint rather than trusting each server to have built its own.
| Pattern | What it does | What it does not do | Where the risk sits |
|---|---|---|---|
| Transparent passthrough proxy | Exposes every tool of every connected server automatically, the moment it is added | Decide who may call which tool, or check what a specific caller should see | Inherits every upstream server's own auth posture, unfiltered |
| Allowlisted / governed proxy | Exposes only tools an administrator has explicitly enabled, scoped and classified as read or write | Rank or rewrite what a passthrough call returns; entitlement gates the call, not the answer | Narrower: limited to the enabled surface, but still only as good as the scopes assigned |
| Registry-only lookup | Lists what servers exist and how to install them, with no calls flowing through it at all | Anything at runtime; it is a directory consulted before connecting, not a component in the request path | None at call time, because it never sits in the call path |
Table 1: three things that get called "MCP infrastructure" in the same conversation, doing three different jobs. The middle row is where a governed layer sits; what an MCP registry does not do covers the third row in full.
Is a transparent MCP proxy safe?
This is the question worth sitting with, because "transparent" is doing a lot of work in that phrase. A transparent proxy is one where connecting a server is the whole configuration step: every tool that server exposes becomes callable through the proxy immediately, under its own name, with no administrator decision in between.
That convenience is also the failure mode. A proxy that forwards everything by default forwards whatever the upstream server was built to expose, including tools an operator never meant to hand an agent, and including the authentication gaps documented across the live server population. The proxy adds a hop. It does not add a check, unless the proxy was specifically built to add one, and "drop in mcp proxy" as a category promise usually means exactly the opposite of that: point it at a server and everything on the other side becomes reachable at once.
"MCP proxy servers using static client IDs MUST obtain user consent for each dynamically registered client before forwarding to third-party authorization servers (which may require additional consent)."
Model Context Protocol specification, Authorization, on the confused deputy problem
That single requirement exists because a proxy is exactly the shape of thing the confused deputy problem targets: something acting on a caller's behalf, holding broader privileges than any one caller should have, forwarding requests toward third parties the original caller never explicitly authorized. The specification is equally direct on the related point that a server receiving a token "MUST NOT pass through the token it received from the MCP client" to an upstream API, precisely because an unmodified, forwarded token is how one caller's credential ends up doing work for a system it was never issued against.
Why does this matter more for an agent than a browser?
A person clicking through a proxied web request notices when something looks wrong. An agent reading a tool description as part of its own reasoning does not have that instinct, and a transparently proxied tool list hands an agent every upstream tool's name and description as though the proxy itself had vetted them. It has not. It relayed them. The agent cannot tell the difference between a tool the proxy operator reviewed and one it merely passed through, unless the proxy's own design makes that distinction visible.
MCP proxy vs MCP gateway: what's the actual difference?
In most vendor writing the two words are used interchangeably, and there is no strict, universally agreed line between them. Where a distinction is worth drawing, it is this: "proxy" names the mechanism, a server that is also a client, sitting between two ends of a connection. "Gateway" usually names a product built around that mechanism, adding the things a network chokepoint is good for: identity provider integration, rate limiting, and audit logs formatted for a compliance framework. MCP gateway vs permissioned context layer walks through two named products, MintMCP and Kong, that fit the gateway description, and both are proxies underneath in the strict technical sense, just with a policy and identity layer wrapped around the proxying.
The practical upshot is that asking "proxy or gateway" is usually the wrong question. The right one is narrower: does this piece of infrastructure expose an upstream tool automatically once a server is connected, or only once an administrator has made a deliberate decision about that specific tool? That is the line that determines whether the 40.55%-with-no-authentication problem gets inherited wholesale or filtered at the door.
How to set up an MCP proxy without inheriting the whole upstream surface
If the goal is aggregation or transport translation and nothing more, an open-source proxy like FastMCP's is a reasonable, well-documented starting point, and its own guidance on upstream authentication is worth reading before connecting anything with real credentials behind it. Three questions are worth answering before that first connection, regardless of which implementation is doing the proxying:
- Does every upstream tool become callable the moment the server is added, or is there a step where somebody decides which tools should be reachable at all?
- Is a tool ever classified as read versus write before it is exposed, or does a mutating action look identical to a lookup from the proxy's point of view?
- If a call is refused, is that refusal logged the same way a successful one would be, so a denied attempt leaves the same trail a completed one does?
A proxy that cannot answer those three questions with anything but "everything, automatically, and only successes are logged" is a transparent proxy, and it is worth knowing that going in rather than discovering it during an incident review.
Where Contextely sits in this pattern
Contextely is not a transparent MCP proxy, and that distinction is deliberate rather than a limitation to work around. It can route a live call to an upstream read tool through two of its own catalogue entries, source_tools_list and source_tool_call, documented in full on the MCP tool catalogue. But a tool only becomes reachable through that path once an administrator has enabled it specifically, filed it as a read or a write, and named the scope it requires. Pointing Contextely at a server does not expose that server's tools on its own, which is the exact behaviour a transparent, drop-in proxy would give you instead.
The other half of that design worth stating plainly: a passthrough answer through this path is not ranked, scored, or rewritten. Entitlement decides whether the call happens at all, not what comes back once it does, and the reply is exactly what the upstream system gave, logged either way. The MCP pillar page states both limits in public, alongside the two other constraints the product carries today, with the entitlement ordering written against the actual code rather than described from a distance.
Frequently asked questions
The pattern underneath "MCP proxy" is not going to change: a component that is a server to one side and a client to the other will keep showing up wherever aggregation, translation or policy enforcement is needed. What is worth tracking is which specific behaviour a given product ships, because "proxy" alone tells you almost nothing about whether it forwards everything by default or only what an administrator chose. MCP authentication patterns covers the four credential shapes a proxy might be holding on the upstream side, and each one fails in a genuinely different way once something goes wrong.