MCP Gateways Explained: Why Uber, GitLab and Chalk Put a Control Layer in Front of MCP

An MCP gateway is a proxy that sits between your agents and your MCP servers and applies shared rules once, instead of in every server. In practice it does six jobs, namely authentication, routing, rate limits, redaction, audit and tool discovery. You need one when many teams, many servers or unattended agents make per-server controls unmanageable. You probably do not need one yet if a single agent host talks to a few servers you control.

Uber, GitLab and Chalk show three different shapes. Uber built an internal gateway in front of what it says is more than 800 servers. Chalk sells a gateway as a product. GitLab shipped a server with gateway-like controls and is not a gateway at all. The 2026-07-28 MCP spec also added Mcp-Method and Mcp-Name headers so intermediaries can route without parsing the body.

The short version

Disclosure. Oakgen is our product and we do not make a gateway. This is an explainer built from vendor and spec pages, and Oakgen appears in one short note and the banners.

Who this is for

You run several MCP servers and someone asked "who can call what, and where is the log?" Or you must decide whether to buy, build or do nothing.

How we checked this

On November 12, 2026 we opened Uber's engineering posts of October 1 and November 6, 2026, InfoQ's report of November 2, GitLab's MCP server docs, tool governance docs and release notes for 19.5 and the upcoming 19.6, Chalk's gateway docs, changelog and blog posts, and the 2026-07-28 spec pages on Streamable HTTP, authorization and caching.

We ran none of these systems. "Not found" below means we did not see it in the pages we read, which is weaker than "does not exist".

Why organizations put a gateway in front of MCP

Four pressures show up in the sources.

Integrations multiply. Uber's post says teams built their own integrations, which led to "fragmentation in tooling and duplicated infrastructure". A gateway is where translation, ownership and enablement live once.

Agents should not hold secrets. Chalk's launch post says the credential exchange happens at the gateway, so the agent and its sandbox never see the upstream credential. That is a vendor description of its own design.

Blast radius grows. In a talk summarized by the Agentic AI Foundation on May 14, 2026, Uber's Meghana Somasundara said agents "move faster and break things faster". The same summary reports more than 60,000 agent executions a week and more than 1,500 monthly active agents. Those are Uber's own numbers from a conference talk.

Context is finite. GitLab's 19.5 notes say every tool that is not required wastes space in the model's context window. Uber's post says MCP has no native cross-server search, so an agent must already know which server to ask. Our post on code execution with MCP covers the token side.

Uber's gateway, read against the primary source

Uber's post is dated October 1, 2026. InfoQ's November 2 report by Leela Kumili repeats the figures and links to it, so the November news is a summary of an October post, not a new disclosure.

What the post says Uber built.

• Two planes. An MCP Registry is the control plane for servers, tools, ownership and enablement. A Proxy Gateway is the data plane.
• Protocol translation. The proxy turns MCP calls into HTTP, gRPC or TChannel calls through Muttley, Uber's service mesh sidecar, so services do not change.
• Automated discovery. AutoCrawler scans Uber's interface definition registry, has an LLM write tool descriptions, and registers every tool disabled by default.
• Discovery is not exposure. Owners must review and enable each server and tool. A description change creates a config diff they must approve, with rollback.
• Authorization and redaction. Uber's Access Control System applies policies by caller type (humans, services, agents), per server with optional tool-level overrides. The gateway redacts PII and sensitive data from tool responses.
• Third-party servers. For Jira and Google, the gateway relays the caller's user token and applies authorization, rate limiting and redaction. A separate service exchanges the internal token for a third-party token.
• Scale tools. Omni MCP exposes four tools (discover_server, discover_tools, get_tool_schema, invoke_tool) for incremental discovery.

The headline figure is Uber's own. The post says the gateway "is currently hosting over 800 MCP servers and over 5000 tools". We found no independent count.

What the post does not say

