Cisco AI Defense MCP Scanner: A Three-Engine Scanner for MCP Servers
Scan MCP servers for potential threats & security findings.
At a glance
- What is it?
- The MCP Scanner is a Python CLI and REST server that inspects MCP tools, prompts, resources and server instructions using YARA rules, LLM analysis and Cisco's inspect API. It is useful when you can supply at least one engine's credentials; with none configured, the scanner has nothing to run.
- Who is it for?
- Adopt the MCP Scanner if you already hold a Cisco AI Defense key, an LLM provider key, or both, and you want MCP tool definitions and server source code checked in CI. Do not adopt it if you need a single self-contained offline scanner: the LLM and Cisco engines require network calls and credentials, and the readiness checks are static pattern matching rather than runtime verification.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The supply-chain gap MCP servers open
An MCP server hands an agent a set of tool descriptions, prompts, resources and server instructions. The agent reads those strings and decides what to call. Nothing in the protocol requires the descriptions to be honest. A tool named read_file can be described as a file reader while its implementation posts the contents elsewhere, and the agent has no way to tell. The scanner exists to inspect that surface before an agent is pointed at it. The README frames the goal as detecting malicious MCP tools, and the homepage title refers to securing the AI agent supply chain. The intended user is a security engineer or platform owner who is about to register a third-party MCP server, or who already has a fleet of them and wants a repeatable check. It is not aimed at end users of an agent, and it is not a runtime firewall. It reads definitions and code, produces findings, and stops there.
Three engines, one finding format
The README describes three scanning engines: YARA rules, LLM-based analysis, and the Cisco AI Defense inspect API. They can be used together or independently, and the AnalyzerEnum import in the quick start suggests the analyzer set is selected programmatically as well as on the command line. YARA is the deterministic layer: pattern matching against rules shipped with the tool, plus any custom rules you add. The LLM analyzer sends content to a model for judgement, which the README lists as tested against OpenAI GPT-4o and GPT-4.1 and AWS Bedrock Claude 4.5 Sonnet, while noting that any LiteLLM-supported model can be configured. The Cisco engine calls an inspect API endpoint. Around those three sit narrower analyzers: pip-audit for Python dependency CVEs, VirusTotal SHA256 hash lookups for bundled binaries, and a readiness analyzer described as zero-dependency static analysis for timeouts, retries and error handling. There is also a PyPI package scanner that downloads and scans packages inside a Docker sandbox with behavioural analysis, and a behavioural code scanner for MCP server source. The practical consequence is that findings from different engines arrive in one report, but they are not equivalent evidence. A YARA hit is reproducible from the rule text. An LLM verdict is not, and the README gives no threshold, confidence score or model-version pinning guidance for that engine.
Getting it installed and pointed at a server
The README requires Python 3.11 or newer and uv as the package manager. The CLI install command is uv tool install --python 3.13 cisco-ai-mcp-scanner, with an alternative that installs from git. For library use, uv add cisco-ai-mcp-scanner pulls it in, and the importable module is mcpscanner, with selective imports recommended over importing the whole package. Configuration is entirely environment-variable driven. The Cisco engine needs MCP_SCANNER_API_KEY and MCP_SCANNER_ENDPOINT, with the README showing the US endpoint and pointing to Cisco's developer documentation for other base URLs. The LLM engine needs MCP_SCANNER_LLM_API_KEY plus an optional MCP_SCANNER_LLM_MODEL, MCP_SCANNER_LLM_BASE_URL and MCP_SCANNER_LLM_API_VERSION. For Bedrock, authentication can come from AWS_PROFILE and AWS_REGION instead of an API key. Extended-thinking models get a longer timeout through MCP_SCANNER_LLM_TIMEOUT, shown as 300 seconds. VirusTotal needs its own key, and the analyzer runs either as a virustotal subcommand or as part of --analyzers virustotal. The README's prerequisites mark the Cisco key, the LLM key and the VirusTotal key as optional, which is accurate per engine but easy to misread as meaning the scanner works without any of them.
Static scanning is the part that fits CI
The feature list includes static or offline scanning of pre-generated JSON files without live server connections, described as suitable for CI/CD pipelines and air-gapped environments. That is the most defensible mode for an automated gate. It removes the live server from the trust path, which matters because connecting to an untrusted MCP server to enumerate its tools is itself an action against a system you have not yet assessed. The trade-off is staleness: the JSON you scan is a snapshot, and a server can change its tool definitions between snapshot and use. The README does not describe a signing or pinning mechanism for those JSON files, so the integrity of the snapshot is your problem, not the tool's. The readiness analyzer is likewise static and explicitly zero-dependency, which keeps it usable in constrained environments but limits it to patterns visible in the artefact, not behaviour observed at runtime.
Where the scanner is the wrong tool
Three limits are visible in the material. First, credential dependency: the LLM analyzer and the Cisco analyzer both require external services, so in an air-gapped environment you are left with YARA, readiness checks, pip-audit and VirusTotal hash lookups, and the last of those still needs a VirusTotal key and network access. The README does not present a fully offline mode that includes semantic judgement. Second, the LLM engine is non-deterministic. The same tool description can produce different verdicts across runs or model versions, and the README offers no reproducibility controls beyond specifying the model name. A CI gate that fails intermittently on LLM output will be disabled by the team that owns it. Third, the PyPI package scanner runs downloads inside a Docker sandbox; that is a sensible containment choice, but it means the feature is unavailable wherever Docker is not, and sandbox escape is a category of risk the README does not discuss. If you need runtime interception of tool calls, or policy enforcement on what an agent may invoke, this scanner does not do that. It reads artefacts and reports.
How it differs from a general dependency scanner
pip-audit is the closest familiar tool, and the MCP Scanner embeds it for the dependency portion of the job. The difference is scope. pip-audit answers whether a pinned package version has a known advisory. It has nothing to say about a tool description that instructs an agent to ignore prior instructions, or a server instruction block that redirects the agent's behaviour. The MCP Scanner's YARA and LLM engines exist for exactly that gap. The cost of the wider scope is a wider set of inputs and credentials, and a weaker evidence standard for the LLM portion. A team already running pip-audit in CI would be adding a second, differently-shaped check rather than replacing the first. The two are complementary, and the README's own framing treats dependency scanning as one analyzer among several rather than the centre of the tool.
Maintenance, releases and licence
The repository is active, not archived, with a last push in September 2026 and releases 4.8.2 through 4.8.4 landing between late July and late August 2026. That cadence suggests the project is maintained, though it also means pinning matters: a tool whose detection logic changes monthly will change its findings without any change on your side. Pinning the version in uv tool install and re-reading release notes before upgrading is the practical stance. The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant; it also requires that you preserve notices and state significant changes. That is a summary of the licence identifier, not legal advice, and the repository's LICENSE file is the binding text. One thing to verify: the README badge and the repository metadata both say Apache-2.0, but the README itself does not reproduce the licence header, so confirm the file is present and unmodified before you redistribute anything.
Editorial conclusion
Adopt the MCP Scanner if you already hold a Cisco AI Defense key, an LLM provider key, or both, and you want MCP tool definitions and server source code checked in CI. Do not adopt it if you need a single self-contained offline scanner: the LLM and Cisco engines require network calls and credentials, and the readiness checks are static pattern matching rather than runtime verification. Before rollout, confirm which analyzers your credentials actually enable by running the CLI with an explicit --analyzers list, and verify the licence file in the repository matches the Apache-2.0 badge.
Community notes