On this page
Put Coworker to work on your stack.
Connect Salesforce, Slack, Jira and run your first agent in minutes.
Enterprise AI
MCP Gateway: What It Is, What It Does, and How to Choose One
What an MCP gateway is, how it differs from an LLM gateway and an API gateway, what it does in practice, and how to evaluate the options.
What is an MCP gateway?
An MCP gateway is an infrastructure layer that sits in front of one or more Model Context Protocol servers and gives AI clients a single, governed entry point to all of them. Instead of each agent or editor connecting directly to a GitHub server, a Postgres server, a Slack server and half a dozen others, every client connects to the gateway, and the gateway handles routing, authentication, access control and logging on the way through.
Kong's definition (June 10, 2026) frames it as a reverse proxy and management layer, and makes the important point that the protocol does not ask for one: "The MCP specification doesn't mandate it. Yet production deployments demand it." TrueFoundry's guide (May 21, 2026, by Ashish Dubey) puts the same idea more sharply: if MCP defines how models talk to tools, an MCP gateway defines who is allowed to speak and under what conditions.
The structural point is that nothing changes from the agent's side. The client still performs a `tools/list` handshake and still issues tool calls. Those requests are simply intercepted, evaluated and routed before any backend system executes them. That interception is the whole product. Everything an MCP gateway does for you, it does because it is the one place every tool call has to pass through.
If you are new to the protocol underneath all this, start with what MCP is and come back. The rest of this guide assumes you already know what a server and a client are.
The problem it solves: N clients times M servers
MCP launched in November 2024, and Anthropic's own engineering team describes the adoption curve since then as rapid, with thousands of community servers built on it (Anthropic, November 4, 2025). That growth is exactly what creates the problem.
Picture a realistic mid-sized setup. You have five agents or AI surfaces in play: a support agent, a sales agent, an analytics agent, a code review agent, and whatever your engineers have configured in Cursor and Claude Code personally. Each needs some subset of Slack, GitHub, Linear, HubSpot, Jira, Google Calendar and Postgres. Without a shared layer, that is a mesh of direct connections. Composio's comparison piece (May 27, 2026, by Dumebi Okolo) names it the N times M integration problem: N agents connecting directly to M tools produces a number of connections nobody can manage by hand.
The consequences are not abstract. They show up in five specific places.
Credentials multiply. Every client that connects directly to a server needs its own copy of a token. A personal access token for GitHub lives in one engineer's config file, another copy lives in the support agent's environment, a third in a CI job someone set up in March. There is no single place to see who holds what.
Revocation stops being a single action. When someone leaves, or when a token leaks, "revoke access" means finding every machine and every config that holds a copy. Most teams discover during this exercise that they do not have a list.
Configuration sprawls. Adding a sixth server means editing every client that needs it. Rotating an endpoint means the same. The work grows with N times M, which is the point.
Visibility disappears. There is no shared record of which tool calls happened, by whom, with what arguments. Each client has its own logs in its own format, if it logs at all. This is the single most common thing security teams ask about first, and the hardest to retrofit.
Context gets expensive. Every server a client connects to loads its tool definitions into the model's context window. This is the part teams underestimate most, and it deserves its own section below.
A gateway collapses the mesh into a hub. Clients know one endpoint. Credentials live in one vault. Policy is written once. The audit log has one schema. That is the trade: you add a hop and an operational dependency, and in exchange the management problem stops scaling with the number of clients.
MCP gateway vs LLM gateway vs API gateway
This is the distinction people search for most, and the one most often blurred by vendors who sell more than one of the three. The clean way to hold it: all three are control layers between clients and servers, and they differ by the traffic they govern.
An API gateway governs ordinary service traffic, the HTTP and gRPC requests between your own services. It is the original concept, it was designed for stateless request and response patterns, and if you run microservices you almost certainly have one already.
An LLM gateway governs calls to language models. Provider routing, fallback when one provider rate limits you, prompt caching, token-aware spend controls, guardrails on prompts and completions. We have a full explanation of what an LLM gateway does if that is the layer you actually need, and it is worth reading before you buy anything, because a meaningful share of teams who say "MCP gateway" describe an LLM gateway problem.
An MCP gateway governs agent-to-tool traffic over the Model Context Protocol. Routing to the right server, credential brokering, session state, tool-level access control, audit logging of what the agent actually did.
Composio's framing is the most memorable version: the API gateway protects normal app traffic, the LLM gateway governs thinking traffic, and the MCP gateway governs acting traffic. Speakeasy makes the same cut from the other direction: the LLM gateway governs what goes into and out of the model, the MCP gateway governs what the model does.
| Capability | API gateway | LLM gateway | MCP gateway |
|---|---|---|---|
| Traffic governed | Service HTTP and gRPC | Model inference calls | Agent tool calls over MCP |
| Primary question answered | Can this service call that one? | Which model, at what cost? | Which tool, on whose behalf? |
| Routing | Yes | Yes, across model providers | Yes, across MCP servers |
| Auth and access control | Yes | Yes, usually per key or team | Yes, usually per user and per tool |
| Rate limiting | Request based | Token and cost aware | Session and tool-call aware |
| Credential brokering for third-party tools | No | No | Core feature |
| Session and state management | No | Rarely | Core requirement, sessions persist |
| Streaming | Sometimes | Common | Core requirement |
| Prompt and response guardrails | No | Common | Can inspect tool arguments and results |
| Tool discovery and filtering | No | No | Core feature |
| Typical failure it prevents | A service gets hammered | Spend runs away, one provider goes down | An agent touches data it should not |
The three are complementary. A mature agent platform often runs all of them, stacked: the API gateway at the perimeter, the LLM gateway in front of the model, the MCP gateway in front of the tools. If you only run one today and you are adding agents, the question is not which to replace. It is which layer your current incidents are happening at.
There is a related distinction worth being precise about, because it comes up in the same searches: MCP versus a plain API is a protocol question, not a gateway question. MCP is how the model discovers and calls a capability. The API is what sits underneath. A gateway can front either.
What an MCP gateway does in practice
Vendor pages tend to list the same six or seven capabilities. Here is what each one actually means when you are the person operating it.
Authentication and credential brokering
This is the capability that justifies the category on its own. Without a gateway, every agent holds its own credentials for every tool, which means one compromised agent exposes credentials for every service it touches.
A gateway inverts that. The client authenticates to the gateway once, usually through your existing identity provider. The gateway holds the downstream credentials, encrypted at rest, and attaches them per request. Raw secrets never reach the agent, the model, or the developer's laptop.
The mechanism that makes this more than a shared password vault is identity propagation. In many real deployments an agent acts on behalf of a specific human, but connects to the backend as a single shared service account, which flattens every permission model underneath it. A gateway can instead inject the authenticated user's identity downstream via OAuth or OIDC tokens, so the CRM still sees an individual AE and still applies the record-level rules it always did.
The strongest current pattern here is token exchange. Red Hat's engineering team documented an implementation (December 12, 2025) that uses RFC 8693 to swap a broad access token for a narrowly scoped token specific to each MCP server, so a compromised downstream server cannot replay a token that works everywhere else.
It is worth knowing why this falls to the gateway rather than the protocol. The MCP authorization specification is explicit that "Authorization is OPTIONAL for MCP implementations," and that servers using stdio transport should not follow it at all and should instead retrieve credentials from the environment. That is a reasonable design decision for a protocol. It also means a local stdio server is, by spec, inheriting whatever is on the machine.
Tool discovery and filtering
An MCP gateway sits on the `tools/list` response, which is a more powerful position than it first sounds. It can present a curated surface: this team sees these forty tools, that team sees a different twelve, and nobody sees the destructive ones unless they have been granted them.
Red Hat's implementation filters `tools/list` against a cryptographically signed header carrying the caller's permissions, so the filtering is enforced rather than advisory. Obot builds the same idea into a product feature by letting you compose a virtual server that exposes selected tools drawn from several real ones.
Filtering does double duty. It is an access control mechanism, and it is also the main lever you have on context cost and agent accuracy, which is the next section.
Access control per user, team, or agent
Role-based access on its own is table stakes and is usually not enough. The useful granularity is the individual tool, and increasingly the individual argument. "Sales can reach HubSpot" is a weak policy. "Sales can call `hubspot_search` and `hubspot_read`, not `hubspot_write`, and never on records flagged confidential" is a policy that survives a review.
Good gateways express this per user and per identity-provider group, so that access is derived from your existing directory rather than maintained as a second list that drifts. If you have to maintain group membership twice, you will eventually maintain it wrong.
Audit logging
"The AI queried Salesforce" is not an audit trail. A usable one records which human, through which client, called which tool, with which arguments, against which server, at what time, and what came back. Microsoft's guidance on running MCP behind API Management makes the operational version of the point: capture which user invoked which tool with what arguments, and ship it to your existing log analytics or SIEM rather than inventing a parallel system.
Two practical notes. First, arguments frequently contain sensitive values, so redaction at write time is a requirement, not a nicety. Second, the log is only as complete as the coverage of the gateway. A gateway that ninety percent of traffic bypasses produces an audit trail that is worse than none, because it looks authoritative.
Rate limiting and quotas
Agents fail differently from humans. A retry loop that a person would abandon after three attempts, an agent will run four hundred times in a minute, and the first thing you learn about is the downstream API's rate limit, not yours. Gateway-level limits, per user and per tool rather than only per endpoint, are what keep one badly-behaved agent from getting the whole organization throttled by a vendor.
Cost control lives here too. If your tool calls trigger billable downstream operations, the gateway is the only place you can enforce a ceiling across every client at once.
Observability
Separate from audit, which is for compliance, observability is for operations: latency per server, error rates per tool, which tools are actually used, which have never been called since the day someone added them. OpenTelemetry export is the common denominator, and IBM's ContextForge, among others, ships it natively.
The unglamorous payoff is usage data. Most teams who instrument this discover a long tail of tools nobody calls, which is the cheapest possible input to the filtering decision above.
Network isolation
A smaller capability with outsized value in regulated environments. Fronting external MCP servers behind the gateway keeps developer machines off the public internet and gives you fixed egress IPs to allowlist. Docker's approach goes further at the process level by running each MCP server in an isolated container with restricted privileges, network access, and resource usage.
Coworker
Put Coworker to work on your actual stack
Connect Salesforce, Slack, Jira and run your first agent in minutes.
The part teams underestimate: tool sprawl is a correctness problem
The most common reason a team reaches for an MCP gateway is security. The most common reason they keep it is context.
Every MCP server a client connects to loads its tool definitions into the model's context window before the user types anything. Anthropic's engineering team documented the shape of this in Code execution with MCP (November 4, 2025): most clients load all tool definitions upfront, and agents connected to thousands of tools "need to process hundreds of thousands of tokens before reading a request." In the worked example in that post, switching from loading everything upfront to loading only what the task needs took token usage from 150,000 to 2,000, a 98.7% reduction.
That is the cost side. The accuracy side is worse, and better measured than most people realize. Speakeasy ran a controlled test by generating an MCP server with 107 tools from a single API, one per dog breed, then progressively cutting it down:
| Tools exposed | Result |
|---|---|
| 107 | Models frequently failed to select a tool and hallucinated tool names based on patterns in the naming |
| 40 | Three of four calls correct, one hallucinated endpoint |
| 20 | 19 of 20 calls correct, one hallucinated |
| 10, curated | All calls correct, no errors |
| 10 + 10, two focused servers | All calls correct across both servers |
The finding that matters for gateway buyers is the last row. Two focused servers of ten tools each worked, while one server of 107 did not. The variable is not how many servers you connect. It is how many tool definitions reach the model at once. Speakeasy's own summary of the thresholds: around thirty tools, descriptions start to overlap and create confusion, and past a hundred, models are close to guaranteed to fail at selection.
This is why tool filtering belongs on the buying checklist next to auth rather than three rows below it. A gateway that presents a per-team or per-task tool surface is not doing a cosmetic tidy-up. It is the difference between an agent that picks the right tool and one that confidently picks the wrong one. Anthropic's post frames the general fix as loading definitions on demand rather than upfront, which is the same principle a filtering gateway applies at the policy layer.
If you are still deciding which servers to connect at all, how to choose MCP servers for your team covers the selection criteria that feed this.
What breaks without a gateway
The security case for a gateway is not hypothetical. It rests on a specific, documented research record.
Tool poisoning. Invariant Labs published the foundational work here on April 1, 2025. A tool poisoning attack embeds instructions inside an MCP tool description that the model reads and the user never sees, because clients show a simplified version in the UI. The demonstrated payloads instructed models to read local files such as SSH keys and exfiltrate the contents while concealing the action. Microsoft's developer platform team describes the same class as a subset of indirect prompt injection, noting that compromised descriptions can manipulate the model into tool calls that bypass the controls meant to prevent exactly that.
Cross-server shadowing. The nastier finding in the same research: because an agent sees every connected server's tool descriptions at once, a malicious server can inject instructions that change how the agent behaves toward a different, trusted server. Your carefully reviewed internal server is not isolated from the unreviewed one a developer added last week. They share a context window.
Rug pulls. A server can present a benign tool definition at install time and a different one later. Invariant's public reproduction code includes a sleeper variant that changes its tool interface only on the second load, which defeats approval flows that check once.
Toxic flows. Invariant, now the research division of Snyk, later generalized the pattern to toxic flow analysis (July 29, 2025), modelling the sequences of tool calls an agent can make and identifying combinations that create an exfiltration path even when no single tool is malicious. The public GitHub MCP exploit is the canonical example: a prompt injected into an issue in a public repository, read by an agent that also has access to private ones.
Ordinary implementation bugs, at ecosystem scale. These are not all exotic. CVE-2025-53100 is plain command injection in the Codehooks.io MCP server, patched in version 0.2.2 (NVD). JFrog's research team disclosed CVE-2025-6515 in the Oat++ MCP implementation, where predictable session IDs allow an attacker to hijack another user's session and inject prompts into it.
Protocol-level traps the spec itself flags. The MCP authorization specification explicitly forbids token passthrough and calls out the confused deputy problem, where a server acting as an intermediary to a third-party API can be manipulated into obtaining access tokens without user consent. The current security best practices guidance (July 28, 2026) states that MCP proxy servers must implement per-client consent to prevent it.
A gateway does not make any of this go away. Be clear-eyed about that: a poisoned tool description passed through a gateway is still a poisoned tool description. What a gateway gives you is the three things you cannot have without a chokepoint. A place to review and approve servers before anyone can reach them. A place to inspect, reject or rewrite requests and responses in flight. And a record afterwards of exactly what was called, which is the difference between an incident you can scope and one you cannot. Our deeper treatment of the threat model is in MCP security.
Self-hosted vs managed
The market splits cleanly into two shapes, and the split matters more than any individual feature.
A self-hosted gateway is software you run. You point it at MCP servers you also run or trust, you hold the credentials in your own secret store, and traffic never leaves your network. Docker's gateway, IBM's ContextForge and Obot are all in this category, and all three are genuinely open source.
A managed platform hosts the gateway and, usually, the connectors behind it. You authenticate once, and the tools are already there. Composio and Coworker sit here. TrueFoundry occupies a middle position by design, deploying its gateway inside your own cloud account.
| Self-hosted | Managed | |
|---|---|---|
| Who holds downstream credentials | You, in your own secret store | The vendor, encrypted at rest |
| Where traffic flows | Inside your network | Through the vendor |
| Time to first working connection | Days to weeks, depending on your platform team | Usually under an hour |
| Who maintains the connectors | You, including every upstream API change | The vendor |
| Data residency control | Complete | Whatever the vendor offers |
| Cost shape | Infrastructure plus engineering time | Subscription |
| Failure mode you own | The gateway going down is your incident | Vendor outage, with a status page and no fix from you |
| Best fit | Regulated environments, strong platform teams, unusual internal systems | Teams who want governance without building a platform |
Two honest observations that cut against the usual framing.
The hidden cost of self-hosting is rarely the gateway. It is the servers behind it. Running your own gateway means somebody owns the Slack MCP server, the Salesforce MCP server, the Jira MCP server, and every breaking change those upstream APIs ship. That is a standing maintenance commitment, and it is the reason self-hosted deployments often stall after the third connector.
The hidden cost of managed is scope. A managed platform governs the tools it carries. If you also run three internal MCP servers wrapping proprietary systems, most managed platforms cannot front those, and you end up with two paths and a split audit trail. Ask this question early, because it determines whether you need one gateway or two.
The vendor landscape, honestly
Nobody owns this category yet. The AI-generated answers on this topic cite a rotating set of vendors, none of which is a canonical reference, which tells you the market is roughly eighteen months old and still sorting itself out. Here is a fair reading of the real players, with what each is genuinely good at.
| Vendor | Shape | Open source | Strongest at |
|---|---|---|---|
| Docker MCP Gateway | Self-hosted CLI and runtime | Yes | Container isolation and local developer workflow |
| IBM ContextForge | Self-hosted proxy and registry | Yes, Apache-2.0 | Federating MCP, A2A and REST behind one endpoint at scale |
| Obot | Self-hosted or cloud control plane | Yes, MIT | Identity-based access policy and virtual composite servers |
| Kong | Commercial platform | Gateway core is open source | Teams already running Kong for APIs |
| TrueFoundry | Gateway in your own cloud | No | Regulated enterprises wanting managed software on private infrastructure |
| Composio | Managed endpoint plus connectors | No | Getting many tools working fast, per-team scoped endpoints |
Docker MCP Gateway was announced July 9, 2025 as an open source project, and its distinguishing idea is process isolation: it runs each MCP server as a container with restricted privileges, network access and resource usage, rather than as a process inheriting your shell. It handles secrets through Docker Desktop, supports OAuth flows for servers that need them, and manages server lifecycle and discovery from one config. Its security model documentation is unusually candid, including details like requiring a bearer token by default on HTTP transports and rejecting tool names that collide across enabled servers. Genuine strength: if your objection to MCP is "I do not want arbitrary npm packages running unsandboxed on developer laptops," this addresses that directly and for free. Genuine limit: it is developer-workstation shaped first, and organization-wide identity governance is not its center of gravity.
IBM ContextForge is the most architecturally ambitious of the open source options. It is Apache-2.0 licensed and federates MCP servers, A2A agents and REST or gRPC APIs behind one endpoint, with centralized discovery, auth, retries, rate limiting, OpenTelemetry observability and a plugin system. It deploys via PyPI or Docker and scales to multi-cluster Kubernetes with Redis-backed federation. Genuine strength: if you want one endpoint covering MCP and your existing REST estate, with real observability, this is the most complete free option. Genuine limit: it is infrastructure, and it expects a platform team. Nothing here is a weekend project.
Obot is MIT licensed and takes the governance angle most directly. Its gateway proxies MCP servers whether Obot hosts them or not, lets you build composite servers that expose selected tools drawn from several real ones, controls access by user or identity-provider group, manages MCP OAuth alongside shared credentials and Kubernetes secret bindings, and can inspect, reject or modify requests and responses through filters or webhooks. Genuine strength: the access model is the product, and being fully open source means you can audit that model rather than trust a datasheet. Genuine limit: it is a newer project than the incumbents it competes with, and self-hosting a control plane is a real commitment.
Kong comes at this from twenty years of API gateway credibility, which is not nothing. Its argument is continuity: if Kong already terminates your API traffic, adding AI and MCP traffic to the same control plane means one policy language, one set of plugins, one operations team. It ships a separate AI Gateway and an MCP Registry alongside the core gateway. Genuine strength: for a platform team already running Kong, this is the lowest-friction path to governed MCP and the answer with the fewest new things to learn. Genuine limit: if you are not already a Kong shop, you are adopting a large platform to solve one problem, and the MCP-specific pieces are newer than the brand suggests.
TrueFoundry targets regulated enterprises and deploys the gateway inside your own cloud environment, which resolves the data residency objection without making you maintain the software. Its published material is unusually good on identity propagation, specifically the problem of agents collapsing into a shared service account, and its documentation of per-server RBAC with structured audit logs inside the customer VPC is written for the security reviewer rather than the developer. Genuine strength: the "managed software, private infrastructure" position is a real gap in the market and they occupy it deliberately. Genuine limit: closed source, and it arrives as part of a broader AI platform, so evaluate whether you want the rest of it.
Composio is the most connector-rich of the managed options and the fastest to a working setup. Its MCP Gateway gives each team a scoped endpoint carrying only the tools that team needs, with credentials managed centrally so no agent handles raw secrets, and it publishes genuinely useful conceptual writing on the category. Genuine strength: breadth and speed. If the goal is many tools working across many agents this week, this is the shortest path. Genuine limit: it is a developer platform first, so the governance features are organized around teams and endpoints rather than around an enterprise identity and compliance model, and your credentials live with the vendor.
An evaluation checklist
If you are shortlisting, these are the questions that actually separate options. The order is deliberate: the first four decide the outcome, the rest decide how pleasant it is.
| # | Question | Why it decides things |
|---|---|---|
| 1 | Where do downstream credentials live, and who can read them? | This is the whole security posture in one question. If the answer is "in each client," the gateway is not solving your problem |
| 2 | Does it propagate the end user's identity downstream, or use a shared service account? | A shared account flattens every permission model behind it, and no amount of gateway-side RBAC restores it |
| 3 | Can access be scoped to an individual tool, not just a server? | Server-level access is usually far too coarse. Read and write live on the same server |
| 4 | Can it filter `tools/list` per user or team? | Both an access control and the main lever on context cost and tool-selection accuracy |
| 5 | What exactly is in the audit log, and can it reach your SIEM? | Ask to see a real log line. "Full audit logging" covers a wide range of realities |
| 6 | Are tool-call arguments redacted before they are stored? | Arguments carry customer data. Your log becomes a new data store the moment it does not redact |
| 7 | Does it support OAuth 2.1 with per-server token scoping or exchange? | Per RFC 8693, this contains the blast radius of a compromised downstream server |
| 8 | Can it front MCP servers it does not host? | Decides whether your internal servers get one audit trail or a second, separate one |
| 9 | What happens to sessions when the gateway restarts? | MCP sessions are stateful. Restart behavior is where the theory meets a reconnect storm |
| 10 | Rate limiting per user and per tool, or only per endpoint? | Agents retry in ways humans do not. Endpoint-level limits do not stop one bad loop |
| 11 | Is there an approval step before a new server becomes reachable? | Without it, the gateway is a router, not a control point |
| 12 | Who maintains the connectors when an upstream API changes? | The real cost of self-hosting, and the question most often skipped |
| 13 | Does it support your identity provider natively, including groups? | If group membership has to be maintained twice, it will drift |
| 14 | What is the observability story: metrics, traces, or just logs? | OpenTelemetry export is the practical common denominator |
| 15 | Has it been through an external security review? | Newer projects in this space often have not, which is a fact to weigh rather than a disqualification |
A note on sequencing that will save you time. Answer questions 1 through 4 before you book any demos. They eliminate more than half of most shortlists in about twenty minutes of documentation reading, and they are the questions vendors are least likely to volunteer.
Rolling one out without stalling your teams
The failure mode of an MCP gateway project is not technical. It is that the gateway ships, developers find it slower or more restrictive than their existing direct connections, and they quietly keep the direct connections. You then have a gateway with partial coverage, an audit log that looks complete and is not, and a false sense of control. This is the worst of the available outcomes, and it is the common one.
Three things prevent it.
Start with the servers people already use, not the ones you wish they used. Inventory what is actually connected today across editors and agents. The list is usually longer than expected and contains at least one thing nobody remembers approving. Migrate those first, because coverage is worth more than curation early on.
Make the gateway path the easier one. If connecting through the gateway means one URL and an SSO login, while the direct path means finding and pasting a personal access token, adoption takes care of itself. If it is the reverse, no policy will hold.
Set the default tool surface small and let people ask for more. This is counterintuitive for a rollout, but it follows directly from the measurements above: a smaller tool surface makes the agent work better, so the restriction produces a better experience rather than a worse one. Requests to add tools are also the cheapest usage signal you will ever get.
Then measure the thing that matters, which is the fraction of tool calls that pass through the gateway. Everything else in the deployment is downstream of that number.
Where Coworker MCP fits
Coworker MCP is a managed governed connection rather than a self-hosted proxy, and it is worth being precise about what that does and does not mean.
One connection gives any MCP-compatible client access to 50+ connected tools, including Slack, Jira, Salesforce, GitHub and Google Drive, plus the organizational memory built across them. It works with Claude Code, Cursor, ChatGPT, Windsurf, or any MCP client, so teams keep the tools they already use. Queries respect your existing permission model, meaning users reach only the data they were already authorized to see in Coworker rather than whatever a shared service account can reach. It is SOC 2 Type II certified and GDPR compliant, and setup typically takes under 30 minutes. Pricing is Pro at $29.99 per user, Max at $149.99, and Enterprise custom.
What it is not: a generic proxy that fronts arbitrary third-party MCP servers you have deployed yourself. If your requirement is "put a policy layer in front of the eleven MCP servers my platform team already runs," an open source gateway like ContextForge or Obot is the more honest fit, and we would rather say so than sell you the wrong shape. If your requirement is "give our AI tools governed access to the company's systems without building and maintaining a server estate," that is the case Coworker MCP is built for, and it closes the connector-maintenance problem that stalls most self-hosted rollouts.
The broader deployment considerations, including what a security review will ask for, are in enterprise MCP.
See how Coworker MCP works, or book a demo to walk through what your setup would look like.
Frequently asked questions
What is an MCP gateway?
An MCP gateway is an infrastructure layer that sits between AI clients and one or more Model Context Protocol servers, giving every client a single endpoint and applying authentication, access control, tool filtering, rate limiting and audit logging to every tool call that passes through it.
What is the difference between an MCP gateway and an LLM gateway?
An LLM gateway governs calls to language models: provider routing, fallback, caching, token budgets and prompt guardrails. An MCP gateway governs what happens after the model decides to act: which tool it can call, under whose identity, with which credentials, and what gets logged. The short version is that the LLM gateway controls the thinking and the MCP gateway controls the doing. Most production agent platforms end up running both, and our LLM gateway guide covers that layer in full.
Is an MCP gateway the same as an API gateway?
No. An API gateway governs stateless HTTP and gRPC traffic between services. MCP traffic is stateful, uses JSON-RPC with streaming, and carries a different unit of authorization, the tool call rather than the endpoint. You can put MCP traffic behind an API gateway and some teams do, but you will be rebuilding tool-level access control, credential brokering and session handling yourself.
Do I need an MCP gateway if only a few developers use MCP?
Probably not yet. One developer with two servers on a laptop has a configuration problem, not a governance problem. The threshold is usually the point where the same server is used by more than one person, or where any connected system holds customer data. That is when credential sprawl and the absence of an audit trail start to matter.
Does an MCP gateway stop prompt injection and tool poisoning?
Not by itself. A poisoned tool description still reaches the model after passing through a gateway. What a gateway adds is the ability to review and approve servers before anyone can reach them, to inspect or reject requests and responses in flight, and to produce a record of what was actually called. That last part is the difference between an incident you can scope and one you cannot. See MCP security for the full threat model.
Should I self-host an MCP gateway or use a managed one?
It depends on who you want holding the credentials and who you want maintaining the connectors. Self-hosting keeps both inside your perimeter and is the right answer for regulated environments with a platform team. Managed removes the maintenance burden and gets you to a working setup far faster. The question that decides it in practice is whether you also need to front internal MCP servers, which most managed platforms cannot do.
How many MCP servers can one client handle before quality drops?
The limit is tool definitions, not servers. Speakeasy's testing found models handled 10 to 20 tools reliably, started hallucinating tool names around 40, and failed consistently at 107. Anthropic has documented cases where loading definitions on demand rather than upfront cut token usage from 150,000 to 2,000. A gateway that filters the tool list per user is the practical fix.
Does the MCP specification require a gateway?
No. Authorization is optional in the specification, and servers using stdio transport are explicitly told not to follow the authorization spec and to take credentials from the environment instead. The specification defines the protocol and deliberately leaves deployment architecture open, which is exactly why gateways emerged from practice rather than from the standard.
What should I ask a vendor first?
Where the downstream credentials live, and whether the end user's identity is propagated to the backend system or replaced with a shared service account. Those two answers determine more about your security posture than every other feature on the comparison table combined.
Related reading
Ready to get started?
Put Coworker to work inside your actual stack
Connect Salesforce, Slack, Jira, whatever you use, and run your first agent in minutes.