ReferenceReferenceMCP tools

MCP tools

Memnox appears in the Model Context Protocol twice, doing two different jobs.

1. The Memnox MCP server, the agent asks

memnox setup registers it. Restart your client and the agent has two tools:

Tool

memnox_check_rules

Before writing a file, running a command, deploying, adding a dependency

memnox_status

When a call was refused, or the user asks what Memnox is doing

bash
memnox mcp                     # the server itself; the client launches it
memnox mcp install             # add it to another client
memnox mcp uninstall <client>

It never overwrites an existing memnox entry in your MCP config, and everything stays local: no account, no API key, no network call.

What check_rules returns

The same thing memnox context prints: your organization's constraints, quoted verbatim, plus a versioned security baseline for that kind of work.

Neither is generated, and neither is a review of code the agent wrote.

2. The MCP firewall, every other server

bash
MEMNOX_AGENT_TOKEN=mnx_... memnox-mcp-firewall \
  --name github -- npx -y @modelcontextprotocol/server-github

Part

MEMNOX_AGENT_TOKEN

The credential the firewall uses to reach the runtime. A firewall with no credential allows everything, which looks exactly like being protected.

--name <server-name>

What this server is called in rules and audit lines. Defaults to mcp-server; give it a real name once you wrap a second server.

--

Divides the firewall's own flags from the server command. Everything after it is passed through untouched, and it is required.

The firewall proxies any MCP server. Every tools/call goes through the runtime first, and denied tools are hidden from the listing rather than failing when called, an agent cannot be tempted by a tool it never saw.

It is also the only enforcement point where redact is meaningful, because it can rewrite a payload. An editor hook answers allow or deny, so a redact rule blocks there instead of forwarding unmasked.

Why this covers clients nobody has integrated

Windsurf, Zed, Codex and anything else speaking MCP are governed with no per-client work. That is the point of doing it at the protocol layer rather than per editor.

Argument matching stays on your machine

A rule can match the contents of a call:

yaml
    match:
      actions: ["mcp.run_shell"]
      arguments: { command: ["*rm -rf*"] }

That evaluation happens inside the firewall, in-process. The runtime is told the tool, the target, and the rule ids that matched, never the payload.

Configuring it by hand

If your client's config is edited directly rather than through memnox mcp install:

json
{
  "mcpServers": {
    "memnox": {
      "command": "npx",
      "args": ["memnox", "mcp"]
    }
  }
}

For the firewall, wrap the server you were already running:

json
{
  "mcpServers": {
    "github": {
      "command": "memnox-mcp-firewall",
      "args": ["--name", "github", "--", "npx", "-y", "@modelcontextprotocol/server-github"],
      "env": { "MEMNOX_AGENT_TOKEN": "mnx_..." }
    }
  }
}

Troubleshooting

Symptom

Tools not appearing

The client was not restarted

Everything allowed

No credential, a hook with no token allows everything

Tool missing from the listing

Correct: policy denies it, so the firewall hides it

Firewall exits immediately

The wrapped command is wrong, test it without the firewall