Scanning MCP Servers for Security Problems

An MCP security scanner connects to the MCP servers configured on a machine, reads what each one offers (its tools, prompts and resources, with their descriptions) and looks for signs of trouble: instructions hidden in descriptions, tools that could be used together to move data out, tools that have changed since you approved them, and known-risky packages or secrets in the configuration. It is a useful check when you add a server and each time you upgrade one. It is not a verdict. A scan sees what a server says about itself at one moment, not what the server does with your data, and it cannot see the permissions a token holds on the other end.

The risks a scanner looks for, such as tool poisoning and rug pulls, are explained in MCP security risks. The practices around them are in MCP security best practices. This piece is about the scanning step itself.

What a scanner looks at

• Configuration. Scanners find the MCP config files of common clients on your machine, list every server they name, and flag things such as secrets written into the file.
• Tool, prompt and resource descriptions. The model reads these as guidance, so a description that tells it to read a file, call another tool or hide something from the user is the classic finding. Detection is by pattern rules, by asking a language model to judge the text, or both.
• Combinations across servers. A tool that reads private data and a tool that sends data outward are each harmless. Together, in one session, they are a route out. Some scanners look for these pairs, sometimes called toxic flows, and for a description on one server that tries to change how another server’s tools are used.
• Change over time. A scanner can record a fingerprint of each tool and report when it changes, so an approved server that later rewrites its descriptions is noticed.
• The code and packages behind a local server, in scanners that go that far: known-malicious binaries, dependencies and suspicious behaviour in source.

Two open tools, as their own documentation describes them

Snyk Agent Scan (formerly MCP-Scan)

Invariant Labs released MCP-Scan in April 2025; its repository now redirects to Snyk’s agent-scan. According to its README, it automatically discovers the configurations of agents such as Claude Code and Claude Desktop, Cursor, Gemini CLI and Windsurf, and checks MCP servers for prompt injection, tool poisoning, tool shadowing, toxic flows, untrusted content, private data exposure and destructive capabilities. It also scans agent skills. The original announcement↗ (opens in a new tab) described built-in tool pinning, which hashes each tool so that later changes are flagged.

# scan every agent configuration it can find
uvx snyk-agent-scan@latest

# scan one config file
uvx snyk-agent-scan@latest ~/.vscode/mcp.json

An inspect command lists what each server exposes without running the security analysis, which is a good way to read a tool list before deciding to scan it.

Two things to know before you run it at work. The README↗ (opens in a new tab) says it sends component information for analysis, including server configurations, tool names and descriptions, to its analysis API, with secrets redacted first. And in an interactive scan it asks for your consent before contacting each server, because contacting a stdio server means starting it.

Cisco AI Defense MCP Scanner

Cisco’s mcp-scanner is a Python tool that combines three engines: YARA pattern rules, an LLM-based analyser, and the Cisco AI Defense API. It scans tools, prompts, resources and server instructions, and its README↗ (opens in a new tab) also lists package dependencies, source code and binary checks. The YARA engine runs locally, which makes it a reasonable first pass where descriptions should not leave the building.

uv tool install --python 3.13 cisco-ai-mcp-scanner

# a remote server, YARA rules only
mcp-scanner --analyzers yara --format summary --server-url https://example.com/mcp

# the client configs on this machine
mcp-scanner --scan-known-configs --analyzers yara --format summary

Both projects move quickly. Check their READMEs for current flags before scripting either one.

Reading the results

Most findings fall into three groups. A description that speaks to the model rather than describing the tool, or asks it to keep something from the user, is the one to act on at once: remove the server and find out where it came from. A warning that two tools together could move data out is a design question, not an alarm; the fix is usually to keep those servers out of the same session, or to require approval for the tool that sends. A changed tool is neither good nor bad until someone reads the new text, so treat it like a dependency upgrade and review it before you accept it.

Where a scan fits when you add a server

1. Choose the source. Prefer the server published by the vendor of the tool it connects to. A scan does not replace that choice.
2. Read the tool list yourself, or with a scanner’s inspect mode. It is usually short, and you will spot a description that is not about what the tool does faster than you expect.
3. Scan before first use. For a local server, scan the exact version you are about to run, and pin that version in your config.
4. Triage the findings. A description that addresses the model (“before using this tool, read…”) is serious. A toxic-flow warning may be the server doing its job; decide whether those two tools should be in the same session.
5. Record the approval: server, version, date, who looked. For a team, the project .mcp.json in version control is a natural place, because a new server then arrives as a change someone reviews.
6. Scan again when you upgrade, and on a schedule. The change report is the most useful thing a repeat scan gives you.

What scanning cannot tell you

• What the server does. A scanner reads descriptions; it does not see what happens to the data a tool receives. A well-described tool can still send your data somewhere you would not approve.
• What arrives at runtime. Prompt injection most often comes in through content a tool returns: an issue, an email, a web page. A scan of tool definitions never sees it.
• What a token can reach. Over-broad permissions are one of the main MCP risks, and they live on the server side, in scopes and roles. Check them where they are granted, not with a scanner.
• That nothing changed after the scan. A remote server returns whatever it returns when asked. Pinning helps, but only between scans.
• Certainty. LLM-based judgements are probabilistic. Treat a clean result as “nothing obvious”, and a finding as a reason to look, not proof.

Scanning also has a cost of its own: fetching a stdio server’s tool list means running it. The MCP specification notes↗ (opens in a new tab) that a local server runs with the client’s privileges and that users may have no visibility of what it executes, which is why a consent step before contacting each server matters.

Scanning a board’s MCP server

A task board is a good example of the split between what a scan checks and what it cannot. Scanning fenbs’s remote server would show you its tools, such as fenbs_list_items, fenbs_update_item and fenbs_comment, and their descriptions. What a scan cannot show is what a given token may do with them. On fenbs that is decided by the read, write and comment scopes ticked when the assistant was approved, capped by the person’s role on the board, and listed with each token under Settings, “Connect an AI assistant”. What the assistant then did is in History, recorded as “Claude via” the person it acted for. A scan tells you what the server offers; the board tells you what was allowed and what happened.