Cisco AI Defense MCP Scanner: scanning MCP servers for malicious tools

The supply chain problem MCP Scanner targets

An MCP server is a process an agent connects to and then trusts. Its tools arrive as name, description and input schema, and the model decides what to call based on that text. Nothing in the protocol requires the description to match what the tool does, and nothing stops a server from shipping a binary asset alongside its code. The README frames the project as scanning "MCP servers and tools for potential security findings", with the stated goal of detecting malicious MCP tools.

The audience is narrower than "anyone using AI". It is the engineer who has to approve a server before it goes into an agent's config, or who owns the pipeline that builds an agent image and needs a gate. The repository ships an examples/example-malicious-servers/ directory, which tells you the maintainers expect you to point the tool at deliberately hostile fixtures rather than only at your own code. If you never install third-party MCP servers, the tool has little to inspect.

Three analyzers, one scan: how findings are produced

The scanner is not a single detector. It combines a YARA engine, an LLM-based analyzer and the Cisco AI Defense inspect API, and the README states these can be used together or independently. A scan targets MCP tools, prompts, resources and server instructions, and the project also covers MCP server source code and bundled binaries.

The engine split matters when you read a report. YARA matches patterns from rules you can extend, so its output is deterministic and offline. The LLM analyzer requires a provider key and a model, and the README lists tested models as OpenAI GPT-4o and GPT-4.1 plus AWS Bedrock Claude 4.5 Sonnet, with LiteLLM pinned at 1.93.0. The Cisco AI Defense analyzer calls a hosted inspect endpoint, so it needs MCP_SCANNER_API_KEY. Two of the three therefore depend on an external service, which changes what you can run in an air-gapped environment.

Separately from those, the tool includes a pip-audit integration for Python dependencies (CVE, PYSEC, GHSA), a VirusTotal hash-lookup path for binary files, and a readiness pass the README describes as zero-dependency static analysis for production issues such as timeouts, retries and error handling. Those are different questions from "is this tool malicious" and should be read as such.

Installing the CLI and running a first scan

The README requires Python 3.11+ and uv, and notes that a Cisco AI Defense key, an LLM provider key and a VirusTotal key are each optional depending on which analyzers you intend to use. The documented CLI install is a uv tool install with an explicit interpreter:

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

After that, the executable is on your PATH. If you would rather build from a checkout, the README gives the source form:

git clone https://github.com/cisco-ai-defense/mcp-scanner
cd mcp-scanner
uv sync --python 3.13

Configuration is environment driven. The repository ships .env.example, which the README says to copy to .env and fill in. The two keys it lists are the Cisco AI Defense key and the endpoint:

MCP_SCANNER_API_KEY="..."
MCP_SCANNER_ENDPOINT="https://us.api.inspect.aidefense.security.cisco.com/api/v1"

If you want the LLM analyzer, the README shows MCP_SCANNER_LLM_API_KEY and an optional MCP_SCANNER_LLM_MODEL, with MCP_SCANNER_LLM_BASE_URL and MCP_SCANNER_LLM_API_VERSION for gateways such as Azure OpenAI. For extended thinking models it documents raising MCP_SCANNER_LLM_TIMEOUT to 300. A point worth noticing: the README does not print a complete end-to-end CLI invocation with a target server argument in the excerpt available here, so treat the examples/cli_end_to_end.sh script as the place to confirm the exact subcommand and flags before you script anything. The same applies to the virustotal subcommand, which the README names but does not fully spell out.

Using it as a library or as a REST server

The module name is mcpscanner, and the README explicitly recommends selective imports over importing everything. The documented entry points are Config and Scanner, with analyzer selection coming from AnalyzerEnum in mcpscanner.core.models:

from mcpscanner import Config, Scanner
from mcpscanner.core.models import AnalyzerEnum

The second mode is a REST API server. The dependency list includes FastAPI and uvicorn, so the server mode is a real deployment shape rather than a wrapper around the CLI, though the README does not document the bind port or the route layout. There is also a static or offline mode that scans pre-generated JSON without connecting to a live server, which the README calls out for CI/CD pipelines and air-gapped environments. That is the mode to look at first if your build agents cannot reach the MCP server itself. The examples/ directory carries api_end_to_end.sh and api_endpoints_end_to_end.py alongside the CLI equivalents, which is the practical way to pin down request shapes.

