Topic: mcp server security tools

MCP server security tools — what's in the landscape (and what's missing)

If you went looking for an "MCP server security tool" you've probably already discovered there isn't one named category yet — there's a generic SAST tool, an SCA tool, MCP Inspector for the dev loop, GitHub code scanning that catches what CodeQL can express, and a small group of MCP-aware scanners. Here's an honest map of which tool covers which part of the threat surface, with corpus data from 101 of the most-installed servers in the wild.

TL;DR

There are five tool categories you'll see in this landscape: SCA (Snyk Open Source, Dependabot, OSV-Scanner, npm audit), generic SAST / code scanning (CodeQL, Semgrep, Snyk Code, Socket, StackHawk), dev-loop tooling (MCP Inspector), MCP-aware scanners (SkillAudit and a small handful of early entrants), and secrets / supply-chain probes (gitleaks, trufflehog, Socket). They do not overlap as much as their marketing suggests. Of the dangerous findings we've seen across 101 of the most-installed Claude skills and MCP servers — 50% with SSRF, 38% with credential-handling findings, 10% with command-exec sinks — almost none are caught by SCA, most are missed by generic SAST, none by Inspector. Below: what each category genuinely covers, where it stops, and how to compose them into a real coverage map.

Why "MCP server security tools" isn't (yet) a single category

Two observations make this market shape itself differently than the equivalent tooling landscapes for Node, Python, or Go services:

The risk lives in first-party tool-handler code, not in dependencies. Most MCP servers are 200–2,000 LOC. Their package.json tree is small and clean. The vulnerable code is the wrapper a developer wrote this week — the SSRF in server.tool('fetch_url', ({url}) => fetch(url)) or the credential echo in return { text: process.env.GITHUB_TOKEN }. SCA tools have nothing to flag because there is no CVE in a dependency tree to flag.
The threat surface is shaped by the protocol, not the language. What "untrusted input" means in MCP is "tool-call argument from an LLM acting on user instructions." That is a different threat shape than "HTTP query string," which is what most SAST corpora and rule sets were trained against. Linters and CodeQL queries that handle web inputs cleanly often pass MCP tool inputs through silently.

The result: each tool category is best at a slice of the surface, and the buyer's job is to assemble the slices into coverage. The next sections go through them.

The five categories — what each one actually catches

1. SCA: Snyk Open Source, Dependabot, OSV-Scanner, npm audit

SCA finds known vulnerabilities (CVEs / GHSA advisories) in the dependencies your package.json / requirements.txt / go.mod resolves. You should run one. It is separate, mature, and orthogonal to the MCP-shaped threat surface. What it doesn't catch: any first-party code, any tool-handler-shaped finding, anything without a CVE assigned. In our corpus, fewer than 5% of F-grade findings were CVE-shaped — meaning if you only ran SCA, you would green-light most of the F-grade vendor releases. We cover the side-by-side in Snyk alternative, Dependabot alternative, OSV-Scanner alternative, and npm audit alternative.

2. Generic SAST / code scanning: CodeQL (GitHub Code Scanning), Semgrep, Snyk Code, Socket, StackHawk

SAST detects taint flows in first-party code. The sophisticated ones (CodeQL especially) can follow tool-handler arguments to an HTTP sink and flag SSRF — if the rule set knows about MCP. The default rule sets do not. We compared CodeQL's default queries against our corpus and saw it surface roughly 1 in 5 of the SSRF findings SkillAudit catches; the rest are dynamic-base patterns (fetch(`${baseUrl}/${path}`)) and template-string idioms that the default queries don't model. Semgrep is closer when you write MCP-shaped rules yourself. Socket is best on dependency-tree freshness (overlaps SCA more than code scanning). Detail: GitHub code scanning alternative, Socket alternative, StackHawk alternative.

3. Dev-loop tooling: MCP Inspector

