An MCP gateway is an intermediary endpoint between AI clients and one or more Model Context Protocol servers. It can authenticate clients, route calls, apply access policies, manage downstream credentials, filter or aggregate tools, and centralize observability.
You do not need one simply because you use MCP. Two or three stable, low-risk servers may remain manageable through version-controlled client configuration and a suitable secrets process. A gateway becomes more compelling when separate connections create a concrete problem with credential custody, revocation, identity-specific permissions, incident investigation, or shared call records.
This guide separates two decisions that are often conflated: using a gateway for governance and using filtering or search to reduce the tool definitions presented to a model. It then compares operating models and sets out a staged migration that preserves rollback.
What an MCP gateway does, and when you need one
A client such as Claude, Cursor, or a custom agent connects to the gateway rather than configuring every upstream server independently. Depending on the product, the gateway can identify the caller, expose selected tools, aggregate definitions, route calls to the owning server, obtain downstream credentials, enforce policy, and record activity. These are implementation-specific capabilities, so verify each control in the product documentation.
Keep the surrounding terms distinct:
- Registry: metadata and discovery for servers. The official MCP Registry is in preview and publishes metadata primarily for publicly accessible servers. It does not route MCP requests or directly support private servers.
- Catalog: a curated offering of servers or tools.
- Gateway: request handling, routing, and potentially policy enforcement and observability.
- Tool search: a method for finding relevant tools in a larger catalog.
- Policy engine: rules that decide whether a principal or request is allowed.
Some products combine these functions. Shortlist a gateway only when it addresses an identified operational need, and document who owns the simpler direct configuration when a gateway is not warranted.
A gateway solves a governance problem only when its controls are configured and tested. Reducing model context requires explicit filtering, pagination, or search.
Separate governance from context reduction
Putting servers behind a gateway does not inherently reduce token usage. If the gateway exposes the same complete catalog, the client may receive essentially the same tool definitions. Context changes only when the client or gateway exposes fewer definitions, loads them on demand, or otherwise changes the tools presented for a task.
Who may call which tool?
Use identity-aware policy, downstream authorization, and call records. Measure discovery and invocation decisions for each identity.
Which definitions does the task need?
Use fixed allowlists, filtered or virtual tool sets, pagination where supported, or runtime search. Measure definition context and task success on the same test set.
Anthropic’s tool-use research describes large MCP catalogs consuming tens of thousands of tokens and presents on-demand discovery as a way to load relevant definitions. Those examples are not a universal threshold or a promise of a fixed reduction. Measure your own tools/list payload, selected tools, context, and task results.
A fixed allowlist is usually the better starting point when roles and tasks are stable and least privilege matters more than catalog breadth. Search is more useful when the catalog is large or changes often, but a search result is not permission to invoke the returned tool. Define success before testing: exact tool match, acceptable top-k retrieval, or completed task.
Choose a gateway by operating model
Shortlist by deployment boundary first, then validate identity granularity, credential handling, tool filtering, audit export, protocol support, and total operating cost. The table summarizes documented capabilities, not independent security, reliability, or performance ratings. Features, versions, licensing, and regional availability can change, so check the current documentation before committing.
| Operating fit | Documented capability | Tradeoff to investigate |
|---|---|---|
| Docker-based local development | Docker MCP Gateway documents routing, profiles, authentication, isolated containers, logging, and call tracing. | Docker AI Governance is described as invite-only. Verify current deployment, credential, and governance requirements. Dynamic MCP is experimental. |
| Self-managed platform | IBM ContextForge presents an open-source gateway, registry, and proxy for MCP, A2A, REST, and gRPC APIs. The project is Apache-2.0 licensed. | Plan for deployment and operations. Use version-specific project documentation for identity, credentials, logging, and integrations. |
| Existing Kong platform | Kong AI MCP Proxy documents MCP proxying, aggregation, REST conversion with valid OpenAPI schemas, ACLs, and audit logging. | The plugin requires an AI Gateway Enterprise license. Confirm the gateway version, ACL behavior, upstream protocol, and commercial terms. |
| AWS-managed deployment | Amazon Bedrock AgentCore Gateway aggregates MCP targets and can expose supported APIs, Lambda functions, OpenAPI specifications, and Smithy models. | Semantic search is optional and depends on configuration and Region. Calculate current gateway, search, observability, and related service costs from the AWS pricing page. |
| Managed SaaS tool access | Composio Tool Router documents user-scoped sessions and tool access. Composio currently advertises more than 1,500 toolkits. | Review credential custody, cloud dependence, tool restrictions, and approval compatibility. Relevant approval flows are documented as experimental. |
Compare total operating cost rather than a license line alone. Include usage or license charges, hosting, patching, credential operations, observability, support, and the cost of operating a rollback path. Open-source licensing does not remove operational work, and managed infrastructure does not remove access-review responsibilities.
Design authorization and credentials as separate checks
A tool missing from discovery is not necessarily protected from invocation. A client may know a tool’s name, and products differ in whether a denied tool disappears from tools/list, fails at tools/call, or does both. Test both paths, including a direct attempt to call a restricted tool by its known name.
The current MCP security guidance says an MCP server must not accept a token that was not issued for that server. Validate the inbound token for the gateway’s intended audience. Use a separately authorized downstream credential or authorization flow for the upstream. Do not treat the client’s gateway credential as an upstream credential.
For each principal and tool, record expected and actual discovery and invocation decisions. A proposed audit record can include caller principal, client or agent, tool, upstream server, policy version, discovery decision, invocation decision, timestamp, outcome, and denial reason. These are recommended fields, not a vendor log schema. Verify what the selected product records and whether logs can be retained and exported as required.
For write-capable tools, deterministic controls should check identity, tenant or workspace scope, target record, current version where available, and rate limits. Let the model propose a bounded action; do not rely on model judgment to enforce authorization or prevent duplicates. If a write times out, its outcome may be unknown. Use documented upstream idempotency support where available. Otherwise persist an operation record and reconcile upstream state before retrying.
Treat discovery as a usability decision and invocation as an authorization decision. Store both results so a hidden tool, a denied call, and a routing failure cannot be mistaken for the same event.
Migrate one server at a time and preserve a rollback path
Start with an inventory owned by the platform or application team: clients, server owners, tools, data access, credentials, protocol versions, and read/write behavior. Classify tools by risk and remove unused ones before migration. Keep the existing direct configuration until the gateway route passes agreed tests.
Use separate data grains in the test ledger. A run-level record represents one test execution and stores configuration revision, model or client version, direct and gateway latency, task-result reference, and rollback decision. Child records represent individual searches or tool calls and store the upstream server, tool name, protocol version, policy version, authorization result, retry count, and duplicate-write result.
The following is an illustrative tool-call record, not a vendor-published schema:
{
"gateway_id": "gw-staging",
"client_id": "agent-test-01",
"run_id": "run-unique-per-test",
"tool_call_id": "call-unique-within-run",
"upstream_server_id": "server-readonly-01",
"tool_name": "search_records",
"policy_version": "policy-2026-10-01",
"authorization_result": "allow",
"retry_count": 0,
"rollback_decision": "hold"
}Enforce uniqueness at the data store, for example with a unique key on gateway_id + client_id + run_id + tool_call_id. A lookup followed by an insert can race when multiple runners write concurrently. Use a database-enforced unique constraint and an atomic insert or upsert. If the source provides a stable call ID, preserve it. Keep prompt-level outcomes in the run record rather than combining them with individual calls or daily aggregates.
Use ClickUp MCP as an upstream only after checking the client and limits
ClickUp documents its MCP endpoint as https://mcp.clickup.com/mcp and says the server is available on all plans. Its documentation lists task, Docs, comment, time-tracking, Chat, and reporting-related capabilities. Use ClickUp’s MCP server documentation for current connection requirements and limits.
Authentication is a specific integration constraint. ClickUp documents OAuth for its MCP server. A custom client must use JSON-RPC 2.0 over HTTP and support OAuth 2.1 with PKCE. ClickUp says API keys and Auth access tokens are not accepted for MCP authentication. Before routing ClickUp through a gateway, confirm support for the required OAuth flow, callback behavior, and downstream credential storage. Do not assume the gateway’s inbound credential can be passed through.
Without the Everything AI add-on, ClickUp documents rolling 24-hour MCP call limits of 100 on Free Forever, 300 on Core or Unlimited, 1,000 on Business, 2,500 on Business Plus, 5,000 on Enterprise, and 25,000 on Enterprise Plus. Limits are per workspace and per client; each tool call counts, while initialize and tools/list do not. With the add-on, ClickUp says requests follow Public API per-minute limits. Confirm the applicable plan limits and gateway behavior in a test workspace, then validate one read before enabling writes.
A practical gateway selection and launch checklist
- State whether the primary problem is governance, context cost, or both.
- Map identities to permitted tools and test discovery and invocation separately.
- Confirm inbound token audience, downstream authorization, and credential custody.
- Measure tool-list context and search success on representative tasks.
- Test expired credentials, upstream errors, timeouts, retries, and duplicate writes after an ambiguous timeout.
- Confirm log fields, retention, export, operating cost, and a tested rollback route.
Approve rollout only when the pilot meets pre-agreed access, failure, latency, context, and rollback criteria. Keep the direct route available until the gateway path is stable and its credentials can be revoked safely. For help defining an agent’s bounded role and operating controls, see AI agent consulting.