MCP Gateway
Tool Access Your Auditor Can Read
An MCP gateway is the governed layer between AI agents and the tools they call over the Model Context Protocol: it holds the tool registry, decides which role may invoke each tool, runs the server that exposes internal systems as tools, and records every invocation. VDF AI runs that layer inside your perimeter, so an agent gains reach into Jira, GitHub or a database only where an administrator granted it.
Your systems registered as tools. Grants assigned per role, never per prompt.
Every call written to the same audit trail as the model decision.
Bring the systems you would never expose to an agent. Those are the interesting ones.
What MCP changed, and what it left open
- Connecting an agent to a system stopped being a bespoke integration
- Which also means a developer can hand an agent production reach in an afternoon
- The protocol carries no notion of who approved the connection
- Tool calls act on systems, yet are usually logged less carefully than the text the model returned
What the gateway adds
- A registry an administrator governs, with grants assigned per role: VDF AI Agents
- An MCP server layer that exposes internal systems as tools inside your network
- Skills that direct how a tool is used without widening what the agent may reach: Agent Skills
- One audit trail covering the model decision and the tool call: AI governance platform
- The same discipline applied to model traffic: AI gateway
Tools Wired Into Agents
or Tools Granted From a Registry
Tools wired per agent
- Credentials pasted into an agent configuration
- Access widened by editing a prompt
- No inventory of which agents can reach which systems
- Revocation means finding every agent that used it
- A read tool and a write tool treated identically
- Tool output logged, if at all, by the application
MCP gateway
- Credentials held by the tool server, not the agent
- Access granted in the registry, per role
- One inventory of tools, owners and grants
- Revoking a grant takes effect everywhere at once
- Actions that write can require approval
- Every invocation recorded with the agent that made it
Register. Grant.
Record.
Register the systems you already run
Jira, GitHub, GitBook, Slack and your own services are exposed through the MCP server layer as tools with declared parameters. An internal API becomes an agent capability by being wrapped as an MCP endpoint and registered, rather than by opening a new network path.
Grant by role, not by prompt
An administrator assigns tools to roles; an agent inherits only what its role holds. A Skill can prescribe the method for using a tool without expanding the tool set, which keeps the question of capability separate from the question of instruction.
Record what was actually done
Each invocation is written with the agent, the role it acted under, the tool and its parameters, next to the model decision that led there. That single trail is what turns "an agent updated the ticket" into an event a reviewer can reconstruct months later.
Where MCP governance can live
| Concern | Hosted MCP service | Per-agent configuration | VDF AI MCP gateway |
|---|---|---|---|
| Tool server reaches internal systems from | Vendor network | Wherever the agent runs | Inside your perimeter |
| Grant model | Per connection | Per agent, by hand | Per role, in the registry |
| Works air-gapped | No | Sometimes | Yes |
| Inventory of agent-to-system reach | Partial | None | The registry is the inventory |
| Audit of tool calls | Vendor-side | Application logs | Platform audit trail |
| Revocation | Per connection | Find every agent | One registry change |
Eight questions to ask about MCP tool governance
MCP moved fast enough that most estates adopted it before anyone wrote the policy. These questions surface the gap between "our agents can use tools" and "we can say who authorised what". The protocol itself is explained in the Model Context Protocol guide.
- Who decides which agent may call which tool?Tool access is authority. If any agent can reach any registered tool, the registry is a directory, not a control point.
- Where does the MCP server run?A tool server reaches into ticketing, repositories and file stores. Hosting it outside your perimeter hands a third party a path into all of them.
- Can you add your own systems as tools?Most of what an agent needs is internal. Ask how an internal service becomes an MCP endpoint, and who approves it when it does.
- Is a tool call recorded as carefully as a model call?The model produced text; the tool changed something. The write path is the one an auditor will ask about first.
- What stops a Skill from widening tool access?A procedure should be able to guide how a tool is used without granting a tool the agent was never given.
- How are destructive actions handled?Reading a ticket and closing a ticket are different risks. Ask where approval sits for actions that write.
- Does it work with no internet access?MCP is a protocol, not a cloud service. In an air-gapped estate the tool server and every tool it exposes must run locally.
- What happens when the protocol changes?MCP is young and moving. Ask who maintains compatibility for your registered tools when it does.
What sits either side of the tool registry
Tools are one half of what an agent may do. The model it may call is the other, and both belong under the same governance.
- Tool catalogueThe tools agents can be granted, by category.
- VDF AI AgentsThe workspace where agents are built and granted tools.
- VDF AI NetworksMulti-agent orchestration invoking MCP actions across providers.
- AI gatewayThe same control applied to model traffic.
- Model Context ProtocolWhat the protocol is and how tool calls are structured.
- Tool use and function callingThe mechanics underneath MCP.
- Agent security handbookControls for agents that act on real systems.
- AI agent platformThe platform this registry belongs to.
Questions about MCP gateways
What is an MCP gateway?
An MCP gateway is the governed layer between AI agents and the tools they call over the Model Context Protocol. It holds the registry of available tools, decides which agent or role may invoke each one, runs the MCP server that exposes internal systems as tools, and records every invocation for audit. Without it, MCP gives an agent reach into enterprise systems with no place to state who approved that reach.
What is the Model Context Protocol?
The Model Context Protocol, or MCP, is an open standard for connecting AI models to tools and data sources through a common interface, so a capability written once can be called by any compatible agent or client. It replaced a generation of bespoke function-calling glue. The protocol itself says nothing about who is allowed to call what, which is precisely the gap a gateway fills. The concept guide covers the mechanics in full.
Do we need an MCP gateway if we already have an API gateway?
They govern different things. An API gateway governs service-to-service traffic by path and method. An MCP gateway governs which autonomous agent may invoke which capability, on whose authority, and what evidence that leaves behind — decisions that depend on the agent and its role rather than the route. Enterprises that run both typically expose internal APIs through the API gateway and then register a subset of them as MCP tools, with narrower grants.
Can we run an MCP server on our own infrastructure?
Yes, and in regulated environments it is the only sensible option. VDF AI runs the tool server inside your perimeter, including air-gapped estates, exposing systems such as Jira, GitHub, GitBook, Slack and your own APIs as governed tools. Internal services are wrapped as MCP endpoints and registered in the platform tool registry, so agents gain the capability without anyone widening network access by hand.
How is tool access granted and revoked?
An administrator assigns tools to roles in the registry, and an agent inherits only what its role holds. Because the grant lives in the registry rather than in an agent prompt, revoking access is a registry change that takes effect for every agent that depended on it, and the change is visible in the audit trail rather than buried in a prompt revision.
See enterprise AI agents in production
Watch how VDF AI runs governed, multi-agent workflows on your own infrastructure — then compare it against the platforms you are evaluating.