The Best MCP Gateways for Claude Code in 2026

An MCP gateway gives Claude Code one pinnable URL in front of many business systems — which is exactly the shape Claude Code’s own enterprise controls want. Anthropic’s managed-mcp.json lets IT pin full server definitions users can’t override — the robust pattern its docs recommend over matching servers by name alone — and pinning fifty individually-vetted servers is fifty times the work of pinning one. The gateway adds what sits under that pin: per-user credentials, provider-level audit logs, and a vetted catalog. Verdict: StackOne for IT-governed rollouts acting on business systems; Docker MCP Gateway for one developer running local servers; Composio for solo builders.

This page is about Claude Code specifically — the agent running in terminals, devcontainers, and CI, governed by platform and IT teams. For claude.ai and Claude Enterprise chat, see our Claude MCP gateway guide; for the full twelve-vendor field, the MCP gateway comparison.

How does Claude Code connect to MCP servers today?

Three scopes, one precedence order

Per Anthropic’s MCP documentation (June 2026), Claude Code MCP configuration works at three scopes:

• Local (the default) — private to you in one project, stored in ~/.claude.json.
• Project — a .mcp.json at the repo root, “designed to be checked into version control”; Claude Code prompts each user for approval before using project-scoped servers.
• User — available to you across all projects.

Precedence runs local > project > user. The project scope is where team-level MCP starts — and where credential hygiene starts to strain.

Transports and auth

HTTP is the recommended transport (the streamable-http alias works too); SSE is deprecated; stdio covers local servers; WebSocket supports header auth only. For remote servers, the /mcp command runs a full OAuth 2.0 flow: tokens are stored in the system keychain on macOS and refreshed automatically, with support for Dynamic Client Registration, pre-configured client credentials, an authServerMetadataUrl override, and more — per the same doc. That’s a properly engineered auth client; a gateway should meet it with a properly engineered OAuth server, not a static API key in an env var.

One inheritance rule worth knowing: connectors added in claude.ai automatically appear in Claude Code — though only when you’re authenticated with your Claude.ai subscription, not under an API key, Bedrock, or Vertex (disable with ENABLE_CLAUDEAI_MCP_SERVERS=false); on Team and Enterprise plans only admins add those.

Tool count is a solved problem; tool trust isn’t

Claude Code’s Tool Search is on by default and defers tool definitions until needed: per Anthropic’s docs, Claude Code “does not impose a fixed per-server tool cap; the practical limit is your context window budget” (descriptions truncate at 2KB; disabled by default on Vertex and non-first-party base URLs). Tool outputs warn at 10,000 tokens and cap at 25,000 by default (MAX_MCP_OUTPUT_TOKENS). So Claude Code’s MCP question was never how many — it’s which, whose credentials, and who’s watching.

How does IT govern Claude Code MCP servers?

This is the strongest client-side MCP admin plane we’ve seen documented.

What is managed-mcp.json?

managed-mcp.json is an enterprise configuration file for Claude Code that gives IT exclusive control over MCP servers: users cannot add, modify, or use any others, including plugin-provided ones. It’s deployed as a file via MDM/GPO — Anthropic notes it cannot be delivered through server-managed settings — and it pins full server definitions, not just names.

The full control surface, per Anthropic’s managed MCP docs (June 2026):

• managed-mcp.json deploys via MDM/GPO (Jamf, Intune) to /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux, or C:\Program Files\ClaudeCode\ on Windows: “Users cannot add, modify, or use any other MCP servers, including plugin-provided servers.” An empty {"mcpServers": {}} disables MCP entirely.
• Policy files offer a lighter touch: allowedMcpServers / deniedMcpServers match on serverUrl (with * wildcards), serverCommand, or serverName — with Anthropic’s explicit warning that name-only allowlists are “not a security control”. allowManagedMcpServersOnly: true restricts users to the managed list; allowAllClaudeAiMcps: true (v2.1.149+) re-admits admin-approved claude.ai connectors.
• Server-managed settings push the allow/deny policies — not managed-mcp.json itself — from the claude.ai admin console (Team and Enterprise): clients poll hourly, the settings take highest precedence, and “no other settings level can override them, including command line arguments” (docs). Changes are audit-logged via the Compliance API (access via your Anthropic account team).
• Enforcement is visible: blocked servers “silently disappear”, and claude mcp add fails with “not allowed by enterprise policy.”
• Managed settings can also pre-approve or deny individual MCP tools (permission rules on mcp__server__tool) — orthogonal to the server allowlist.

