The Security Edge of MCP: Tool Descriptions and Tool Output Are Both Written by Someone Else

What it kills for you: finding out only after install that a server can read your SSH key

The first thing you can run right now

# (1) See what it actually hands the model (official debugger: Web UI / CLI / TUI)
npx @modelcontextprotocol/inspector

# (2) Scan every server and skill already on the machine
export SNYK_TOKEN=...
uvx snyk-agent-scan@latest

# (3) Shrink the blast radius on the spot: read-only, plus only the toolsets you need
github-mcp-server --read-only --toolsets repos,issues

The point of (1) is not “it connected.” It is reading, one by one, the description text that tools/list returns. That text lands in the model's context verbatim; the server author wrote it, you did not. Step (2) hides a trap worth calling out: plenty of tutorials still teach uvx mcp-scan@latest. That repo, invariantlabs-ai/mcp-scan, is now snyk/agent-scan, the package is snyk-agent-scan, and it wants a SNYK_TOKEN. Check the repo's current state before copying a command — a lesson this series paid for once already last issue.

Mechanism: why a tool description is an attack surface, not documentation

What the spec itself says

The MCP specification (revision 2026-07-28), in server/tools.mdx, gives two sentences that carry most of this issue's theory: “clients MUST consider tool annotations to be untrusted unless they come from trusted servers” and “there SHOULD always be a human in the loop with the ability to deny tool invocations.” Note the reach of the first one — what is untrusted is not only the return value, but also the server's own label saying “this tool of mine is read-only.”

The overview section reduces it to three principles: users must explicitly consent to and understand all data access and operations; hosts must obtain explicit consent before exposing user data to servers; and “Tools represent arbitrary code execution and must be treated with appropriate caution.” Tools equal arbitrary code execution — that is the spec's own wording, not this site's rhetoric.

Real usage and limits: eleven items across three layers

Layer 1 · Vet before you install

• MCP Inspector. Kills: trusting a server on vibes. How: npx @modelcontextprotocol/inspector; Web UI, CLI and TUI, with --format json on the CLI so it fits in CI. When not to: it is a debugger, not a defense — it shows you things, it blocks nothing.
• snyk/agent-scan (formerly invariantlabs-ai/mcp-scan). Kills: reading every description by hand. How: uvx snyk-agent-scan@latest (the 0.5.x line is uvx snyk-agent-scan@0.5.17), with SNYK_TOKEN set. It scans installed servers and skills and flags prompt injection, tool poisoning, tool shadowing, toxic flows, dangerous words in descriptions, plus hardcoded secrets and suspicious download URLs inside skills. When not to: when you are not willing to ship your local inventory off for cloud analysis — that is the price it pays for coverage.
• MCP Registry (per the GitHub repo page, 2026-09: ~7.2k stars). Kills: installing from a blog link with no idea who published the package. How: check namespace ownership — publishing to io.github.<user>/<server> requires authenticating as that GitHub user, and a custom domain has to clear a DNS or HTTP challenge. When not to lean on it: it is still preview (per the repo README, in preview since 2025-09-08, with breaking changes and data resets explicitly possible), and ownership proof is not a code audit.
• mcp-injection-experiments. Kills: treating these attacks as folklore. How: ten minutes reading three scripts — direct-poisoning.py, shadowing.py, whatsapp-takeover.py. When not to: do not run them on your working machine; reading the code is the whole point.

Layer 2 · Fences at runtime

• mcp-context-protector (per the GitHub repo page, 2026-09: ~224 stars, Apache-2.0). Kills: the rug pull — the description you audited today, quietly swapped tomorrow. How: uv sync, then wrap the downstream server with mcp-context-protector.sh --command "<downstream server command>". It does trust-on-first-use pinning of server instructions, tool descriptions and input schemas, then blocks semantic changes until you approve them; it also strips ANSI control characters used for visual deception, and --guardrail-provider LlamaFirewall adds quarantining of suspicious tool responses. When not to: if you only connect first-party servers and your client already has approval gates, this layer buys little.
• docker/mcp-gateway (per the GitHub repo page, 2026-09: ~1.6k stars, MIT). Kills: a pile of npx processes running bare in your home directory. How: docker mcp gateway run (with --profile / --port / --transport); one container per server, secrets through docker mcp secret, and per-profile enable/disable of individual tools. When not to: with one or two local servers, the container and image upkeep costs more than it returns.
• ToolHive (per the GitHub repo page, 2026-09: ~2.2k stars, Apache-2.0). Kills: everyone on the team installing their own set, nobody knowing who connected what. How: container isolation plus permission profiles, encrypted secrets and network egress control, shipped as a desktop app, a CLI and a Kubernetes Operator, with IdP-backed identity and audit logging. When not to: solo on one machine — it solves an organizational problem, and alone you just carry the weight.

