Comparison

When not to use mcpprobe

mcpprobe tests an MCP server you run: whether it enforces the authorization and transport rules, what its tool metadata says, and whether that metadata changed since your last scan. If your problem is one of the ones below, it is the wrong tool, or not enough on its own.

Last checked 3 November 2026 against mcpprobe 0.3.3 and the sources below. Corrections: hello@mcpprobe.tech.

You need to block bad tool calls while agents are running

Why mcpprobe is not it. mcpprobe is a scanner. It looks at a server, writes a report and exits; it never sits between a client and a server, so it cannot stop a call, mask a secret in a response or enforce a policy at runtime. A scan also only shows what the server answered at that moment. A rug pull between two scans is caught on the next scan, not as it happens.

Look at instead. An MCP gateway or proxy in the request path, such as Docker MCP Gateway, agentgateway, IBM ContextForge or Lasso MCP Gateway. Gateways and scanners do different jobs, and many teams will want one of each.

You want to know which MCP servers and skills your developers have installed

Why mcpprobe is not it. mcpprobe scans one target you name: an endpoint URL or a stdio command. It does not read Cursor, VS Code or Claude configs, discover what is installed on a machine, or scan agent skill files.

Look at instead. Snyk Agent Scan discovers agents, MCP servers and skills across many clients and has a background mode for fleets. Ramparts and MCP-Shield also read local configs. See mcpprobe and mcp-scan.

You want to examine a third-party stdio package you do not trust

Why mcpprobe is not it. mcpprobe --stdio starts the command you give it on your own machine, as you, with your environment. That is right for a server you wrote; it is not a sandbox. The check that would watch a stdio server's behaviour (SANDBOX-01) is registered but not implemented, and hosted sandbox runs are not available yet.

Look at instead. Run the package in a disposable container or VM first, or analyse it without running it: Cisco mcp-scanner scans PyPI and npm packages and states that package code is never executed. See mcpprobe and Cisco mcp-scanner.

You need active exploitation testing: injection, path traversal, SSRF

Why mcpprobe is not it. mcpprobe is passive by default and never calls a tool. The active checks for command injection, path traversal, SSRF, SQL injection and supply chain (INJ-01 to INJ-05, SUPPLY-01 and -02) are gated behind ownership verification and are not implemented in the current release: they report not_implemented. A clean mcpprobe report says nothing about whether your tools can be exploited through their arguments.

Look at instead. A penetration test by people who will call your tools with hostile input, or a general scanner you configure for the tool endpoints, such as ZAP or Nuclei with your own templates. Neither knows MCP out of the box, so expect to do the setup.

You want your server's source code reviewed

Why mcpprobe is not it. mcpprobe never reads code. It cannot tell you that a tool's implementation does something its description does not mention, or find a vulnerable dependency.

Look at instead. Static analysis and dependency scanning in your normal pipeline. For MCP specifically, Cisco mcp-scanner has a behavioural source-code analyser and a pip-audit integration, and Ramparts checks OSV.dev for known CVEs in npx and uvx-launched servers.

You want an LLM to judge every description out of the box

Why mcpprobe is not it. mcpprobe makes no LLM calls by default. Its tool-poisoning check (META-01) is rule-based, with an optional hook for a model you supply. Rules miss things a model might catch, such as a description that is misleading without using any suspicious phrasing.

Look at instead. Tools with LLM analysis built in: Cisco mcp-scanner (your model credentials, or Cisco AI Defense), Ramparts, Nova Proximity, or Snyk Agent Scan, which sends descriptions to its own API. Check each one's data-handling terms first.

You need a compliance certificate or an auditor's sign-off

Why mcpprobe is not it. A scan report is evidence, not a certification. mcpprobe does not certify servers as compliant with anything, a passing badge means only that the latest hosted scan, within the last 30 days, found nothing at or above your fail-on severity, and five governance items (GOV-01 to GOV-05) cannot be assessed by a scan at all, so they are never marked passed. mcpprobe itself does not hold SOC 2 or ISO 27001 certification (see trust).

Look at instead. An accredited auditor for the framework you need. mcpprobe's JSON, SARIF and evidence export can be one input to that work.

You need published false-positive rates before you adopt a tool

Why mcpprobe is not it. We have not measured them yet. Per-check rates will be published on the checks page once each check has enough samples. Until then you are relying on the documented false-positive notes for each check.

Look at instead. Ask any vendor for their measured rates and method; few publish them. Independent audits exist for some tools, for example the one cited on the Cisco comparison.

Where it does fit

You run a remote MCP server, or write a stdio one, and want to know before release whether it enforces the MCP authorization spec, validates Origin, handles sessions safely, keeps its tool descriptions clean and has not changed them since the last approved scan, with the request and response behind every finding and SARIF for code scanning. The overview puts that next to the other tools.

Sources

All fetched on 3 November 2026.