What is an MCP gateway?
On this page
An MCP gateway sits between an AI application's MCP client and the MCP servers it uses. It can bring several server connections behind one endpoint and apply rules before forwarding requests. The servers still provide the tools and data; the gateway manages how clients reach them. Toolstile applies this model as a managed service.
MCP stands for Model Context Protocol. It gives AI applications a common way to discover and use capabilities supplied by servers: tools that perform actions, resources that provide context, and prompts that supply reusable templates. The official MCP architecture overview explains those building blocks.
The request path through a gateway
With a direct connection, you configure each server in the application that uses it. With a gateway, you configure the application to reach the gateway, then manage the server connections there.
A typical request follows this path:
- The client asks the gateway which capabilities it can use.
- The gateway returns the capabilities available to that client's authorization.
- The client sends a request for one of them.
- The gateway checks access, forwards the permitted request to the connected server, and returns the result.
For example, a team might let one coding agent read issues while another can also create them. Both use the gateway, but their permissions differ. The upstream service's account permissions still apply: a gateway grant cannot give an account access the service itself denies.
Exact behavior depends on the gateway. Aggregation, permission controls and activity logging are product features to check, not guarantees that follow from the MCP name.
MCP gateways, servers and registries
An MCP server exposes capabilities. A gateway connects clients to capabilities from other servers and may restrict access along the way. To the client, the gateway presents an MCP endpoint; behind it, the original servers continue to do the work.
A gateway also differs from a registry. A registry helps people discover servers. It does not, by itself, decide whether a particular agent may call a tool. You may also see the phrase “MCP proxy.” Check what the product actually manages rather than assuming that the label includes permissions, account handling or logging.
When a gateway is useful
A gateway becomes useful when access needs differ between agents, server configuration is repeated across clients, or a team needs a shared place to manage accounts.
Consider an agent that needs one read tool from a server with several write tools. A gateway with per-agent permissions can expose only the allowed tool. Or consider a shared service account: the gateway can forward authorized calls without every team member entering that account's credentials in a client.
Direct connections may be enough when your setup is small and you are comfortable managing each server and its access separately. A gateway adds another service in the request path, so its availability, data handling and usage limits become part of your setup.
Choosing an MCP gateway
Start with your actual clients and servers. Check supported connection types, authentication, which MCP capabilities can pass through, and whether permission checks apply to both discovery and use. Review how accounts are selected and what happens when one needs reconnection.
Then examine logging and limits. Find out whether full request contents are stored, who can enable capture, and what happens when an allowance is exhausted. A gateway can restrict access to connected capabilities; it does not make an untrusted server or an unsafe tool harmless.
A managed gateway puts operation of that service with its provider. Running a gateway yourself puts deployment, updates and service recovery with you. In either case, review where credentials and request data are processed before routing work through it.
How Toolstile uses this model
Toolstile is a managed MCP gateway for public HTTPS MCP servers. Each agent authorization belongs to one workspace. You grant access per agent, and explicit blocks override grants. Full access includes supported capabilities the server adds later, so selected grants are useful when you want a narrower boundary.
Personal and team catalogs stay separate. In a team workspace, approved shared accounts can have a workspace default and a member's preferred account. Toolstile does not silently switch accounts if the selected one becomes unavailable.
For setup instructions, start with the getting started guide. For the rules behind an access decision, read about permissions.