We found no latency figures, availability targets, failure isolation, capacity or cost in it, and it does not mention the 2026-07-28 headers. A Platform Engineering commentary of October 12, 2026 makes the useful point that most teams will never run 800 servers, and the portable part is the governance model, a registry with owners and tools that are off until someone enables them.

InfoQ also quoted Kelly Goetsch, president of Pipe17, who wrote that Uber's gateway "looks identical to gateways we've built over the decades for APIs and later GraphQL". Fair. The new parts are tool-level policy, description review and context control.

Uber's November 6, 2026 security post adds a caution. Its guardrails reduced risk but did not eliminate it.

GitLab is a server with gateway-like controls

GitLab shows the other way to get governance. Instead of one proxy in front of everything, the vendor builds controls into its own server.

GitLab 19.5, released October 15, 2026, made the GitLab MCP server generally available on all three tiers and all three deployment types.

What the documentation describes.

• Toolsets. An X-Gitlab-Enabled-Mcp-Server-Toolsets header limits which tool groups a connection gets. core, merge_requests, work_items, repository and ci are on by default. wikis, code_security and orbit are opt-in.
• Listing is not access. The docs say "Listing a tool does not grant access." Each tool still checks the user's project and namespace permissions.
• Rate limits. The 19.5 notes say that from October 15 the server on GitLab.com limits each user to 60 requests a minute on Free and 600 on Premium and Ultimate, and that reconnects and retries count. The docs add that the limit is per user, so several clients share one allowance.
• Authentication. OAuth 2.0 with Dynamic Client Registration or a pre-registered app, or a fine-grained token. Legacy personal, project and group tokens get a 403.

Enforced denies, advisory asks

GitLab's tool governance page holds the most useful idea for gateway builders. Premium and Ultimate owners can set each tool to Always Allow, Always Ask or Always Deny. For third-party clients such as Claude Code or Cursor, the docs say the server enforces Always Deny and refuses the call before the tool runs. Always Ask is different. The server only annotates the tool, and the docs say the client's own implementation determines whether the rule applies.

The docs list Claude Code 2.1.199 and later as prompting, and older Claude Code, Cursor, Windsurf and other clients as running the tool without prompting. GitLab's own advice is to use Always Deny for enforcement across every client.

A rule enforced where the request lands holds for every client. A rule left to the client is a suggestion.

Read the version labels

The GitLab docs page we read already describes 19.6, and GitLab's 19.6 release notes were still titled "Upcoming release" that day. Per the docs, hourly limits, enforced Always Deny for third-party clients and audit events for MCP tool calls are 19.6 items, and the first two sit behind feature flags that are off by default. Plan on 19.5 behavior until you see them in a release you run.

The docs also say the server accepts 2026-07-28 in initialize but answers 2025-11-25, because it does not yet implement the stateless features. A gateway in front of it will meet mixed protocol eras.

Chalk sells the gateway as a product

Chalk's MCP Gateway is the closest of the three to a classic gateway. Its documentation says it "sits in front of other MCP servers and governs your agents' access to them", and it is distinct from Chalk's own MCP server. The changelog dates the launch October 15, 2026 and the launch blog October 16. Chalk turns the gateway on per environment, and we found no price on the pages we read.

What the documentation describes.

• Registered backends. HTTP or stdio MCP servers, OpenAPI APIs and Chalk functions, behind one endpoint at /v1/mcp.
• Stored credentials. Backend credentials are stored encrypted, and agents authenticate to Chalk separately.
• Tool controls. An allowed-tools list, description overrides, and "belts", named subsets of the catalog with their own endpoint.
• Rego policy. Rules decide per call on user, scopes, backend, tool and arguments, with a simulator for drafts.
• Audit log. Every tool call, resource read and prompt fetch is recorded with the policy result, outcome, argument preview and duration.
• Per-agent rate limits. Listed on Chalk's capability page. We did not find a rate limit setting in the documentation page, so verify it.

The defaults are the fine print

Chalk's documentation is direct about edge cases, and they matter when you compare any gateway.

