MCP vulnerability scanner tool: what to look for in the new SAST category

Your dependency scanner sees a Node.js package. It does not see that the package opens a stdio MCP server, exposes file-write tools, and reads `~/.aws/credentials`. A new category of scanners is filling that gap — and you should be using one before the year is out.

A traditional SAST tool checks code for known CVE signatures, dangerous patterns, and outdated dependencies. None of that catches the failure modes specific to MCP servers:

An MCP server with a tool that takes free-form shell strings.
A package that ships an MCP server alongside a normal CLI, opting your repo into capability you did not request.
A tool whose inputSchema is permissive enough to allow path traversal.
A server reading ambient secrets (AWS_PROFILE, ~/.config/) without declaring them.
Lock-file drift between an MCP server's manifest and its actual binary behaviour.

Pair this article with MCP server supply chain attacks and detecting malicious MCP servers for the attack patterns these scanners defend against.

What an MCP scanner actually does

A useful MCP scanner combines four checks:

1. Manifest and capability inspection

Parse the MCP server's tools/list, resources/list, and prompts/list outputs. Flag:

Tools with overly broad input schemas (free-form string for shell, SQL, or paths).
Tools that mutate without an explicit destructive: true annotation.
Resources outside the declared root.

2. Static binary / source analysis

Look for known-bad patterns in the server's source or compiled artefact:

child_process.exec / subprocess.run with concatenated user input.
Reading from ~/.aws, ~/.kube, ~/.ssh without explicit declaration.
Network egress to non-allowlisted hosts.
Hardcoded tokens or API keys.

3. Dynamic test harness

Spin the server up in a sandbox and fire adversarial calls:

Path traversal (../../etc/passwd).
Prompt injection in tool output that downstream models would consume.
Resource exhaustion (recursive list, huge result sets).
Malformed JSON-RPC frames.

4. Provenance verification

Check that the binary you got matches the published one:

Sigstore / Cosign signature.
SBOM (Software Bill of Materials) match.
Reproducible build verification where supported.

The scanners worth evaluating in April 2026

The space is young. Three viable categories:

Category	Examples	Best for
OSS, manifest-focused	mcp-audit, server-shield	quick CI checks
Commercial, full-stack	Aikido MCP scan, Snyk MCP add-on	enterprise rollouts
Provenance / signing	Sigstore plus an MCP plugin	supply-chain hardening

Each has gaps. Manifest scanners miss runtime behaviour. Commercial tools are still maturing dynamic harnesses. Sigstore solves only signing, not behaviour. Most teams end up running two: a manifest/static scanner in CI and a runtime guardrail in production.

A minimal CI integration

Even before commercial tooling matures, you can add value with 30 lines of CI:

# .github/workflows/mcp-audit.yml
name: MCP audit
on: [pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Find MCP manifests
        run: |
          jq -r 'select(.mcpServers != null) | .mcpServers | to_entries[] | .key' \
            **/claude_desktop_config.json **/.cursor/mcp.json 2>/dev/null \
            > mcp-servers.txt || true
      - name: Run mcp-audit
        run: |
          while read s; do npx mcp-audit "$s" --fail-on high; done < mcp-servers.txt

A failing audit blocks the PR. The action checks: known-bad packages, missing signatures, manifest red flags.

What to actually fail on

Tuning the failure threshold matters more than picking the scanner. Fail on:

Critical: unsigned binary from untrusted publisher. No exceptions.
Critical: tool with shell-execution capability + unconstrained input. Block until input is constrained or the tool is wrapped.
High: ambient secret access not declared. Block until declared.
Medium: outdated MCP SDK with known issues. Warn, allow override.
Low: no SBOM. Warn.

Do not fail on cosmetic findings (missing description, lowercase tool names). Alert fatigue is its own vulnerability.

Where the category is heading

By Q4 2026 expect:

The MCP spec itself to ship a signatures field, formalising what scanners enforce today via convention.
One or two scanner products to consolidate the OSS + commercial halves.
IDE-level integration (VS Code, Cursor) showing scanner verdicts in the MCP install UI — making it harder to install a flagged server by accident.

Until then, treat MCP servers like third-party Chrome extensions: powerful, useful, and subject to review before they touch your data.

The blind spot in classical SAST