Inspector is the official Anthropic-maintained dev-loop tool. You point it at your MCP server, see the tools the server registers, fire requests at them, watch the responses, debug the protocol traffic. It is excellent at what it does. It is not a security tool. Inspector won't grade your code, won't flag SSRF in a tool handler, won't catch credential echoes — that is not its job. It is the MCP equivalent of curl + jq, not the MCP equivalent of Snyk. We have a side-by-side for buyers who arrive on this page expecting it to be a scanner.

4. MCP-aware scanners

This is the new category. SkillAudit is the most-developed of these in 2026; a handful of others are in earlier stages. The defining characteristic: the rule set, the taint model, and the report shape are tuned to the Model Context Protocol — registered-tool extraction, dynamic-baseURL handling, env-var read-tracing into tool responses, prompt-injection probing as a separate axis, A–F grading instead of finding-list dumps. SkillAudit's scanner specifically covers the six-axis surface we have evolved against the corpus: SSRF, command-exec, credential exposure, prompt-injection (LLM-assisted), permission scope, maintenance, client compatibility, and documentation completeness. Output is a buyer-readable A–F card plus per-axis findings with file paths and line numbers, embeddable as a public badge.

5. Secrets / supply-chain probes

Tools like gitleaks, trufflehog, and Socket's supply-chain analysis catch hardcoded secrets in commits and suspicious package metadata. They are useful adjacent layers but they don't grade the MCP server's behavior — a server that reads process.env.GITHUB_TOKEN and echoes it back through a tool response has no hardcoded secret and a clean dependency tree, but it will leak the token to whoever invokes the tool. The credential-echo class (38% of our corpus) is invisible to this layer.

What each tool covers: a buyer's coverage table

Finding class	SCA	SAST default	SAST custom	Inspector	MCP scanner
CVE in dependency	Yes	No	No	No	Maintenance axis
SSRF in tool handler (static URL)	No	Sometimes	Yes	No	Yes
SSRF dynamic base / template	No	Rarely	Yes (with effort)	No	Yes
Command exec from tool input	No	Sometimes	Yes	No	Yes
Credential echo to tool response	No	No	Hard	No	Yes
Prompt-injection vector (tool I/O)	No	No	No	No	LLM-probe axis
Over-broad permission scope	No	No	No	No	Yes
Archived / unmaintained	No	No	No	No	Maintenance axis
Client compatibility drift	No	No	No	Partial	Yes
Hardcoded secrets in repo	No	Sometimes	Yes	No	Adjacent

"Sometimes" reflects rule-set defaults; "with effort" reflects tools whose customization layer can express the rule but where the default install will not. Sources: SkillAudit's CodeQL/Semgrep comparison runs against the 101-server corpus, plus per-tool documentation review.

What we'd run as a buyer in 2026

SCA — Dependabot or OSV-Scanner. Cheap, automatic, catches the dependency-CVE class.
One MCP-aware scanner — covers the first-party tool-handler classes that nothing else does. SkillAudit is what we built; our methodology page lays out exactly what we cover and what we don't, so the choice is auditable.
A secrets probe in pre-commit — gitleaks or trufflehog. Cheap, prevents the most embarrassing class of accident.
CodeQL or Semgrep if you have a security team that will write and maintain MCP-shaped rules — otherwise the default install adds little here.
Inspector in your dev loop, as a development tool, not as a gate.

For team buyers, the install-time gate is the highest-leverage piece — wire the MCP-aware scanner into a GitHub Action that fails PRs below grade B and the rest of the stack works behind it.

Run an audit

What we wish existed (and don't)

A standardized prompt-injection benchmark for MCP servers. Each LLM-assisted probe is a different methodology today; cross-tool comparability is poor. We publish our calibration set as a step toward this.
A protocol-version compatibility matrix for the major clients. Claude Code, Cursor, Windsurf, Codex, JetBrains, the VS Code extension — the MCP protocol drifts and breaks installs quietly. Tooling for this exists in fragments inside each client's CI; nothing public covers all of them.
A first-party Anthropic security review. The Skills Directory listing process now requires a security review, but the criteria aren't public, and there is no third-party way to pre-flight a submission. Until that exists, an open-methodology MCP scanner is the closest substitute — which is partly why we built one.