Where MCP Scanner is the wrong tool

The LLM analyzer is the weakest link in a locked-down environment. It needs a provider key and an outbound call, the model list is short and explicitly labelled as tested, and LiteLLM is pinned to an exact version in pyproject.toml. If your policy forbids sending tool descriptions to a third-party model, you lose that analyzer and with it the semantic judgement about what a tool claims to do. YARA alone will not tell you whether a description is a lie.

The readiness pass is easy to misread. Zero-dependency static analysis for timeouts, retries and error handling is production hygiene, not a security verdict, and the README does not claim otherwise. A clean readiness result says nothing about whether the server is hostile.

There is also a coverage boundary. The scanner inspects MCP surfaces and source code it can parse, and the tree-sitter language packs listed in pyproject.toml cover Python, JavaScript, TypeScript, Go, Java, Kotlin, C#, Ruby, Rust and PHP. A server written in something outside that set, or one whose dangerous behaviour lives in a compiled dependency rather than its own source, falls outside the behavioural path. Finally, the README does not document rollback or remediation workflow: it reports findings, and what you do about a finding is your process, not the tool's.

How it differs from MCP-Scan and Snyk MCP-scan

The obvious comparison is Invariant Labs' MCP-Scan, which people search for alongside this project. The architectural difference is where the verdict comes from. MCP-Scan is generally described as a focused scanner for MCP configurations and tool definitions; Cisco's tool instead routes each scan through a pluggable set of engines, one of which is a hosted Cisco AI Defense inspect API and another of which is a general LLM call via LiteLLM. That means the Cisco scanner can be extended with your own YARA rules and can reuse an existing AI Defense subscription, but it also means two of its three engines stop working without network access and credentials.

Snyk MCP-scan sits in a different category again, since Snyk's centre of gravity is dependency and package vulnerability data. Cisco's scanner does include a pip-audit path for Python dependencies, so there is overlap there, but the primary framing is malicious tool behaviour rather than known CVEs in the dependency tree. If your actual question is "does this server's dependency tree contain a known vulnerable package", a dependency scanner is the more direct instrument. If the question is "does this tool description and source look like an attempt to exfiltrate data", the multi-engine design here is aimed at that.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-08. Releases have been frequent: 4.8.2 on 2026-07-30, 4.8.3 on 2026-08-07 and 4.8.4 on 2026-08-28, with the version in pyproject.toml matching 4.8.4. That cadence is a cost as well as a signal. Anything you build on the Python API imports from mcpscanner.core.models, an internal-looking path, so minor releases are the place to watch for import churn. Pin the version in your pipeline and re-run your own scan fixtures on upgrade rather than assuming report output is stable.

Licensing is Apache-2.0, which is permissive and includes an explicit patent grant. The practical implication is that you can embed the SDK in a commercial pipeline. Two caveats that are not legal advice: the tool calls out to Cisco AI Defense, VirusTotal and your chosen LLM provider, and those services carry their own terms that Apache-2.0 says nothing about; and the YARA rules and any rules you add are your own to manage. The dependency set is large, including FastAPI, LiteLLM, pip-audit and ten tree-sitter language packs, so your own SBOM will grow when you add it.

Editorial conclusion

Adopt it if you are wiring third-party MCP servers into an agent and want findings produced before the server is trusted, especially if you already hold a Cisco AI Defense key or can run the offline JSON path in CI. Do not adopt it expecting an open-ended code auditor: the behavioural analyzer is tied to LiteLLM and a provider key, and the static readiness pass covers production hygiene rather than exploitability. Verify first that Python 3.11.4 or newer and uv are available on the scanning host, that you know which analyzers you can actually authenticate, and that your MCP server can be reached over stdio, SSE or streamable HTTP from that host.

Frequently asked questions

Official sources

1. cisco-ai-defense/mcp-scanner on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases