Interpose, not observe
The gateway sits on the wire between the agent and the server. It refuses a call rather than reporting it after the side effect already happened. That is the difference between a governance layer and a log.
MCP Gateway · Apache-2.0
Govern any MCP server. Change nothing.
The Agentomy MCP gateway interposes between your agent and any MCP server. Every tool call is checked against your policy before it runs, and a call you refuse is stopped, not just logged. The server is never patched, forked, or told it is governed. One config line.
Why a gateway01 02 03 04
A monitor tells you what it failed to stop.
Most tools that touch MCP traffic watch it and report. That produces a clean record of the calls they could not prevent. The Agentomy gateway sits on the connection itself, so a call your policy denies is refused before it reaches the server. Sitting on the wire is what turns a report into a refusal.
Change nothing on the host
The MCP server is never patched, forked, or reconfigured, and never learns it is governed. You change one line in the agent's config, and nothing else.
Policy before the call runs
Every tool call is checked against your Agentomy policy before it reaches the server. A refusal is answered by the gateway and never forwarded, so the action does not happen.
Fails closed
If the gateway cannot reach a decision, it denies. Governance that opens up the moment it loses its connection is not governance.
The whole integration
One config change, per agent.
In the agent’s MCP configuration, launch the server through the gateway instead of directly. The gateway governs every tools/call and passes the rest through untouched.
{
"mcpServers": {
"dev-tools": {
"command": "agentomy-mcp-gateway",
"args": ["--", "your-mcp-server", "--its-flags"],
"env": {
"AGENTOMY_ENDPOINT": "https://your-agentomy",
"AGENTOMY_API_KEY": "..."
}
}
}
}Or wrap it at the command line: agentomy-mcp-gateway -- your-mcp-server --its-flags. Works with any stdio MCP server and any MCP-speaking environment, Claude Code, Cursor, and VS Code included.
Govern the tools your agents already call.
FAQ
MCP gateway, answered.
MCP (Model Context Protocol) is the open standard that connects an AI agent to the tools and servers it acts on. An MCP gateway sits on that connection. The Agentomy MCP gateway interposes between the agent and any stdio MCP server: every tool call is checked against your policy before it reaches the server, and a call your policy refuses is answered by the gateway and never forwarded, so the side effect never happens.
A monitor or sidecar watches the traffic and reports on it, which produces a record of the things it failed to stop. The gateway sits on the wire itself, so it can refuse a call rather than describe it after the fact. Sitting on the path is what turns a report into a refusal.
No. The server is never patched, forked, or reconfigured, and it never learns it is being governed. You change one thing: in the agent's MCP configuration, you launch the server through the gateway instead of directly. That is the whole integration, one config change per agent, made by the operator.
It fails closed. A governance layer that fails open the moment it loses its connection is not governance, so when the gateway cannot get a decision it refuses the call rather than letting it through.
Any stdio MCP server, and any agent environment that speaks MCP, including Claude Code, Cursor, and VS Code. The gateway is server-agnostic by design: it governs the tool calls, not a specific vendor's server, so the same one line governs whatever you point it at.