Layer 3 · Client-side permissions (cheapest; do this one first)

• Fully-qualified names plus deny rules. MCP itself does not guarantee tool names are unique across servers, which is exactly the soil shadowing grows in. Claude Code's answer is to rename every tool to mcp__<server>__<tool> (characters outside A-Z a-z 0-9 _ - become _; the plugin form is mcp__plugin_<plugin>_<server>__<tool>), and permission rules, hook matchers and a subagent's tools list all address tools by that name. How: "deny": ["mcp__*"] turns off every MCP tool in one line; "deny": ["mcp__database__drop_table"] names a single one.
• Allow globs must be anchored to a server. mcp__github__get_* works, while an unanchored allow such as "*" or "mcp__*" is skipped with a warning. Worth copying as a design idea: an allow must name a concrete server, so a newly connected server cannot slip into your allowlist. Also: settings files skip any mcp__ rule containing parentheses, so parameter-level matching has to go through --disallowedTools.
• --strict-mcp-config and disabledMcpjsonServers. Kills: cloning a repo and silently connecting the servers in its .mcp.json. An interactive session does prompt for approval, but -p, the Agent SDK and cloud sessions load them without prompting. --strict-mcp-config restricts the session to configs you passed explicitly; disabledMcpjsonServers rejects a server by name in every session type. When: every CI and unattended run, unconditionally.
• requiresUserInteraction (self-restraint on the server side). Kills: an irreversible operation waved through by auto mode. How: the server author sets _meta["anthropic/requiresUserInteraction"] to the JSON boolean true on the tool's tools/list entry; that tool then prompts on every call, and acceptEdits, auto and bypassPermissions cannot suppress it, nor can a matching allow rule. Limits: in dontAsk mode it becomes an outright deny, and an allow from --permission-prompt-tool is converted to a deny.
• github/github-mcp-server (per the GitHub repo page, 2026-09: ~32.9k stars, MIT). Kills: handing over write access just to read issues. How: --read-only (or GITHUB_READ_ONLY) — the README states write tools are skipped even if explicitly requested; --toolsets (or GITHUB_TOOLSETS) defaults to context,repos,issues,pull_requests,users, and only all opens everything. When not to: drop --read-only on the day you genuinely want it opening PRs, then put it back.

One more layer that belongs to the protocol, not to tooling

If you write servers rather than only installing them, the MUSTs in basic/authorization/security-considerations.mdx are the bar: a server MUST NOT pass through the token it received from the client to a downstream API; it MUST validate token audience and accept only tokens issued specifically to itself; clients MUST include the resource parameter, MUST implement PKCE, and MUST refuse to proceed when PKCE support cannot be verified; and a proxy server using a static client ID MUST obtain user consent for each dynamically registered client — the clause that exists to kill the confused deputy.

Costs and alternatives: the one to know is “MCP servers do not run in the sandbox”

Three honest costs

• The sandbox governs Bash, not MCP. Claude Code's sandboxing doc says the quiet part out loud when explaining why sandboxed commands may not rewrite config files: a command that could edit .mcp.json or .claude/ could grant itself permissions, or add a hook or MCP server that Claude Code runs outside the sandbox. In other words, those files need protecting precisely because MCP servers are not bound by it. Your isolation boundary is a container or a VM, not /sandbox.
• A scan is only true at the moment you scan. Tool poisoning can be caught statically; a sleeper rug pull cannot, because its first version is clean. Layer one (scanning) and layer two (pinning plus change alerts) are complements, not alternatives. Scanning alone means you were safe on install day.
• Every layer adds friction. A gateway is another hop, pinning means re-approving on every upgrade, requiresUserInteraction prompts every single time. Security measures usually die of annoyance rather than of being bypassed — which is why order matters: do the zero-cost layer-three items first, and only add layer two when an external server arrives.

Three ways to connect nothing at all

• Replace the server with a script. Last issue had the example: the official webapp-testing skill replaces an entire browser server with Python scripts. A script's permissions are fixed by you, not decided by description text.
• Replace a remote server with local read-only. For most servers you use one or two read endpoints; after --read-only and --toolsets, the remaining surface is usually just “the return value contains hostile prose.”
• Replace always-on with just-in-time. Connect it for the hour you need it, then claude mcp remove. Tool tax and attack surface both bill by the minute; this is the most underrated move of the three.