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.
Capability profile01 02 03 04 05 06 07 08 09 10 11
What the gateway governs, exactly.
Governance coverage is not integration coverage. This is the gateway’s profile: what it decides, what it reads, what leaves the host, how it fails and where the record lands. It is rendered from the same record the machine reads at adapters.json, where every statement is bound to the source that implements it.
Pre-execution enforcement
Every tools/call is adjudicated before it is forwarded. A refused call is answered to the agent as a JSON-RPC error (code -32000, data.governed = true) and never reaches the server, so the side effect does not happen. A refused notification (no id) is dropped, not answered, because answering a notification would corrupt the stream.
What is decided
tools/call is decided. Every other JSON-RPC method passes through unchanged: the gateway governs what an agent does, not the protocol around it.
What of the arguments is read
The tool name and the names of its argument keys travel to the control plane as metadata (tool, argKeys). Argument values never leave the host.
Responses
Responses from the server pass through untouched. The gateway decides actions; it does not read or rewrite results.
Discovery
tools/list, resources and prompts pass through. What an agent may discover is not narrowed; what it may do is decided. Narrowing discovery while leaving action ungoverned would be theatre in the wrong place.
When no decision can be obtained
A call is allowed only when the control plane says so explicitly. Unreachable, timed out, non-2xx, a body that is not JSON or lacks the boolean authorized field: each denies with its own reason, so an operator can tell an outage from a policy refusal.
Where the record lands
Each decision is a call to the control plane, which records it in the tamper-evident audit trail with the tool's identity. Denials are also written to the gateway's stderr on the host. The gateway keeps no local log of its own.
What is sent to the control plane
One authorization call per tool call, carrying the agent identity, the governance action class (execute) and scope (mcp), and the tool name and argument key names as metadata. Nothing else leaves the host.
Degradation
When no decision can be obtained the call is refused, with the reason named. Governance that opens the moment it loses its connection is not governance.
What changes on the host
In the agent's MCP configuration the server is launched through the gateway instead of directly. Nothing on the server changes.
Configuration
Four environment variables. A missing endpoint is refused at start, once, rather than as a stream of denials that would read as policy refusals.
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.