What the Best MCP Gateways Do in 2026

Twelve months ago, “MCP gateway” meant a thin proxy that translated authentication for one upstream MCP server. Today the buying conversation includes Portkey (being acquired by Palo Alto Networks), Cloudflare, Kong, Microsoft, AWS Bedrock AgentCore, Lunar.dev, IBM ContextForge, MCPJungle, MintMCP, Docker, and Zuplo. The category grew up fast, and the requirements that separate a real gateway from a working demo are now clear enough to write down.

This is the checklist I’d hand a platform team buying or building one today.

What an MCP gateway is for

Two situations call for one.

You’re shipping an MCP server as part of your product. The API team or platform engineer who built it wants the same things they’d put in front of any API: auth, rate limits, audit logs, and a deploy story for the server itself.

You’re governing how your own people use MCP. The IT, platform, or security lead wants to control which servers and tools each employee can reach as they wire Claude, Cursor, ChatGPT, and VS Code into Linear, GitHub, Notion, Atlassian, Stripe, and a pile of internal servers. They need to audit every tool call and revoke access the day someone leaves.

The category started with the first. The growth in 2026 is in the second. A thousand employees with personal MCP configs is the same governance problem as a thousand employees with personal SaaS accounts, except these connections read and write your production systems on the user’s behalf.

Both need the same checklist.

The ten things every MCP gateway should do

1. Speak the full spec

MCP versions its spec by date. The 2025-06-18 revision is the profile every shipping MCP client targets in production: Claude Desktop, Claude Code, Cursor, ChatGPT (including the OpenAI Apps SDK), VS Code, and MCP Inspector all interoperate around it. The 2025-11-25 revision is the newer published spec; adoption is still rolling through clients. A gateway should ship the version clients actually use today and track new releases as the ecosystem moves.

In practice that means:

• Streamable HTTP transport (not SSE-only, not stdio-only).
• Protected Resource Metadata at .well-known/oauth-protected-resource per RFC 9728, with resource, authorization_servers, scopes_supported, and bearer_methods_supported.
• Authorization Server metadata at .well-known/oauth-authorization-server per RFC 8414.
• Dynamic Client Registration per RFC 7591, with PKCE S256 enforced (no shared client secrets shipped to desktops).
• WWW-Authenticate: Bearer resource_metadata=..., scope=... on 401, and error="insufficient_scope" on 403 for step-up flows.
• RFC 8707 resource-indicator audience validation, so a token minted for one virtual server is rejected at another.

If a gateway tells you “we use OAuth,” ask which fields they emit on metadata endpoints and which RFCs they implement. The answer separates the gateways that actually pass spec compliance tests from the ones that have a working demo.

2. Broker upstream auth

The naive design takes the user’s OAuth token from the MCP client and forwards it to the upstream MCP server. That’s bad. The user’s client shouldn’t hold broad-scope credentials for every upstream service in the catalog. The right design is broker mode:

• The user authenticates once to the gateway via your IDP.
• For each upstream they connect (Linear, Gmail, Stripe, internal), the gateway brokers the credential on their behalf: a per-user OAuth flow where the upstream supports it, a shared service account where it doesn’t, or an encrypted vault entry for upstreams that issue per-user API keys.
• Whatever the credential type, it’s stored encrypted server-side, keyed to the user’s gateway identity, and never returned to the MCP client.
• On each tool call, the gateway looks up the right credential, refreshes it if needed, and proxies the call. Per-user attribution stays in the audit log even when the upstream sees one service principal.

A gateway that passes the user’s IDP token straight through teaches every upstream MCP server about your IDP sessions. You don’t want that.

3. Control access per capability, not per server

Server-level access is too coarse. The Stripe MCP server exposes create_charge, refund_create, retrieve_balance, and a hundred more. Your finance read-only analyst should see retrieve_balance. Your engineers shouldn’t see Stripe at all. A yes/no-per-server switch can’t express that, and when the only knob is per-server you end up hand-rolling shadow MCP servers that each expose a subset. Manageable at 50 people, unmanageable at a thousand.

So the unit of access is the capability, not the server. Zuplo’s capability filter lets you allowlist exactly which tools, prompts, resources, and resource templates a route exposes; anything you don’t list is blocked, and a hidden tool returns MethodNotFound rather than failing silently. Give each role its own curated route and “what can finance reach” becomes a config diff instead of a Slack thread.

For rules that go past yes/no on a capability (cap a refund amount, redact a customer email from a response), you drop into a programmable policy on the route. The curation layer decides what’s visible; the policy layer (item 9) decides what’s allowed and what comes back.

4. One virtual server per upstream

Pointing a client straight at a raw upstream MCP server exposes every tool that server ships. A virtual MCP server fixes that: a curated view of one upstream that exposes only the tools, prompts, and resources you pick, behind a dedicated gateway URL with its own auth.

An engineering team that needs Linear, GitHub, deployment tools, and an internal knowledge server gets a curated virtual server for each, all registered and governed in one gateway. Each virtual server gets its own gateway URL (/mcp/linear, /mcp/stripe, and so on) and brokers its own upstream credentials behind the gateway’s single OAuth front door. The curated capability list is the contract; the upstream is the implementation. Adding or removing a tool doesn’t break clients.

That’s the difference between handing a client a raw upstream and giving each team a governed, curated surface you control centrally.

5. Scan tool traffic both ways

MCP traffic has two attack surfaces:

