MCPSafe.io
RegistryThreatsMethodologyDocsPricingScanSign in
⌘K
  • Getting Started
  • Quickstart

API Reference

  • Overview
  • POST /scan
  • GET /scan/:id
  • Private scans
  • Team & billing

Integrations

  • GitHub Actions
  • Cursor
  • Claude Code

Concepts

  • AIVSS Scoring
  • Findings
  • Severity Levels
  • CLI
  • Troubleshooting
  • FAQ
⌘K
MCPSafe.io

Security checks for MCP servers — public packages and private repos, fast or deep.

Legal

Privacy PolicyCookie PolicyTerms of ServiceSecurity disclosure

Resources

State of MCP SecuritySupportSystem statusMade in Germany 🇩🇪

© 2026 MCPSafe. All rights reserved.

GDPR — Privacy Policy

Findings

What a finding is, what it contains, and the categories MCPSafe detects.

A finding is a discrete security issue detected in an MCP server. Each finding is produced by a specific rule and points at a single location in a tool or file.

Finding object

{
  "finding_id": "f_001",
  "mcp_threat_id": "MCP-205",
  "category": "injection",
  "severity": "high",
  "aivss_score": 7.4,
  "tool_name": "execute_command",
  "file_path": "src/tools/execute.ts",
  "line_number": 42,
  "description": "User input flows into an inner-LLM SYSTEM message",
  "remediation": "Wrap untrusted input with <untrusted>...</untrusted> or pass through escape_for_prompt()",
  "evidence_snippet": "messages: [{ role: 'system', content: `Use this context: ${userInput}` }]"
}
FieldDescription
finding_idStable identifier within this scan
mcp_threat_idThe rule that produced the finding (e.g. MCP-205); cross-references /threats/coverage
categorySignal category (see below)
severitycritical / high / medium / low
aivss_score0–10 score for this specific finding
tool_nameThe MCP tool where the issue was found
file_pathSource file path (relative to package root)
line_numberLine number of the offending code
descriptionHuman-readable explanation of the issue
remediationRecommended fix
evidence_snippetCode or text that triggered the finding

Finding categories

Categories are signal buckets, not individual rules. Multiple rules can map to the same category — see /threats/coverage for the active rule set per category.

CategoryWhat it covers
injectionPrompt injection into inner LLMs, command/SQL injection through tool input
secretsRuntime secret exfiltration to logs/responses, plaintext secrets in .env
permissionsIAM wildcards, OAuth over-scoping, unused-scope detection
supply_chainTyposquats, install-time remote-exec hooks, container running as root, known CVEs
destructiveMutating tool handlers without elicit() / dry_run / confirmation
cveNVD / GHSA matches against the resolved version
typosquatLook-alike package names targeting popular packages
server_configurationOAuth/PKCE/redirect-URI hygiene, host validation, CORS, session-binding, MCP-spec compliance

How findings are generated

  • Fast scans run pattern, manifest, and supply-chain checks across the full catalog.
  • Deep scans add taint and AI-assisted semantic checks plus an LLM judge panel that votes on each tool handler. The judge panel is a second opinion — it adjusts the score, but rule findings drive the verdict.

New rules go through a precision review before they affect any user-visible result.

Filtering findings

On the scan result page, use the severity and category filters to narrow the findings list. You can also filter programmatically via the API response:

const critical = result.findings.filter(f => f.severity === "critical");
const injections = result.findings.filter(f => f.category === "injection");
const fromRule  = result.findings.filter(f => f.mcp_threat_id === "MCP-205");
←PreviousAIVSS ScoringNextSeverity Levels→