• Policies are deny-only. A request proceeds when no deny rule matches, so an allow rule "has no effect".
• With no policy enabled, the audit log shows "NOT RUN", meaning no policy evaluated the request.
• If a policy fails to evaluate, the gateway "allows the request rather than blocking on a rule it cannot run".
• A rule that names the wrong field or tool "fails silently", which is why Chalk recommends the simulator.

None of that is a flaw. It is a stated design that favors availability. But a security reviewer should know it is fail-open before approving it, and should ask every gateway vendor the same question.

What the 2026-07-28 spec gives a gateway

The spec does not define gateways. It does say how intermediaries should behave, in the Request Metadata section of the Streamable HTTP page. For the full spec changes, see our 2026-07-28 explainer. The page says the transport mirrors selected body fields into HTTP headers "so that intermediaries (load balancers, gateways, observability tooling) can route and inspect requests without parsing the body."

A request that fails validation gets HTTP 400 and this JSON-RPC error, copied from the spec's example.

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32020,
    "message": "Header mismatch: Mcp-Name header value 'foo' does not match body value 'bar'"
  }
}

Three rules matter for gateway builders.

1. Servers that process the body must reject mismatches. The stated reason is a load balancer routing on the header while the server executes on the body. Intermediaries must return an HTTP error on failure but need not send a JSON-RPC body.
2. Policy on headers needs a version check. Intermediaries that route or rate limit on mirrored headers should check that MCP-Protocol-Version names a version that requires validation, and otherwise reject the request instead of trusting the headers.
3. Caches must respect scope. A private cached result must not be shared across authorization contexts. A public one may be shared by a gateway, even if it came from an authenticated endpoint.

The authorization page adds a rule that shapes every credential design above. Servers "MUST NOT accept or transit any other tokens", meaning tokens not issued for them. That is why the vendors describe token exchange (Uber) or stored upstream credentials (Chalk) instead of forwarding the user's token.

Two inferences, not spec text

We have not tested any gateway against these, so treat them as questions to ask.

• Header routing is coarse. Mcp-Method and Mcp-Name support routing and per-tool rate limits without parsing JSON. A policy on arguments, such as Chalk's SELECT-only example, still needs the body.
• Renaming needs care. Chalk's docs say the gateway namespaces tool names and encodes resource URIs before sending them upstream. Under 2026-07-28 the header and body must agree on the upstream leg, so a gateway that rewrites one must rewrite the other. Chalk's docs example still shows a 2025-06-18 initialize, so the docs do not say how it handles this. Uber's post does not mention it either.

Do you need a gateway yet

This is our table, built from the sources above. The triggers are our judgment, not a standard.

MCP gateway responsibilities checklist

Use this as a requirements list when you build or buy. The table shows what each system's pages say.

The checklist itself, in the order we would verify it.

Auth

• The gateway authenticates every caller (human, service, agent) with its own identity. Agents do not share one key.
• Backend credentials live in the gateway or a token exchange, never in agent config.
• One agent identity can be revoked alone, and the log names which one made each call.

Routing

• One stable endpoint per agent surface, with a way to scope a subset of tools to a task.
• If you rewrite tool names, you also rewrite Mcp-Name so header and body agree.
• The gateway handles both protocol eras, since a backend may answer 2025-11-25 while a client sends 2026-07-28.

Rate limits

• Limits apply per identity, not only per client, and reconnect loops count.
• Calls that start paid or slow work have a tighter limit than reads.

Redaction

• Sensitive fields are removed from tool responses before they reach the model.
• You tested redaction on real response shapes, including nested fields.

Audit

• Every tool call, resource read and prompt fetch is logged with caller, target, arguments, decision and duration, and denied calls are logged too.
• You know what happens on a policy error. Fail-open and fail-closed are both defensible, but only if someone chose.

Tool discovery

