If you run an AI agent through MCP (Claude Code, Cursor, or any MCP client), your tool calls now flow through MCP servers: a filesystem server, a database server, a shell. That standardization is great. It also means a single hallucinated or prompt-injected tool call can do real, irreversible damage, and the model does not know a destructive call from a safe one until it is already making it.
So people ask: is this MCP server safe?
Here is the better question. Your agent will, eventually, send an MCP server something destructive. The question is not only whether you block it. It is whether the run survives the block.
Wrap any MCP server with agentx-mcp
. It is a small stdio proxy: it spawns the real server, relays the MCP protocol untouched, and screens every tools/call
before it runs. One line in your mcp.json
:
{
"mcpServers": {
"database": {
"command": "agentx-mcp",
"args": ["npx", "-y", "your-real-mcp-server", "..."]
}
}
}
pip install agentx-security-sdk # this ships the agentx-mcp command
Now every tool call the agent makes is checked by a deterministic floor first. A DROP TABLE
, an unscoped DELETE
, a secret-store read, an SSRF to 169.254.169.254
, an rm -rf
: all blocked before they reach the server. No API key, nothing leaves your machine, no LLM in the hot path for the block. It works with any MCP-speaking stack, because it screens the protocol, not your code.
That is the part you can verify in two minutes without trusting me.
Most "is it safe" answers stop here: the dangerous call is blocked, the tool returns an error, and your agent gives up. A hard 403 in the middle of an autonomous run is its own kind of failure. The task does not get done. You just traded one broken outcome for another.
When the shield blocks a tools/call
, agentx-mcp
does not return a dead error. It returns a coaching tool error that names what was unsafe and points at a safe path. Your agent reads it on its next turn, revises, and tries a safe version. The run keeps going.
Here is the loop, end to end, on a real MCP server:
SELECT name FROM users; DROP TABLE users;
agentx-mcp
blocks it at the proxy. The call never reaches the database. The agent gets back a coaching error: blocked, mass destructive intent, revise to a safe read.SELECT COUNT(*) FROM users
.The catch is table stakes. The recovery is the point: your agent finishes the job instead of dying on the block.
This recovery is keyless and in-band. The agent doing the self-correcting is your agent, your MCP client's own model, reading the coaching. There is no extra key and no gateway in this loop. (A richer, gateway-coached version is on the roadmap, but the keyless coaching above is what ships today.)
The floor is deterministic, so the block is a rule, not a vibe:
DROP TABLE
, TRUNCATE
, unscoped DELETE
169.254.169.254
)rm -rf
, curl | sh
, path traversalNo model inference for the floor, which is why it runs with no key and adds negligible latency. It is the blatant-catastrophic floor on purpose: the things you never want an agent to do, blocked deterministically, every time.
I am looking for people running MCP servers against something real (a database, a filesystem, cloud, internal APIs) to wrap one and tell me two things:
What dangerous tool call did it miss? Try to stump it.
Watch the catch-and-recover live, and try it: https://bit.ly/agentfirewall
Tell me what broke or what it missed: https://discord.gg/PmWRTtaSx2
If your agent never touches anything irreversible, move along. If it does, wrapping one MCP server is one line, and DROP TABLE
is a bad way to learn this the hard way.