What is an MCP gateway, and when does a team need one?
The Model Context Protocol (MCP) has become the common way to connect AI assistants to other systems. An MCP client, for example Claude Code, Cursor or VS Code, talks to an MCP server, and the server offers tools such as "search Jira issues" or "create a pull request comment". The model decides which tool to call, and the server executes the call against the real system.
This works well for one developer and one tool. It becomes harder to manage when a company has many agents, many tools and requirements from security or compliance. An MCP gateway addresses this by putting one control point between all MCP clients and all tools. This article explains what a gateway does, how it differs from connecting MCP servers directly, and when the additional component is worth it.
How agents connect without a gateway
In the direct setup, every developer configures the MCP servers they need in their client. Each server authenticates to its target system with a credential, typically a personal API token or an OAuth grant of the person who set it up. Some vendors now offer their own remote MCP servers, which work the same way: the agent acts with the permissions of the connected user.
This has three practical consequences. First, the agent usually holds the full rights of a person, although it only needs a small part of them. A token that allows reading tickets often also allows deleting them. Second, there is no single place to see which agents can reach which systems; the configuration lives in individual clients and personal tokens. Third, logging depends on each target system. Some record API calls in detail, some barely at all, and none of them record what the agent tried but was not allowed to do.
What an MCP gateway does
A gateway is a proxy that speaks MCP to the clients and talks to the target systems on their behalf. The agent no longer holds credentials for Jira or GitHub; it holds one key for the gateway. The credentials for the target systems are stored in the gateway, encrypted, and are never handed back to the client.
For every call, a gateway typically runs the same sequence:
- Authentication. Who is calling? The request carries an API key that identifies a person or an agent.
- Authorization. May this caller run this operation, on this resource, with these parameter
values? For example: read issues, but only in project
MOB, and never delete. - Data rules. Are there values in the request or the response that must not pass, such as email addresses or bank account numbers? These can be masked or removed.
- Rate limiting. Is the caller within its limits? A misbehaving agent loop should be slowed down before it creates hundreds of tickets.
- Audit. The call is recorded with its outcome, whether it was allowed, denied, held for approval or rate limited.
A useful side effect is that the agent only sees the tools it may call. The list of available tools is filtered before it reaches the model, which also reduces the chance that the model tries an operation it has no business with.
Gateway vs. direct MCP servers
The difference is less about features and more about where decisions are made. With direct servers, access control is a property of each token and each target system. With a gateway, it is a policy in one place, evaluated on every call.
| Question | Direct MCP servers | MCP gateway |
|---|---|---|
| Which rights does the agent have? | Those of the token owner | Those granted per operation |
| Where is access configured? | In each client and each tool | In one policy |
| Are denied attempts recorded? | Usually not | Yes, with the reason |
| Can one key be revoked for all tools? | No, one token per tool | Yes |
| Who holds the tool credentials? | The client machine | The gateway |
A gateway does not replace the permission model of the target system. Jira still enforces its own rights on the account the gateway uses. The gateway adds a narrower layer on top, specific to the agent and the task.
When a team needs a gateway
Not every team needs one. A single developer experimenting with an agent against a test project can work without a gateway, and adding one would mostly add setup effort.
The situation changes when several of the following apply:
- More than a handful of people or agents use AI clients against shared systems.
- Agents are allowed to write, not only read: tickets, pull requests, pages, messages.
- The systems contain personal or customer data.
- Security or compliance asks who can access what, and wants evidence.
- The company uses more than one AI client or provider and does not want to configure governance again for each of them.
In these cases, the effort of one central component is usually lower than the effort of reviewing access spread across many tools and personal tokens. Two concrete examples of such write access are an agent that prepares sprints in Jira and an agent that reviews pull requests on GitHub or Azure DevOps.
What to look for in an MCP gateway
Gateways differ considerably. The following criteria help to compare them:
- Granularity. Can access be limited per operation and per parameter value (for example, per repository or per Jira project), or only per tool?
- Response filtering. Can fields or sensitive values be removed from what the tool returns, before the model sees it?
- Audit quality. Is the log tamper evident? Does it include denied calls? Can it be exported to existing security tooling?
- Deployment. Does the gateway run on your infrastructure, or does every call pass through a third party's cloud?
- Interfaces. Is it MCP only, or can scripts and CI jobs use the same governed operations over REST?
- Coverage. Which tools and which operations are supported today?
How Vordix implements this
Vordix is a self-hosted MCP gateway. It runs as a Docker Compose deployment on the customer's own infrastructure, and no Vordix-operated service sits in the request path.
Access is configured in three levels. The organisation sets a ceiling of what may be allowed at all; a project selects within that ceiling; and a workspace, which is a gateway endpoint with its own URL, rate limit and kill switch, is what an agent actually connects to. Rules that apply to a single agent are expressed by giving that agent its own workspace. Within these levels, access can be limited by integration, operation, parameter value and response field. Every operation is available over MCP and over REST.
Every call is written to an append-only, hash-chained audit log, including denied calls and the reason. Human users can sign in via SSO (for example Entra ID or Okta), and API keys are shown once and stored only as hashes. The supported tools cover planning, documentation, code, data and communication; the overview of AI agents in the software development lifecycle walks through them stage by stage.
Trade-offs and limitations
A gateway adds a network hop to every call, and it adds a component that has to be operated and kept available; if the gateway is down, the agents cannot reach the tools. It also needs someone who owns the policies. The main limitation in practice is coverage: a gateway can only govern the operations it implements, so a team should check that the operations it needs are supported before moving agents behind it.
Conclusion
An MCP gateway turns agent access from a property of many personal tokens into one reviewable policy, evaluated on every call and recorded in one log. For a single developer this is often more than needed. For a team with several agents, write access and sensitive data, it is a practical way to let agents work without losing track of what they can do. How such a log should look is covered in what an audit trail for AI agents should contain.
To see a gateway configured for your own tools, you can request a Vordix demo.