• New tools start disabled, an owner enables them, and description changes are reviewed and reversible.
• Agents see a task-sized slice of the catalog, through belts, toolsets, tool search or code mode.
• Cached lists honor ttlMs and cacheScope, and someone reads third-party tool descriptions. Our MCP server supply chain post covers why.

How a creative team would apply this

Most creative teams will not run a gateway in year one. They connect an agent to one or two servers and want a cap on spend and a person who approves anything that costs money. That is a server-side and workflow job first, covered in our MCP security checklist for creative teams and our post on human approval for creative agents.

A note on our own server. Oakgen's MCP endpoint is a server, not a gateway, and it enforces its own per-account limits. The rate policy in our repository sets 60 requests a minute and 1,000 a day for a standard account, with a separate 10 a minute for calls that start generation, and generation calls carry a maxCredits quote. We have not put a gateway in front of it.

For when MCP beats a plain API at all, see MCP versus API for image generation.

Common mistakes

1. Calling a server with controls a gateway. GitLab's toolsets and rate limits protect GitLab and nothing else.
2. Assuming a policy means default deny. Chalk's policies are deny-only.
3. Trusting Always Ask across clients. Several clients run asked tools without prompting.
4. Trusting headers without a version check.
5. Rewriting tool names and forgetting the header.
6. Treating a count as proof. "800 servers" tells you about Uber's scale, not whether a gateway fits your twelve.

Decision framework

For the foundation that hosts agentgateway, see our Agentic AI Foundation explainer. We have not tested agentgateway.

What I would do

I would start with the registry and not the proxy. A page that lists every MCP server, its tools, its owner and whether each tool is on costs nothing and answers most "who can call what" questions. Platform Engineering's commentary reaches the same conclusion from Uber's post.

I would add a gateway the day an agent runs unattended with write access, or the day a third-party server touches user data. Those are the two cases where per-client controls fail, because nobody is there to say no.

When evaluating a gateway I would ask five questions. What happens when the policy errors. Can it deny by argument as well as by tool. Does it log denied calls. How does it handle tool renaming under the new headers. Can it serve two protocol eras at once. Chalk answered the first in its documentation. Most vendors will not volunteer the others.

I would not copy Uber's AutoCrawler without thousands of services, and I would read every third-party tool description myself. Check the six-month MCP release cycle before you pin a gateway to one spec version.

Frequently asked questions

What is an MCP gateway?

An MCP gateway is a proxy between agents and MCP servers that applies shared rules in one place instead of in every server. The jobs we found across Uber's engineering post of October 1, 2026, GitLab's documentation and Chalk's documentation are authentication, routing, rate limits, redaction of sensitive data, audit logging and tool discovery. It is not part of the MCP specification. The 2026-07-28 spec only adds request headers that let intermediaries such as gateways route and inspect requests without parsing the body.

Is the GitLab MCP server a gateway?

No. It is an MCP server that exposes GitLab to agents, generally available since GitLab 19.5 on October 15, 2026. It has gateway-like controls built in, namely toolset selection by HTTP header, per-user rate limits on GitLab.com, OAuth, and tool governance rules for Premium and Ultimate. A gateway sits in front of other servers. GitLab's controls only cover GitLab's own tools.

Is Uber's MCP Gateway available to buy or download?

Not as far as we could verify. Uber's engineering post of October 1, 2026 describes an internal platform. Uber's own figure is more than 800 MCP servers and more than 5,000 tools. InfoQ reported the same figures on November 2, 2026 by summarizing that post. We found no product or open source release of the gateway itself.

What do the Mcp-Method and Mcp-Name headers do?

In the 2026-07-28 Streamable HTTP transport, Mcp-Method carries the JSON-RPC method on every request, and Mcp-Name carries the tool, resource or prompt name on tools/call, resources/read and prompts/get. The spec says they exist so load balancers, gateways and observability tooling can route and inspect requests without parsing the body. Servers must reject a request whose headers disagree with the body with HTTP 400 and the JSON-RPC error -32020, named HeaderMismatch.

Do I need an MCP gateway for two or three servers?