One caveat Anthropic itself documents: server-managed settings are distributed centrally but enforced client-side — users with admin/sudo on unmanaged devices can tamper, and they’re bypassed on Bedrock, Vertex, or a custom ANTHROPIC_BASE_URL. MDM-deployed files give stronger guarantees.

What Claude Code’s MCP controls don’t cover

Claude Code’s admin plane governs the client — which servers it may talk to. Five gaps sit behind it, at the server layer:

1. The allowlist needs something worth pinning. The robust pattern Anthropic points to — full server definitions, not names — means IT must source, vet, and maintain every definition it pins. And there’s no built-in registry: per the managed-mcp docs, Claude Code “doesn’t have a built-in MCP server registry that users can browse and install from”; Anthropic suggests an internal wiki or plugin marketplace. Fifty pinned servers is fifty vetting exercises.
2. Nobody audits the servers. Anthropic reviews directory connectors but “does not security-audit or manage any MCP server”, and warns that “servers that fetch external content can expose you to prompt injection risk.” Content vetting is your job.
3. The audit trail stops at the client. OTEL_LOG_TOOL_DETAILS=1 records which MCP servers and tools users invoke via OpenTelemetry — useful, but it shows which tool was called, not what it read or wrote downstream. And Claude Enterprise’s audit logs (documentation dated March 16, 2026) don’t include connector or MCP events at all — 35 documented event types, Enterprise-only, 180 days. “Which records did the agent touch in the CRM?” has no answer in Claude’s logs.
4. Project-scoped configs invite shared credentials. A .mcp.json checked into the repo is great for sharing servers — and a standing temptation to share tokens through env vars referenced in it. Per-user OAuth belongs at the server, not in the repo.
5. Local servers don’t travel. stdio servers and per-machine credentials break in devcontainers and CI, where a growing share of Claude Code runs happen.

What to look for in an MCP gateway for Claude Code

The best MCP gateways for Claude Code, compared

Facts below are from each vendor’s public documentation as of June 9, 2026, carried over from our full comparison. We’ve kept the four that map to distinct Claude Code postures — IT-governed remote, local containers, solo-developer remote, self-hosted infrastructure; Zapier and Merge, remote endpoints Claude Code can also consume, are covered in the Claude guide and the full comparison.

1. StackOne

StackOne is the enterprise layer for AI agents to safely act on any application — one governed entry point in front of 310+ managed connectors exposing 20,000+ agent-optimized actions across HRIS, ERP, CRM, and ITSM. Against the Claude Code criteria:

• One pinnable URL, verified end-to-end in Claude Code. An individual adds it with claude mcp add, a team checks it into .mcp.json, and IT pins its full definition in managed-mcp.json — Anthropic’s allowlist guidance becomes a one-line policy.
• Per-engineer credentials. An OAuth 2.1 flow where the end user authorizes the MCP client themselves: the /mcp handshake lands on SSO, a co-branded consent screen, and an account picker, so every engineer acts on their own linked accounts and no service token sits in a repo.
• Provider-level logs. Request logs capture every call down to the underlying provider requests, exportable to Datadog or Grafana — the record OTel and Claude’s audit logs don’t keep.
• Governance at any catalog size. Admins scope which actions each project and linked account exposes; agents get two meta-tools, search and execute, so context stays constant as the catalog grows; and StackOne Defender scans tool responses for prompt injection before they reach the agent (89.0% detection accuracy in our published evaluation). The same URL can be added in claude.ai too, so IT manages one connector definition across the inherited chat-and-code surface. SOC 2 Type II, GDPR, HIPAA; EU/US data residency.

Limitation: the catalog focuses on business systems, not consumer applications — for the consumer-app long tail, Zapier’s catalog is far bigger. When a system isn’t in the catalog, the AI Connector Builder builds or extends a connector on the same engine that powers the pre-built ones, so coverage isn’t capped at what ships out of the box.

Best for: platform and IT teams governing a Claude Code rollout that acts on business systems — one pinned URL, per-engineer credentials, provider-level logs.

2. Docker MCP Gateway

