MCP tool-poisoning risks and review controls

Review the full tool contract, not only the display name

Inspect tool descriptions for prompt injection, cross-server tool references, and hidden Unicode before approval. The current Snyk Agent Scan issue reference labels prompt injection in a tool description as E001, cross-server tool references as E002, and hidden Unicode as W021. Those categories identify material for human review; they do not make every flagged tool malicious.

Record the server identity and the exact discovered name, description, schemas, and annotations. Compare that baseline after an update or a tool-list change notification. Oxvault's current project documentation demonstrates a pin-and-check workflow for changed descriptions or schemas, but its rule counts, test results, and performance statements are project-maintainer claims rather than independent validation.

Definition

Name, description, schemas, and annotationsReview the exact bytes the client will expose to the model, including invisible characters.

Provenance

Server origin, version, command, URL, and publisherA trusted-looking tool name does not establish who supplied the current implementation.

Drift

Any unexplained contract changeQuarantine the changed tool until a person reviews and approves the new baseline.

Use scanners as evidence collection, not certification

A scanner can inventory configured servers, retrieve current definitions, and highlight patterns for a reviewer. It cannot turn an untrusted server into a trusted one. Snyk's Agent Scan documentation says the scanner starts commands found in stdio MCP configurations so it can retrieve tool descriptions. It prompts before each server in an interactive scan and recommends a container, virtual machine, or disposable environment for untrusted configurations. This matters because scanning can cross the execution boundary before the report exists.

Preserve the scanner version, ruleset or issue codes, target configuration, timestamp, and raw findings. Snyk also labels its CLI output and issue-code surface experimental, so automation should not assume those fields remain stable without version-specific tests. A clean report means only that the selected scanner produced no finding in that run. Pair it with source review, dependency and install-script review, a definition diff, least privilege, runtime approvals, and server-side access controls.

Safe setup

Scan unknown stdio configurations in isolationReview the exact command and arguments before allowing the scanner to start a server.

Reproducibility

Keep tool definitions and scan provenanceA screenshot or pass/fail label alone cannot show what bytes or rules were evaluated.

Decision

Human review remains requiredTreat findings as triage signals and a clean scan as limited evidence, not an assurance.

Separate three poisoning paths

Definition poisoning places prompt injection in a tool description, including text concealed with hidden Unicode. A change-after-approval variant alters a previously accepted description or schema; Oxvault's documentation demonstrates pinning and comparing those fields as a rug-pull check. Response poisoning waits until tools/call and returns useful-looking content mixed with instructions. These paths require review at discovery, after definition changes, and at runtime.

OWASP's third-party MCP guidance treats tool poisoning alongside prompt injection, memory poisoning, and tool interference, and recommends controls spanning secure discovery, sandboxing, least privilege, governance, and human oversight. The MCP tools specification adds concrete client duties: show exposed tools and inputs, keep a person able to deny calls, validate results before passing them to the model, and require confirmation for sensitive operations. These layers reduce blast radius even when content inspection misses a novel instruction.

At discovery

Poisoned definitionInspect descriptions, hidden Unicode, and cross-server tool references before model exposure.

After approval

Definition drift or rug pullDiff the complete contract after reconnects and updates; reapproval is a new decision.

At runtime

Poisoned tool resultValidate structured output and keep privileged actions behind non-model enforcement and confirmation.

Apply client controls before and during every sensitive call

Client controls differ, so verify the behavior of the client and mode you actually deploy. Cursor's current MCP documentation says tool calls require approval by default and lets a user expand the proposed call to inspect arguments. It also documents enterprise server and tool allowlists plus network modes for local servers. Cursor's permissions reference warns that its MCP allowlists and Auto-review instructions are convenience controls, not a security guarantee; broad wildcard entries can remove useful review friction.

Claude Code's current documentation keeps project-scoped .mcp.json servers pending until interactive approval and workspace trust, and says a cloned repository cannot approve its own server from tracked project settings in an untrusted folder. Organization controls can force a connector tool to ask on every call or block it before the model sees it. These controls help only when administrators avoid blanket approval and users can see the arguments and consequence of the operation.

For a high-impact tool, combine an approved-server list, a narrow per-tool allowlist, least-privilege credentials, visible arguments, and confirmation outside model-controlled text. Enforce file, network, database, and spending restrictions in the execution layer. OWASP explicitly recommends isolating privileged tools, enforcing restrictions server-side, allowlisting servers, constraining response formats where possible, and requiring explicit confirmation for destructive or exfiltration-sensitive operations.

Before connection

Approve the origin and exact configurationDo not let a repository, package, or server self-approve through its own metadata.

Before invocation

Show the selected tool and full argumentsSensitive reads, writes, network sends, and spend need a meaningful human decision.

During execution

Enforce limits outside the modelA poisoned instruction must not be able to override filesystem, network, scope, or policy checks.

Continue the security review

Next, use the broader security checklist for authentication, scopes, secrets, transport, logging, and revocation. Keep token passthrough as a separate review question rather than treating metadata inspection as the complete MCP security review.

Evidence boundary and remaining gaps

This page is a control guide, not a certification of any MCP server, client, or scanner. The cited scanner behavior comes from Snyk and Oxvault maintainer documentation. This research pass did not execute either scanner, reproduce an exploit, compare detection rates, validate maintainer rule counts, or independently measure false positives and false negatives.

The refreshed last30days run returned 57 items with degraded coverage: Reddit was partial after HTTP 429, arXiv was rate-limited with zero retained papers, X was not configured, and Polymarket reported no markets. Zero retrieved community items were classified relevant for tool-poisoning review controls, so no community claim is retained. Incomplete source coverage also prevents an absence claim. The page therefore makes no claim about adoption, prevalence, scanner effectiveness, customer outcomes, or whether discussion was quiet on sources that were not successfully covered.