Usually not yet. This is our judgment, not a standard. With one agent host and a few servers you control, server-side scopes, read-only modes, a tool allowlist and a short list of who owns what give you most of the benefit. A gateway starts to pay off when several teams share servers, agents run unattended with write access, third-party servers touch your user data, or the number of tools is large enough to hurt context. The decision table in this post sets out those triggers.

Does a gateway make MCP safe?

No. It enforces the rules you give it, and its defaults matter. Chalk's documentation says its policies are deny-only, that a request is allowed when no deny rule matches, and that the gateway allows a request when a policy fails to evaluate. Uber's own security post of November 6, 2026 says guardrails reduced risk but did not eliminate it. A gateway also cannot tell whether a tool description is honest, which is a supply chain question.

Can a gateway rewrite tool names under the 2026-07-28 spec?

It can, but it has to keep the headers and the body consistent on the upstream leg. Chalk's documentation says its gateway namespaces tool names as backend__tool and encodes resource URIs before passing them upstream. Under 2026-07-28, a server that processes the body must reject a request whose Mcp-Name header does not match the name in the body. We have not tested any gateway against that rule, so ask a vendor how it handles it.

Which open source MCP gateways exist?

The Agentic AI Foundation lists agentgateway as a hosted open source project that routes MCP and agent-to-agent traffic, and its project page links a post on enterprise MCP gateway security dated August 20, 2026. The Linux Foundation welcomed the project on August 25, 2025 and says Solo.io created it. We did not install or test it, so treat this as a pointer, not a recommendation.

Sources

1. Uber Engineering, Designing MCP Gateway, Uber's MCP Management Platform, Oct 1 2026 (read 2026-11-12)
2. InfoQ, Uber Builds MCP Gateway to Govern Access to 800+ Servers and 5,000+ AI Agent Tools, Nov 2 2026 (read 2026-11-12)
3. Uber Engineering, Securing AI Agents, Lessons From Real-World Deployment, Nov 6 2026 (read 2026-11-12)
4. Agentic AI Foundation, How Uber Runs 60,000 AI Agent Tasks Per Week With MCP, May 14 2026 (read 2026-11-12)
5. Platform Engineering, What Uber's 800-Server MCP Gateway Means for Platform Teams, Oct 12 2026 (read 2026-11-12)
6. GitLab Docs, GitLab 19.5 release notes, Oct 15 2026 (read 2026-11-12)
7. GitLab Docs, GitLab 19.6 upcoming release notes (read 2026-11-12)
8. GitLab Docs, GitLab MCP server (read 2026-11-12)
9. GitLab Docs, Agent tool governance (read 2026-11-12)
10. GitLab blog, Connect your agents to your software lifecycle with the GitLab MCP server, Oct 15 2026 (read 2026-11-12)
11. Chalk Docs, MCP Gateway (read 2026-11-12)
12. Chalk Docs, MCP Server Access for sandboxes (read 2026-11-12)
13. Chalk Docs, Changelog, MCP Gateway entry of Oct 15 2026 (read 2026-11-12)
14. Chalk blog, Give agents exactly the access they need with Chalk MCP Gateway, Oct 16 2026 (read 2026-11-12)
15. Chalk blog, Quarterly Product Update, Fall 2026, Nov 10 2026 (read 2026-11-12)
16. Chalk, MCP Gateway capability page (read 2026-11-12)
17. Model Context Protocol, Streamable HTTP transport, 2026-07-28, Request Metadata (read 2026-11-12)
18. Model Context Protocol, Authorization, 2026-07-28 (read 2026-11-12)
19. Model Context Protocol, Caching, 2026-07-28 (read 2026-11-12)
20. Model Context Protocol, Security Best Practices, 2026-07-28 (read 2026-11-12)
21. Agentic AI Foundation, agentgateway project page (read 2026-11-12)
22. Linux Foundation, Welcomes Agentgateway Project, Aug 25 2025 (read 2026-11-12)