MCP server that scans repos and AI tools for prompt injections, exfiltration, and malicious behavior
Three tools with complete schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools have action verbs (scan_*) and clear intent. Descriptions are adequate (100-150 chars) but lack actionable guidance on when to use each tool vs. the others. Parameters lack descriptions for enum values and constraints. No documented output schemas. Error handling returns raw error text without recovery guidance.
Scan an installed AI tool, MCP server, or plugin for malicious behavior, hidden prompt injections, suspicious system prompts, and unsafe configurations.
Run a comprehensive security audit combining repo scanning and AI tool analysis. Produces a unified security report.
Scan an untrusted code repository for prompt injections, malicious instructions, and rule overrides targeting AI coding assistants. Runs static analysis by default; add static_only: true to skip LLM honeypot (no API key needed).
Output schema not documented. Tools return report objects with fields like 'overall_verdict', 'threats', 'confidence', 'recommendation' but LLMs cannot see the structure. Agents cannot plan downstream processing or extract specific fields reliably.
Enum parameter 'tool_type' lacks description of what each value means. LLMs cannot distinguish between 'mcp_server', 'claude_plugin', 'cursor_plugin', 'vscode_extension', 'agent_framework' without explicit guidance on when to use each.
Parameter 'extra_patterns' (scan_repo only) lacks description of glob pattern syntax and valid examples. LLMs will guess at format, likely producing invalid patterns.
Tool descriptions do not clarify when to use scan_repo vs scan_ai_tool vs scan_full. Agents cannot distinguish: is scan_full just scan_repo + scan_ai_tool? When should I call scan_repo alone? Ambiguity forces trial-and-error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Error handling returns raw error text ('Scan error: <error>') without recovery guidance. LLMs cannot determine if error is retryable, user-fixable, or fatal. No actionable next steps provided.