Architecture pattern
MCP tool access through a gateway
Give AI agents access to tools through Model Context Protocol servers behind one gateway that authenticates them, limits which tools they may call and records every call.
- Caller
- Gateway
- Component you run
- Control, identity or policy
- Outside your boundary
- Request
- Event or background
How it flows
- Coding assistant to Identity providerThe agent obtains a scoped OAuth token for the person it acts for.
- Coding assistant and Business agent to MCP gatewayAgents list and call tools through one endpoint.
- MCP gateway to Identity providerThe gateway validates the token and maps it to an allowed set of tools.
- MCP gateway to Audit log (asynchronous)Records who called which tool, with which arguments, and the result.
- MCP gateway to Tickets server, Knowledge server and Wrapped REST APIForwards only approved tool calls to registered servers.
- Tickets server to Ticketing system; Knowledge server to Knowledge base; Wrapped REST API to Internal APIsEach server calls its system with its own least-privilege credential.
The problem
The Model Context Protocol (MCP) gives agents a standard way to discover and call tools. That makes it easy for every team to stand up an MCP server, and easy for an agent to connect to many of them. Without a shared layer, each server handles authentication its own way, nobody has a complete list of which agents can call which tools, and there is no single audit trail when an agent does something unexpected.
When to use it
- Several agents, assistants or IDE tools need access to internal systems.
- More than a few MCP servers exist, or teams want to expose existing APIs as tools.
- Security needs to approve which tools each agent may use, and see what was called.
- You want agents to act with the permissions of the person they work for, not a shared superuser.
When not to
- A single local MCP server used by one developer over standard input and output. A gateway adds nothing there.
- Tools with irreversible effects (payments, deletions) that have no human approval step yet. Add the approval flow first; a gateway does not make an unsafe tool safe.
Key components
- MCP gateway. A single HTTP endpoint for agents. It authenticates each call, filters the tool list per agent, and forwards approved calls to registered servers.
- Identity provider. Issues OAuth tokens to agents, ideally on behalf of a signed-in user. The MCP specification uses OAuth 2.1 for remote server authorisation.
- Registered MCP servers. Each wraps one system and uses its own least-privilege credential to reach it. Existing REST APIs can be exposed as tools here.
- Audit log. Who called which tool, with what arguments, and what came back.
- Rate limits and budgets. Agents can loop. Limits per agent and per tool stop a runaway session from flooding a system.
Trade-offs
- Tool descriptions are prompts. A malicious or careless tool description can steer the model. Review and pin server versions rather than trusting whatever a server advertises.
- Protocol churn. MCP is young and its specification still changes. A gateway can absorb some of that, but plan for upgrades.
- Latency for chatty agents. Agents may make many small tool calls. Keep the gateway close to the servers and avoid heavy per-call processing.
- Coarse versus fine control. Filtering by tool name is easy; checking arguments (which customer, which amount) needs deeper policy and more maintenance.
Explore further
Lab: Agents call tools. Someone should check.→Step through how an AI agent discovers and calls tools with the Model Context Protocol, and see what a gateway adds between the client and remote MCP servers.
Lab: No single guard stops every injection.→Try curated prompt injection attacks against a mock support agent and see which layered defences stop each one.
Read: API Gateways for AI Workloads→How API gateways are evolving to handle the unique demands of LLM traffic — streaming, token limits, and semantic caching.