MCP gateways compared
Docker MCP Gateway, Stacklok ToolHive and Arcade MCP Gateways compared on where they run, how they isolate MCP servers, how clients authenticate, tool filtering and context control, policy, audit and rate limits, and licensing.
Comparison
| Entry | What it is | Where it runs | Server isolation | Client authentication | Tool filtering and context | Policy, audit and limits | License and cost |
|---|---|---|---|---|---|---|---|
| Docker MCP Gateway | The docker mcp CLI plugin that runs MCP servers as containers behind one endpoint; the engine behind Docker Desktop's MCP Toolkit. Profiles group servers from the Docker MCP Catalog, the MCP Registry, docker:// images or local files | Docker Desktop 4.59+ (README prerequisite), or as a standalone CLI plugin or the docker/mcp-gateway Compose image with the Docker socket mounted. Transports: stdio (default), SSE or streaming | Starts each server as a container on demand with restricted privileges, network and resources. Defaults: 1 CPU and 2Gb memory per server, signature verification on, secret blocking on; --block-network is off by default | No OAuth layer for clients. On HTTP transports, unauthenticated requests are refused unless --allow-unauthenticated is set, and MCP_GATEWAY_AUTH_TOKEN guards localhost against DNS rebinding. Upstream, the README says it handles OAuth flows for servers that need access tokens | Per-profile tool allowlists (docker mcp profile tools ... --enable server.tool) and --servers / --tools flags at run time; the README also lists dynamic tool discovery and configuration | --log-calls on by default, --verbose; interceptors run your own scripts before or after calls (when:type:path); no built-in rate limiting documented | MIT, open source. The enterprise MCP Gateway in Docker AI Governance is invite-only |
| ToolHive | Stacklok's runtime for MCP servers (thv CLI, desktop UI, Kubernetes operator) plus vMCP, which aggregates a group of servers into one endpoint | Local with Docker, Podman or Colima; vMCP locally via thv vmcp serve or on Kubernetes via the operator. Can also proxy remote MCP servers | Each server in a container. Network isolation is on by default since v0.30.1: egress proxy (Squid, or Envoy), DNS and ingress containers enforce the permission profile's allowed hosts and ports. HTTP and HTTPS only; opt out with --isolate-network=false | OIDC token validation on thv run (--oidc-issuer, --oidc-audience). vMCP uses a two-boundary model (client auth separate from backend auth), an optional embedded authorization server and RFC 8693 token exchange to backends | --tools filter and --tools-override; vMCP prefixes clashing tool names (github_create_issue), adds composite tools and Starlark code mode, and an optimizer that replaces the tool list with find_tool and call_tool | Cedar authorization policies (--authz-config), audit logging (--enable-audit), OpenTelemetry and Prometheus. No rate-limiting option in the thv run reference | Apache-2.0, open source; latest release v0.55.2 (2026-10-19) |
| Arcade | A gateway inside Arcade's tool platform that federates Arcade-built tools and registered remote MCP servers into one Streamable HTTP URL, https://api.arcade.dev/mcp/{slug} | Arcade Cloud, Azure Marketplace, AWS (private offer), GCP listed as coming soon, or self-hosted with Helm on Kubernetes 1.30+ with PostgreSQL, Redis and an OIDC identity provider | Not a container sandbox: Arcade hosts its own tools, and remote MCP servers run wherever their owners host them | OAuth sign-in through Arcade Auth or your own OIDC user source (Auth0, Clerk, Entra ID, Okta, Stytch), or API key plus Arcade-User-ID headers. CIMD client IDs can be allowlisted to skip consent | Pick allowed tools per gateway; Tool Recommendation (default for new gateways in orgs that have it) lists a few tools and returns matching allowed tools per task; gateway LLM instructions | Native rate limits (tool matcher, limit, window; counters per tool and per org or project, not per user), Contextual Access hooks, audit logs with a REST API | Proprietary platform with a free tier (no credit card); the arcade-mcp server framework is MIT |
Verdict: For a developer machine, Docker MCP Gateway is the shortest route if you already use Docker Desktop: catalog servers, containers, tool allowlists. Pick ToolHive when servers must not reach arbitrary hosts (egress allowlists are the default) or you need OIDC, Cedar policy and one aggregated vMCP endpoint on Kubernetes. Pick Arcade when end users sign in and you want per-user OAuth to SaaS tools, rate limits and audit logs without running it.
Once an agent uses more than a few MCP servers, you run into the same problems on every machine. Each client needs each server configured. Every server sees whatever the host can reach. The model is shown every tool's description. Nobody has a record of which tool was called, or by whom. An MCP gateway gives the client one endpoint, and enforces policy between the client and the servers.
The three gateways here solve different parts of that problem:
- Docker MCP Gateway is about running servers safely on a developer machine.
- ToolHive is about running servers in isolation, and putting identity and policy on top, from a laptop up to Kubernetes.
- Arcade is about end users signing in and calling SaaS tools on their own behalf.
Every fact below comes from each project's own README or docs, as of 2026-10-21. None of the three was run for this piece. The box used for research has no container runtime, and Arcade is an account-based service. Defaults are quoted from flag references and docs.
How they differ
Where the servers run. Docker and ToolHive both run MCP servers for you, as containers. Docker starts each server on demand. By default it limits each one to 1 CPU and 2Gb of memory, verifies image signatures, and blocks secrets from being sent to or from tools. Network blocking (--block-network) is off by default. ToolHive takes the opposite default. Since v0.30.1, every thv run gets an egress proxy, a DNS container and an ingress proxy. Only the hosts and ports in the server's permission profile are reachable. The catch is that isolation covers HTTP and HTTPS only. A database server that needs raw TCP has to opt out with --isolate-network=false. Arcade doesn't sandbox servers at all. It hosts its own tools, and any remote MCP server you register keeps running wherever its owner runs it. If what you need is sandboxing rather than a gateway, see Self-hosted sandboxes for agents compared.
Who the client is. Docker's gateway has no OAuth layer for clients. Over HTTP it refuses unauthenticated requests unless --allow-unauthenticated is set, and it uses MCP_GATEWAY_AUTH_TOKEN to protect localhost against DNS rebinding. On the server side, its README says it runs the OAuth flows for servers that need access tokens. That is enough for one developer, but it gives you no per-user identity for clients. ToolHive validates OIDC tokens on each server (--oidc-issuer, --oidc-audience), and authorizes calls with Cedar policies. Its vMCP aggregator splits client auth from backend auth (the docs call this a "two-boundary" model). It can also run an embedded authorization server and exchange tokens for backends with RFC 8693. For remote servers that ToolHive proxies, --remote-auth-resource sets the RFC 8707 resource. Arcade is built around end users. They sign in with Arcade or with your own OIDC provider (Auth0, Clerk, Entra ID, Okta or Stytch). Clients that can't run a browser flow can send an API key plus an Arcade-User-ID header instead. You can allowlist CIMD client IDs, such as Claude's and VS Code's, so those users skip the consent screen. The client half of this is covered in Agent identity and MCP auth compared.
What the model sees. All three let you restrict which tools are exposed:
- Docker sets tool allowlists per profile, or at run time with
--tools server:tool. - ToolHive has
--toolsand--tools-overrideon each server. - Arcade has a per-gateway list of allowed tools.
Two of them go further than listing tools. ToolHive's vMCP optimizer replaces the whole tool list with two primitives, find_tool and call_tool. Its README claims semantic tool search can cut token usage "by up to 85%". That is a vendor figure and was not measured here. vMCP also prefixes clashing names (github_create_issue, jira_create_issue), and adds composite tools and Starlark "code mode" scripts. Arcade's Tool Recommendation is on by default for new gateways in orgs that have it. It lists a few tools, and returns the allowed tools that fit each task the agent describes.
What gets recorded and limited. Docker logs calls by default (--log-calls), and its interceptors let you run your own script before or after a call. ToolHive has an audit log (--enable-audit) and Cedar policies, which deny by default once configured, and exports OpenTelemetry and Prometheus. Arcade is the only one of the three with native rate limits. Each rule is a tool matcher, a limit and a window. The counters are per tool, and are scoped to an organization or project. The docs note they are "not per user": everyone calling through the scope shares one counter. Arcade also keeps audit logs, which you can read through a REST API. If you need cost control per user or per agent, you have to build it on top of these.
Choosing
- You use Docker Desktop and want your coding agent's servers contained. Use Docker MCP Gateway. Turn on
--block-networkif the servers don't need the internet, and use profile tool allowlists to keep the tool list short. Background on adding servers to a client is in Add MCP servers to Claude Code. - Servers must reach only declared hosts, or you need identity and policy on Kubernetes. Use ToolHive. Its default egress allowlist and Cedar policies are the strictest combination here. vMCP gives a team one endpoint with per-user backend auth.
- End users sign in, and the tools act on their SaaS accounts. Use Arcade. It handles per-user OAuth to the SaaS services, gives you a hosted endpoint, and has rate limits and audit logs built in. You can self-host it with Helm if you need data residency.
- You are building the server yourself. A gateway can rename, filter or hide your tools. Run your contract tests and Inspector checks against the gateway endpoint as well as the bare server, as described in Test your MCP server.
Caveats
- Docker's docs describe an enterprise "MCP Gateway as part of Docker AI Governance" that is "an invite-only feature". This comparison covers the open-source
docker mcp gatewayonly. - I couldn't retrieve the latest Docker MCP Gateway release tag. The README's Docker Desktop 4.59+ requirement is the only version floor given here.
- ToolHive moves fast: v0.55.2 was released on 2026-10-19. Check flag names against
thv run --helpfor your version. - Arcade's docs pages were last updated on 2026-10-19. Features are enabled per organization, and Tool Recommendation in particular is the default only "in organizations with Tool Recommendation".
- There are other gateways and proxies that are not compared here because Index Agentica doesn't list them yet, such as agentgateway, MetaMCP, LiteLLM's MCP gateway and the mcp-proxy projects.
Directory entries in this comparison
- Docker MCP Gateway: Docker's open-source MCP gateway (the docker mcp CLI plugin behind MCP Toolkit): one endpoint that runs MCP servers in isolated containers and injects credentials.
- ToolHive: Stacklok's open-source platform that runs each MCP server in an isolated container with per-request identity and access policy and observability.
- Arcade: Actions runtime for enterprise AI agents: agent authorization, agent-optimized tools (MCP servers) and governance, plus an open-source MCP framework.
- arcade-mcp: Arcade's open-source Python framework for building MCP servers and tools, with authorized tool calling (OAuth, token refresh) and tool-call evals.
- Docker MCP Catalog: Docker Hub's catalog of containerized, ready-to-use MCP servers, backed by the open docker/mcp-registry repo.
- Docker Sandboxes: Docker's `sbx` CLI runs coding agents like Claude Code and Codex in isolated microVM sandboxes, locally for free or on metered Docker-managed cloud compute.
- Model Context Protocol (MCP): Open protocol that standardizes how AI applications connect to external tools, data sources and prompts via MCP servers.
- MCP Authorization (OAuth 2.1 for MCP): The MCP specification's transport-level authorization flow for HTTP-based MCP servers, based on a subset of OAuth 2.1 and related RFCs.
- RFC 8707: Resource Indicators for OAuth 2.0: IETF Proposed Standard adding a `resource` parameter so a client can tell the authorization server which protected resource a token is meant for (audience binding).
- RFC 8693: OAuth 2.0 Token Exchange: IETF Proposed Standard for exchanging one security token for another at the token endpoint, enabling delegation and impersonation flows.
- OAuth Client ID Metadata Document (CIMD): IETF OAuth draft letting a client identify itself with a URL as its client_id, pointing to a metadata document, without prior dynamic registration.
- MCP Inspector: Official interactive developer tool for testing and debugging MCP servers in the browser, on the command line or in the terminal.
Related
- Test your MCP server with in-process tests and Inspector CI checks (Guide)
- Self-hosted sandboxes for agents compared (Comparison)
- Agent identity and MCP authorization platforms (Comparison)
- Add OAuth authorization to your own MCP server (Guide)
- Connect an agent to a remote MCP server (Guide)
- DevOps and observability MCP servers compared (Comparison)
- Pick an MCP server (Skill)
Sources
- Docker MCP Gateway README, accessed
- Docker docs, MCP Gateway, accessed
- docker mcp gateway run reference (docs/generator/reference/docker_mcp_gateway_run.yaml), accessed
- ToolHive README, accessed
- ToolHive releases, accessed
- ToolHive docs, CLI quickstart, accessed
- ToolHive docs, Network isolation, accessed
- ToolHive docs, Authentication and authorization (CLI), accessed
- ToolHive docs, thv run reference, accessed
- ToolHive docs, Virtual MCP Server concepts, accessed
- ToolHive docs, Run vMCP locally with the CLI, accessed
- Arcade docs, MCP Gateways, accessed
- Arcade docs, Create an MCP Gateway via the Dashboard, accessed
- Arcade docs, Rate limiting, accessed
- Arcade docs, Audit logs, accessed
- Arcade docs, Deploy, accessed
- Arcade docs, Self-host with Helm, accessed