Docker’s MCP Gateway (open source, free) is the local-dev baseline: it runs MCP servers as isolated containers with restricted privileges, injects credentials centrally, and includes call tracing — a clean security model for one machine. It pairs naturally with Claude Code’s stdio transport. The boundary is the point: multi-tenancy isn’t addressed, the trust boundary is one Docker environment, and there’s no remote URL for IT to pin in managed-mcp.json or carry into CI.

Best for: one developer who wants isolated, credential-managed local servers behind Claude Code, for free.

3. Composio

Composio markets 1,000+ toolkits and 20,000+ tools, with good SDKs, fast setup, published pricing (free tier, from $29/month), and per-user connected accounts where end users authorize via a hosted Connect Link. For an individual Claude Code user it’s one of the quickest paths to a broad tool set. Note that each toolkit is its own MCP server URL — under a managed-mcp.json regime, that’s one pinned definition (and one vetting exercise) per toolkit. And what we couldn’t find in its public docs as of June 9, 2026: an org-level control plane — central policy enforcement, approval workflows. For the team writing the managed-mcp.json, that’s the whole question.

Best for: solo developers wiring tools into their own Claude Code workflows, ahead of organizational governance.

4. Arcade

Arcade is an MCP runtime with deployment flexibility across cloud, your VPC, on-prem, and air-gapped environments — it integrates your existing IdP so multi-user agents act with user-specific permissions rather than service accounts, plus agent lifecycle governance. Against this page’s criteria: a remote Arcade endpoint is a URL Claude Code can add and IT can pin in managed-mcp.json, and a self-hosted deployment keeps that URL inside your own network boundary. What its public docs don’t detail as of June 9, 2026 is whether the IdP-integrated OAuth completes Claude Code’s /mcp handshake end-to-end, or what its logs record per tool call — test both before pinning. Pricing is published (free tier; Growth $25/month plus usage). Its registry lists ~150 MCP servers — an order of magnitude fewer systems than the larger catalogs here; check coverage against your stack first.

Best for: teams with hard infrastructure-control requirements and a contained set of target systems.

How to connect StackOne to Claude Code

Individual developer:

1. Get your MCP server URL — StackOne MCP covers what’s behind it, and the MCP quickstart shows where to generate the URL in the dashboard.
2. claude mcp add --transport http stackone <your StackOne MCP URL>
3. Run /mcp to authenticate — Claude Code drives StackOne’s OAuth 2.1 end-user flow (SSO, consent screen, account picker) and stores the token in your system keychain, refreshed automatically.

Team: add the same server definition to the repo’s .mcp.json (project scope — built to be checked in). Each engineer approves it once and authenticates as themselves; no shared tokens, and the same URL works in devcontainers and CI.

Enterprise: pin the full StackOne server definition in managed-mcp.json, deployed via MDM/GPO — Anthropic notes the file cannot be delivered through server-managed settings; use those to push an allowedMcpServers policy matching the gateway URL instead. Optionally set allowManagedMcpServersOnly: true so the pinned definition is the only MCP surface:

{
  "mcpServers": {
    "stackone": {
      "type": "http",
      "url": "<your StackOne MCP URL>"
    }
  }
}

End users still link their own downstream accounts through the OAuth flow; admins scope actions via connector profiles; every call lands in request logs down to the provider request — the layer below what OTEL_LOG_TOOL_DETAILS records.

When you don’t need a gateway for Claude Code

• One developer, a handful of local servers. claude mcp add plus Docker’s container isolation is simpler and free; a gateway adds a hop you don’t need yet.
• Your servers are all internal and already governed. If platform engineering builds and operates every MCP server behind your own auth and logging, managed-mcp.json pinning those definitions may be enough.
• You’re still proving the use case. Connect a single managed MCP server directly, then graduate when headcount makes credential sprawl, the vetting backlog, and the audit-log gap real.

The trigger points: the first security review asking what an agent did in a provider, the first .mcp.json with a shared token in it, and the first attempt to write a managed-mcp.json allowlist longer than ten entries.

StackOne is the governed layer between AI agents and 310+ enterprise systems with 20,000+ agent-optimized actions — over MCP, A2A, API, and SDKs — with end-user OAuth linking, connectors you can extend, and built-in prompt-injection defense. See the full MCP gateway comparison, the Claude guide, StackOne MCP, or connector-level detail for Salesforce, Jira, and Workday. See pricing or book a demo.

More MCP gateway guides

Every guide in this series applies the same disclosed criteria to a different AI client. Start with the full comparison, or jump to yours: