Agentomy MCP Gateway
OfficialThis server does not currently have a deployable release on Glama. Follow the repository's setup instructions to install and configure it for your MCP client, including any required credentials and local dependencies.
Agentomy MCP Gateway
An open piece of Agentomy, the governance layer for AI agents in regulated enterprises. See the others at github.com/getagentomy.
Governs any stdio MCP server by sitting between the agent and the server. Every
tools/call is checked against your policy before it reaches the server. A refusal is
answered by the gateway and never forwarded, so the side effect does not happen.
Nothing about the upstream server changes. It is not patched, not forked, and never learns it is being governed.
Why interpose instead of observe
A sidecar that watches MCP traffic and reports on it produces a record of the things it failed to stop. Sitting on the wire is what turns a report into a refusal.
Related MCP server: AgentGuard
Install and run
Install once with npm install -g agentomy-mcp-gateway, or run it on demand with npx agentomy-mcp-gateway.
# Instead of launching the MCP server directly:
# my-mcp-server --flag
# launch it through the gateway:
AGENTOMY_ENDPOINT=https://your-agentomy \
AGENTOMY_API_KEY=... \
agentomy-mcp-gateway, my-mcp-server --flagIn an agent's MCP configuration, replace the server's command and args:
{
"mcpServers": {
"dev-tools": {
"command": "agentomy-mcp-gateway",
"args": ["--", "the-original-command", "--its", "--flags"],
"env": { "AGENTOMY_ENDPOINT": "https://your-agentomy", "AGENTOMY_API_KEY": "..." }
}
}
}That is the whole integration. One config change, per agent, by the operator.
Variable | Required | Meaning |
| yes | Platform base URL |
| no | Bearer token |
| no | Identity on the decision, default |
| no | Decision timeout, default |
What it does to the protocol
Message | Behaviour |
| Forwarded unchanged |
| Not forwarded. JSON-RPC error |
| Dropped. A notification must never be answered, so the call is stopped and the reply withheld |
Everything else | Forwarded unchanged |
Upstream to agent | Forwarded verbatim. Results are not rewritten |
Requests are adjudicated in arrival order. Deciding concurrently would let a later call reach the server before an earlier one was resolved, which is a reordering bug that only shows up under load.
Fail-closed, and what that costs you
Every failure path denies:
Condition | Reason returned |
Endpoint unreachable |
|
Decision timed out |
|
Non-2xx response |
|
Body not JSON, or no boolean |
|
Fleet halted |
|
Policy refused |
|
The honest trade: if the platform is down, governed tools stop working. That is the correct behaviour for a governance component and it is a real availability coupling. Run the platform accordingly.
The reasons are distinct on purpose. An operator seeing governance_unreachable has an
outage; one seeing policy_denied has a policy question. Collapsing them into "denied"
would make the two indistinguishable at exactly the moment the difference matters.
A missing authorized field denies rather than being read for truthiness, because a
truthiness check turns any unexpected payload, including an error object, into an allow.
What it does not do
It governs actions, not discovery. tools/list passes through. Narrowing what an agent
may see while leaving what it may do ungoverned would be theatre in the wrong place.
It does not rewrite results. The gateway adjudicates requests; making it edit responses would turn it into a participant in the conversation rather than a gate on it.
It does not inspect arguments semantically. Policy receives the tool name and the argument keys, not the values. Argument-level policy is a platform concern and sending full argument values to a decision endpoint would put file contents and shell commands into a second system.
Licence
Apache-2.0.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
This server cannot be deployed
Maintenance
Related MCP Connectors
Guard wraps stdio MCP servers: risky calls wait for a person; no answer, no run. Remote: cooperative
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
MCP enforcement layer that intercepts AI agent actions and blocks rule violations before execution.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceSits in front of any MCP server to enforce allow/ask/block policies on tool calls, paths, shell commands, and network domains, with local approval prompts and an audit log.MIT
- AlicenseNot gradedqualityCmaintenanceA transparent MCP stdio proxy that sits between an agent client and a real MCP server, intercepting tools/call requests to enforce runtime guardrails derived from the same YAML rules used for CI regression testing. It blocks forbidden, out-of-whitelist, looping, or non-idempotent tool invocations with JSON-RPC errors and writes every decision to an audit log.1MIT
- AlicenseNot gradedqualityBmaintenanceA policy-enforcing sandbox proxy that sits between an agent and an upstream MCP server, letting tool visibility, file paths, hostnames, credentials-looking arguments and timeouts be governed by a single TOML policy file before anything reaches the server. It exposes only the allowed tools, rejects disallowed calls with readable reasons, and writes one audit line per decision without logging argument values.MIT
- AlicenseAqualityBmaintenanceLocal execution gate and stdio MCP proxy for AI agents, with tool policies, expiring leases, approvals and operator kill. Starts with two read-only setup tools; protection requires a trusted downstream server and private operator configuration. Not an OS sandbox. Apache-2.0.2162 PyPI5Apache 2.0