What is MCP tool poisoning? (and how to spot a risky MCP server)
MCP tool poisoning is one of the sharpest risks in the new world of AI assistants running local tools. It hides instructions inside a tool’s description — text the model reads and trusts, but that you never see. This is the plain-English explainer of how the attack works and the signals that flag a risky MCP server. It stands on its own; the two practical how-to guides and the honest product note are linked at the end.
What MCP tool poisoning is
An MCP server describes each tool it offers with a short description. That description isn’t just documentation — it is part of what the AI model reads to decide when and how to call the tool. MCP’s design assumes those descriptions are trustworthy. Tool poisoning breaks that assumption: an attacker embeds hidden instructions inside a tool’s description, and because the model is trained to follow tool instructions, it acts on them.
Security researchers at Invariant Labs named this class of attack a “Tool Poisoning Attack” and describe it as a specialised form of indirect prompt injection. The reason it is so hard to notice is a visibility asymmetry: the model receives the complete tool description, while your AI client usually shows you only a simplified label. The malicious text lives where you don’t look but the model does — so a tool that appears to “add two numbers” can carry an instruction to read your keys and exfiltrate them.
In one sentence: tool poisoning is prompt injection delivered through a tool’s description — the model reads and trusts it, you don’t see it, and it runs with your tools, permissions and secrets.
The variants worth knowing
The first four are documented by Invariant Labs. The last two are general supply-chain risk — they amplify the others rather than being tool poisoning in themselves, and we don’t attribute them to that research.
Poisoned tool descriptions (indirect prompt injection)
The core attack. Malicious instructions are embedded inside an MCP tool’s description — the text the AI model reads in full to decide when and how to use a tool. MCP’s design assumes those descriptions are trustworthy, so a “helpful” tool can quietly be told to read your SSH keys or config and send them somewhere. Invariant Labs classes this as a specialised form of indirect prompt injection.
Documented by Invariant LabsThe visibility asymmetry
What makes it work: the model sees the complete tool description, while you typically see only a simplified label in your AI client’s UI. The hidden instructions live in text the interface never shows you — so a tool that looks like a plain “add two numbers” helper can carry a payload you have no easy way to notice by eye.
Documented by Invariant LabsRug pulls — trusted, then swapped
A server can ship a benign tool description, get approved, then change that description to a malicious one afterwards. Invariant Labs calls this a “rug pull”: a server you vetted last week can behave differently this week. It is the concrete reason to pin versions and re-review on every update rather than trusting an auto-pulled “latest” build.
Documented by Invariant LabsTool shadowing across servers
Invariant Labs also documented “tool shadowing”: a malicious server injects a description that changes the agent’s behaviour toward a different, trusted tool or service. One bad server in the set can quietly bend how the model uses the good ones — so vetting each server in isolation is not enough.
Documented by Invariant LabsOver-permissioned / over-scoped tools
Not tool poisoning itself, but the amplifier that makes it dangerous. A tool granted filesystem, shell or broad network access far beyond its stated job turns any injected instruction into a wide-open door. Least privilege shrinks the blast radius of everything else on this list. (General supply-chain risk, not from the Invariant post.)
General supply-chain riskLook-alike / typosquat servers & unofficial registries
A server whose name is a near-copy of a popular one, or one pulled from a random registry or gist rather than an official source, is the classic supply-chain trap — the same way a typosquatted npm or PyPI package is. Prefer official, well-maintained servers and check who publishes them. (General supply-chain risk, not from the Invariant post.)
General supply-chain riskWhy it’s dangerous
A poisoned tool doesn’t need its own privileges — it borrows yours. When the model follows the hidden instruction, it acts with the tools, permissions and secrets already wired into your assistant. That is why Invariant Labs frames the impact as sensitive data exfiltration and unauthorised actions: the model can be steered to read SSH keys, config files or a database and send them out, or to take actions you never asked for — all under your identity, and often without any visible prompt.
The over-permissioned server is the multiplier. A tool scoped to your whole home directory turns one injected instruction into a wide-open door; a tool scoped to a single project folder contains the damage. That is why the two defences that matter most are vetting the source and least privilege — covered step by step in the securing checklist linked below.
How to spot a risky MCP server
No single signal is a verdict — weigh them together. These are the checks a human (and a code-level scanner) can actually run. When you’re ready to act on what you find, the MCP-server security checklist has the full hardening routine, and the discovery guide has the per-OS config-file paths and commands to find every server first.
Unknown or unvetted source
Who publishes it, and how actively is it maintained? An official, well-known server is a very different risk from an unnamed package pulled off a random registry or a gist. Treat an unrecognised source as the first red flag.
Broad permissions vs. its stated job
Compare what the server can reach — filesystem, shell, network, a database — against what it claims to do. A “weather” tool that wants full filesystem and shell access is asking for far more than its job needs. As a rough rule, five-plus scopes is elevated and ten-plus is excessive.
Secrets it has no reason to hold
Look at whether the config hands the server tokens, API keys or passwords — and whether its job actually justifies them. A server holding credentials it doesn’t obviously need is a server worth a much closer look before you trust it with your agent.
Descriptions that change between runs
The rug-pull tell. If a server’s tool descriptions differ from one run to the next, something changed after you approved it. Catching this means reading the raw descriptions the server serves — the job of a code-level MCP scanner, not something you can see from your client’s simplified labels.
Unofficial registries & look-alike names
Prefer the official, canonical server over a near-name copy or an off-registry build. A typosquatted name or an unofficial distribution channel is a supply-chain warning sign in its own right, exactly as it is for npm or PyPI.
Unexpected outbound connections
A server that declares one purpose but connects somewhere else is a red flag. Traffic to the provider APIs an agent legitimately uses (for example api.anthropic.com or api.openai.com) is normal; an unknown destination from a tool that shouldn’t need one is not.
Primary source, for the detail: Invariant Labs — MCP tool poisoning attacks (who named the attack and the rug pull), and Snyk — detecting tool poisoning. Both go deeper on inspecting a single server’s tool descriptions than any fleet tool — including ours.
NetInsightPro helps you spot risky servers — by their signals, not their text
NetInsightPro finds the AI agents and MCP servers running across your fleet and surfaces the structural signals above automatically, on Windows, Linux and Android. AI-agent & MCP security is live on Pro today.
Inventory + provider recognition (Pro)
One deduplicated inventory of every agent and MCP server, with each server classified by provider — so an unrecognised, unofficial source stands out from a known one.
Permission & secret signals (Pro)
The count of permissions/scopes a server declares, and whether its config references secrets — by env key name and count, never their values, which never leave the device. Over-permissioned and secret-holding servers get flagged for review.
Evidence-based risk scoring (Pro)
Each asset scored Low / Medium / High / Critical from unknown provider, permission count and secret exposure — with the evidence shown, not a black-box number. It’s a heuristic to prioritise review, not a vulnerability verdict; vulnerability scanning is included and rolling out.
Config-change flag + egress visibility (Pro)
NetInsightPro flags when a server appears or its config changes between scans — the “something shifted after approval” signal — and surfaces the outbound destinations each app and process connects to, recognising known AI-provider hosts, so an unfamiliar destination stands out. Judging whether a given host is expected for a server stays your call.
The honest ceiling: NetInsightPro does not read tool descriptions
This is the line we won’t blur. NetInsightPro does not read tool-description text or prompt payloads, so it cannot detect a poisoned description by its content. It flags the risk signals around a server — unknown source, excess permissions, declared secrets, config changes, and the outbound destinations a process connects to — not the hidden instructions themselves. And because its change detection works on the local config, a pure rug pull that swaps only the served description (leaving the config untouched) would not trip it. For inspecting description content, a code-level MCP scanner such as Invariant Labs or Snyk goes deeper. NetInsightPro complements those tools; it does not replace them.
See it in context: how discovery works, the securing checklist and AI-agent & MCP security.
What we won’t claim
An explainer you can trust says where its product stops. Here is exactly what NetInsightPro does not do around tool poisoning, so you can decide with clear eyes.
NetInsightPro does not read tool-description text or prompt payloads. It cannot detect a poisoned description by its content — it flags the risk signals around a server, not the hidden instructions. A code-level MCP scanner (Invariant Labs, Snyk) is what inspects the descriptions themselves.
Its change detection is config-level. NetInsightPro flags a server appearing or its command, args, permissions or secrets changing between scans — but a rug pull that swaps only the description the server serves, leaving the local config untouched, would not trip it.
It does not remediate. NetInsightPro discovers, inventories, scores and can block per destination host through the OS firewall — but removing a server, narrowing its scope, pinning a version or rotating a token is you editing a config file. Enterprise automatic blocking is auto-block, not auto-fix.
Blocking is per destination host, not per app process, and there is no macOS blocking; on-device quarantine for purely local stdio servers is rolling out. Risk scoring is an honest heuristic; vulnerability scanning is included and rolling out. NetInsightPro runs alongside your antivirus — no fabricated metrics or logos.
Frequently asked questions
Spot risky MCP servers across your fleet
Start free on up to two devices, or go Pro for cross-platform discovery, inventory and evidence-based risk scoring of every AI agent and MCP server. Runs alongside your antivirus. Data stays on-device.
New to this? Start by discovering the MCP servers on your fleet.