• Tool inputs: a malicious tool definition or poisoned argument trying to inject instructions into the LLM context.
• Tool outputs: a response carrying PII, a customer record, an internal document, or its own injected instructions.

So guardrails have to run both ways, blocking, redacting, or flagging per policy. Zuplo runs this as a policy on the route. The Akamai AI Firewall policy scans both directions: prompt injection on the way in, PII and DLP on the way out, with a per-request verdict you can set to monitor, modify (redact inline), or deny. Because it’s a policy and not a baked-in detector, you can swap in whatever scanner your security team already procured. The gateway’s job is to call the scanner and act on its verdict, not to be the scanner.

6. Log everything, and make it queryable

Audit logs that live in a vendor UI are not audit logs. They are screenshots in waiting. Generic API analytics that bucket calls by HTTP path miss everything that matters about agent traffic.

Every MCP request should be logged with:

• User identity (resolved through your IDP, not the MCP client’s view).
• Virtual MCP server and upstream MCP server.
• Capability type (tool, prompt, or resource), capability name, and arguments (subject to redaction policy).
• Response size and estimated token count.
• Policy decisions (allowed, denied, modified, redacted).
• Latency, split between gateway and upstream.
• Failure origin (gateway, upstream, client, auth) and JSON-RPC error code.
• Timestamp, IP, geolocation, user agent (so you can tell Claude Code from Cursor from ChatGPT from Inspector).

Structured events with that metadata should drop straight into your existing observability stack (ClickHouse, Datadog, Honeycomb, Splunk, New Relic, BigQuery, your data lake), not stay trapped in a vendor dashboard.

On top of raw events, look for MCP-aware dashboards out of the box: top capabilities by call count and error rate, top virtual servers, users, and clients, JSON-RPC error-code distributions, and gateway-vs-upstream p95 latency. A gateway that knows the protocol can answer “which tool is failing for which client, and where in the call path” without you writing the query.

Retention should be tiered, not cliff-edged. 7 days free, 30 days production, 90 days enterprise, 12+ months for compliance workloads. Critically, the gateway should not silently stop logging when you exceed a threshold. That failure mode breaks the entire premise of an audit-grade gateway.

7. Bring your own identity provider

Every enterprise has an IDP: Auth0, Okta, Microsoft Entra ID, Google Workspace, Keycloak, Cognito, Ping. The gateway should integrate with yours. JWT claims from your IDP should drive per-tenant, per-role, per-team authorization decisions at the gateway edge, not in a separate RBAC system the gateway ships with.

SCIM provisioning should be a first-class feature, not a “contact sales” add-on. When an employee leaves, their gateway access and all upstream MCP service links should revoke in the same flow.

8. Deploy with GitOps, not a UI

The gateway’s configuration (which upstreams are registered, which virtual MCP servers exist, which tools each role can call, which guardrail policies are applied) is operational policy. Operational policy belongs in a Git repository.

That gives you:

• Code review on every governance change.
• PR preview environments to test policy changes against real clients before promoting.
• Audit trail through your existing change management process.
• Rollback to any prior state.
• Branching for staged rollouts.

A configuration UI is fine for exploration, not as the only source of truth. If your gateway’s policies live in a vendor’s database, your governance lives in a vendor’s database.

9. Programmable policies, not toggles

Every interesting MCP governance decision is conditional. “Allow this tool only if the user is on the finance team and the amount parameter is below $10K.” “Redact emails from the response, except internal company emails.” “Route to a different upstream if the user is in the EU and the request would cross a residency boundary.”

You can’t express that in checkboxes. You can express all of it in code.

The gateway should let you write policies in TypeScript (or whatever language fits its runtime), with full type safety, real CI tests, and the ability to call your own services for policy decisions.

10. Stay easy to leave

MCP clients (Claude Desktop, Cursor, ChatGPT, VS Code) point at a gateway URL. If the gateway you bought isn’t working out, switching costs you a URL change plus a re-auth flow.

That’s a feature of the protocol, and a good gateway leans into it. Specifically: no SDK required in the client, no code changes required in the upstream MCP servers, no proprietary protocol layer that locks you in.

If migrating off the gateway means rewriting your MCP servers, the gateway is doing too much.

Three traps to avoid

Trap 1: The all-in-one AI security suite. A single vendor selling the AI gateway, prompt firewall, agent identity, runtime sandbox, and policy engine sounds clean. In practice, you get a roadmap that optimizes for the suite, not the gateway. The gateway component lags the components that close the bigger sale. (Particularly relevant after Palo Alto Networks acquired Portkey on April 30, 2026, but not unique to that deal.)

Trap 2: The free-tier-with-an-Enterprise-cliff. When SSO, RBAC depth, audit retention, and EU data residency all live behind a sales call, the product isn’t designed for the mid-market. If your team is 50 to 500 people, that gap will frustrate you.

Trap 3: The configuration UI as source of truth. It seems faster up front. By month six, you have governance changes nobody reviewed, no rollback path, and no audit trail of who turned which policy on when. Operational policy belongs in version control.

Where to go next

If you’re shopping right now, our MCP gateway comparison runs the major vendors against this checklist.

The category is settling. The right answer is ten capabilities deep, and the gateways that hit all ten are the ones platform teams will quietly standardize on over the next two years. Pick well.

The Zuplo MCP Gateway is in public beta and available on every plan, including the free tier. Try it for free and put it against this checklist yourself.