Every team that gives an agent a tool stands up another server, and every client has to be told about all of them. None of those servers knows who is calling, and the whole tool catalog goes to the model on every turn.
Put one controlled endpoint in front of every MCP server and REST API your agents call: tools scoped to the caller, identity that survives the hop to the backend, and a measured reduction in what each agent carries in context.
Common Challenges
What you build
- One endpoint, every client.
MCP servers are added and removed behind the gateway. Clients are configured once, with one address, and never again.
- REST APIs served as tools.
Point the gateway at an OpenAPI document and its operations become MCP tools. The gateway is the server, so there is nothing for your team to write or run.
- Tools scoped to the caller.
Verified identity from the identity provider you already run, and tool-level authorization keyed to group claims. A tool a caller cannot see cannot be called, and cannot pack the context window.
- Identity that survives the hop.
The gateway exchanges the caller's token for one addressed to the specific backend, so the downstream service receives a token naming the user and valid nowhere else.
- Both specifications, one policy.
Session-based and stateless MCP servers behind the same endpoint, with version translation handled by the gateway, so a mixed fleet is not a second policy set.
Common questions
Q. How do I stop every agent from seeing every MCP tool?
Put the servers behind a gateway and apply tool-level authorization there. The gateway verifies the caller's token and filters the tool list against a claim, usually group membership, so each caller is offered only what they are entitled to. A tool a caller cannot see also cannot be called by name.
Q. How do I reduce the context my agents spend on tool definitions?
Scope the catalog before you compress it. Tool definitions are sent to the model on every request, so the largest reduction comes from each caller being offered only the tools they are entitled to. In the validated deployment this took one caller from twenty tools to four, from 2,200 tokens to 308. Progressive disclosure and code mode help further above roughly five and fifteen authorized tools respectively.
Q. How do I expose a REST API to agents without writing an MCP server?
Give the gateway the API's OpenAPI document. Each operation is served as an MCP tool, so agents reach the API through the same endpoint as everything else and there is no wrapper service to deploy, secure or version.
Q. Can I run session-based and stateless MCP servers at the same time?
Yes. Both sit behind one endpoint under one authorization policy, and the gateway translates between specification versions so existing clients keep working while you migrate. Note that a federated endpoint negotiates the version every target can serve, so a modern-only endpoint alongside it is the pattern for a mixed fleet.
Q. What identity does an MCP server receive when the call comes through a gateway?
Whatever you configure it to receive. Forwarding the caller's own token couples the backend to your identity provider; using a service account loses the user entirely. Token exchange gives you a third option: the gateway issues a token that names the caller, is addressed to that backend alone, and cannot be replayed anywhere else.
