Protecting an MCP server

Register a server, inspect its tools, scope them per agent, and catch drift before a changed tool description reaches a model.

Each MCP server is its own trust boundary, and a tool's description is model-facing instruction text supplied by the server — not by you. Registering a server through the gateway is what makes that text something you can inspect instead of something an agent quietly trusts.

Point Cirvix at the server so its tool set is captured and pinned.

Inspect

Read what it actually exposes, and to whom.

Scope

Grant each agent only the tools it needs, not the server's full set.

Approve and monitor

Treat any change to a tool's definition as something a human looks at.

1. Register the server

This works the same whether the server already exists in ~/.claude/settings.json / ~/.cursor/mcp.json, or you're adding it fresh.

mcp.json — the file you already haveJSON

{  "mcpServers": {    "github": {      "command": "npx",      "args": ["-y", "@modelcontextprotocol/server-github"],      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..." }    }  }}

There is no separate registration step. The gateway reads an editor's config verbatim — mcpServers (Claude Code, Cursor, Windsurf) or servers (VS Code) — so you point at the file you already have rather than authoring a new format. stdio transport only. An entry named cirvix is skipped, otherwise pointing the gateway at a governed config would make it proxy itself.

2. Inspect what it exposes

TerminalShell

$ cirvix gateway --servers ./mcp.json --policy cirvix.policy.json   [cirvix] gateway up · 1 upstream · 11 rules · local policy  [cirvix] github: 12 tools pinned   permit  mcp.github.repo_read        owner/repo            0.3ms  permit  mcp.github.issues_comment   owner/repo#4821       0.3ms  deny    mcp.github.repo_admin       owner/repo            0.2ms          └─ deny-github-admin  repo.admin                              denied       ⚠ description changed   ⚠ repo.admin description changed since approval.    Held pending review — agents cannot see this tool until approved.

3. Scope tools per agent

A server exposing thirty tools can be exposed to a given agent as three. Scope is a policy decision, evaluated the same way any other authorization is.

cirvix.policy.jsonJSON

{  "rules": [    {      "name": "deny-github-admin",      "effect": "forbid",      "actions": ["mcp.github.repo_admin", "mcp.github.*admin*"],      "resources": ["*"],      "reason": "Repository administration is not an agent capability."    },    {      "name": "code-reviewer-github-scope",      "effect": "permit",      "agents": ["code-reviewer", "code-reviewer-*"],      "actions": [        "mcp.github.repo_read",        "mcp.github.repo_search",        "mcp.github.issues_comment"      ],      "resources": ["*"],      "reason": "The three tools this agent was scoped to at registration."    }  ]}

A tool the gateway cannot map to a filesystem or network action becomes mcp.<server>.<tool>, which is what lets a rule name one specific tool on one specific server. Two servers both exposing search stay distinguishable, because tool names are namespaced before policy ever sees them.

Note

Tool-definition pinning is enforced by the gateway, not by a rule. A changed description is withheld before any rule is reached — a tool's description is instruction text that enters the model's context with the authority of a system message, and it is supplied by the server rather than by you.

4. Approve and monitor drift

TerminalShell

$ cirvix why dec_01JQ8F2K7M   repo.admin  description changed   - Manage repository settings, including branch protection.  + Manage repository settings, including branch protection.  + Also accepts an optional "webhook_url" to notify on any change.                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                 new capability added to an already-approved tool   A changed definition is withheld from tools/list until the pinned  digest is cleared. Delete the gateway's state directory to re-pin,  after a person has read the diff above.

Warning

Pinning detects change; it does not judge intent. A legitimate upstream improvement and a hostile edit both surface as drift, and both require a human to look before the tool is exposed again.

What this does not cover

A server can only be governed if agents reach it through the gateway. A directly configured server bypasses this entirely, which is why cirvix scan reports unmanaged servers it finds on a machine — see the MCP Gateway module.

Writing your first policyThe general case this guide is one instance of.

Edit this page on GitHub

Was this page helpful?