Choose your setup
What is an MCP gateway?
An MCP gateway is a proxy that every agent connects through instead of connecting to each MCP server directly, so one place can decide who may call what, hold the keys and write down what happened.
New to MCP? What is an MCP server? covers the basics first.
An MCP gateway is a proxy that sits between your AI agents and the MCP servers they call. Instead of each agent connecting straight to Jira's server, GitHub's server and your internal database server, every agent connects to the gateway, and the gateway connects onward. That single point decides which agent may call which tool, holds the credentials those servers need, and logs every call.
MCP doesn't require one. Teams add it when connecting agents straight to servers stops being enough.
What it does
Four jobs show up in most gateways, under different names.
- Authentication. The agent authenticates once to the gateway, usually with a short-lived token, instead of each MCP server checking the agent itself.
- Per-tool access control. MCP hands a connected client every tool a server offers. A GitHub server that exposes
list_issuesalso exposesmerge_pull_request, and the protocol doesn't separate them. A gateway is where that separation gets added, so an agent can be granted the read tool and denied the one that merges. - Credential injection. The agent never sees the upstream API key for Jira or GitHub. It calls the gateway, and the gateway attaches the real credential before the request goes out. The agent's config holds one gateway token, not a key per service.
- Logging and scanning. Every call goes in a record: agent, tool, server, result, and whether it was allowed. Some gateways also scan calls or tool descriptions for known attack patterns before they reach a server.
A gateway that only handles authentication won't get far in a security review.
How this differs from an LLM gateway and an API gateway
An LLM gateway sits in front of model calls: routing a chat completion to OpenAI, Anthropic or a local model, with per-provider keys, rate limits, cost tracking and fallback. An MCP gateway sits in front of tool calls: a tools/call request and whatever a tool returns from Jira, GitHub or a database. Some products bundle both, but a gateway that only proxies model calls has nothing to say about which tools an agent can reach, since it never sees a tool call.
An API gateway sits in front of a company's own APIs, routing and rate-limiting requests from developers and services calling fixed HTTP routes. An MCP gateway governs a different unit: the tool, as described to a model that picks which one to call at the moment it answers you. A classic API gateway has no concept of a tool description, and nothing in it decides whether an agent, as opposed to a service account, should be allowed to call delete_repository this time. Some MCP gateways are built on API gateway technology underneath, but the access decision is specific to tools and agents.
A worked example
An agent is connected through a gateway to a GitHub MCP server and a Jira MCP server. Without the gateway, its client config would hold both API tokens directly, and it would see every tool each server offers, merge_pull_request and delete_issue included.
With the gateway, the agent holds one token, for the gateway itself. An admin granted it the Jira server with search_issues and add_comment, and denied delete_issue. It has no grant on the GitHub server at all. When the agent calls search_issues, the gateway checks the grant, attaches the real Jira credential, forwards the call and logs the result. When text in a Jira comment tries to talk the model into deleting an issue, the call to delete_issue is refused, and that refusal is the log entry someone reads later.
The gateway didn't stop the model from being talked into trying. It stopped the attempt from reaching Jira and left a record of it, which is the limit of what any gateway does: narrow what a compromised agent can reach, and make the attempt visible. No gateway, Statio included, stops prompt injection itself.
When you need one, and when you don't
A gateway earns its place once more than one agent or person shares a server, or once a server has a tool you'd hate to see called by mistake.
A solo developer with one agent talking to one MCP server that only reads doesn't need one yet. Put the key in an environment variable and move on. That changes when a second agent connects to the same server, or when a server has a tool that changes data.
What to look for when choosing
A few things decide whether a gateway fits a given team, independent of which product you pick:
- Granularity. Does it stop at the server, or can it grant and deny individual tools?
- Agent identity. Does each agent get its own credential and log entry, or does it borrow a person's token?
- Where keys live. Does the upstream credential ever reach the agent's process, or only the gateway?
- Hosting. Managed, or can you run it in your own cloud, and does that matter for a security review you're already in?
- Logging and export. Does it record refusals as well as successes, and can the log leave the vendor's dashboard into your own SIEM?
- Running servers too. Does it only sit in front of servers that already exist, or can it run one for you, including one generated from your own API?
- Price shape. Per seat, flat per team, or usage based, and how that scales as you add people.
Best MCP gateways works through these in more depth and names where specific products land on each one. Self-hosted MCP gateway covers the hosting question, including open-source options. If you already have a couple of vendors in mind, the comparison pages go through named products side by side rather than this page trying to.
Statio as one option
Statio is a gateway built around per-tool grants: an agent gets a server, then individual tools are denied or granted on top, checked on every call. Agent identity gives each agent its own short-lived token instead of a shared one. Upstream credentials are encrypted and never returned to the agent, which /security describes in detail. Audit logs record every call and refusal, with a signed export for a SIEM on Business and up. The MCP security checklist is a free way to see where your current setup stands against the list above before you look at any gateway. The server catalog covers which MCP servers are available to connect.
Statio has no SOC 2 report, ISO 27001 certification or other third-party attestation. Its logs and access controls can produce evidence a security reviewer asks for, which how to get AI agents through a security review covers, but using a gateway doesn't make an organization compliant on its own.
Next
- Best MCP gateways: six questions that decide which one fits
- What is an LLM gateway?
- Local vs. remote MCP servers
- API keys vs. OAuth for MCP
- Shadow MCP: the servers nobody approved