Loading ToolBench
Vulnerability Scanner & Guard for AI Coding Agents | OWASP ASVS 5.0 Security Analysis
VSGuard MCP provides 5 tools with clear security-focused purposes. Tool naming follows verb_noun patterns (list_, check_, scan_, suggest_, map_) which is good. Descriptions are present and reasonably detailed (150-350 chars), exceeding the 10-char minimum. However, input schemas lack critical structure: parameters are defined but many lack explicit type constraints, enums, or validation rules. Error handling is minimal, no recovery guidance or actionable error messages are visible in the code. The server is STDIO-only, which is a hard transport limitation. Tool composition is reasonable (each does one job), but schema documentation for outputs is entirely absent from the visible code. Security-related functionality is clear, but the implementation shows gaps in parameter validation and error classification.
PRIMARY TOOL: Get relevant OWASP ASVS 5.0 security requirements. Search by category (most precise), chapter (broader), or free-text query. Use level filter to reduce results and token usage. Always use the 'list_asvs_categories' tool first to see available categories and chapters.
List all available ASVS 5.0 categories and chapters for search. Use this tool to discover what categories and chapters are available before calling check_security_requirements. Returns: Formatted list of all chapters and their categories with requirement counts
Map a security finding to OWASP ASVS 5.0 requirement IDs. Takes vulnerability type or CWE and returns the relevant ASVS requirements.
Scan code for security vulnerabilities using static analysis. Do not use this tool unless user explicitly asks to scan/audit existing code. Detects SQL injection, XSS, weak cryptography, hardcoded secrets
Get secure code alternatives for a specific vulnerability. Provides: - Secure code example - Explanation of the fix - ASVS requirement references - Security benefits - Additional considerations
Input schemas lack type constraints and enums. Parameters like 'level' accept free-form strings without enum definitions, inviting hallucinated invalid values (e.g., 'level': '4' or 'abc'). The code parses level manually instead of declaring valid values in the schema.
No output schema documentation visible. Tools return formatted strings or undefined structures. LLMs cannot plan downstream tool composition when return types are undocumented. E.g., check_security_requirements returns a formatted string, but what fields/structure should the LLM parse?
Error handling is minimal and not actionable. Code catches exceptions and returns generic error strings ('Error listing categories: {str(e)}'). No guidance for the LLM: is it retryable? Should it try a different tool? No error classification or recovery hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
STDIO transport only. This is a hard blocker for hosted/remote MCP clients. The server cannot be deployed to a cloud infrastructure or accessed via standard HTTP. It only works via local subprocess.
Parameter descriptions mention example values in the text (e.g., 'e.g., "Password Security"' in category param). LLMs tend to reuse example values literally rather than adapting to context. Should use enum constraints instead.
The 'level' parameter in check_security_requirements has complex parsing logic (comma-separated, validation) that should be declarative in the schema via enum or pattern. Validation errors are returned to the LLM but not parsed for actionable recovery.
Tool descriptions mention 'file' location (e.g., 'File: src/server.py') which is internal metadata. This should not appear in user-facing descriptions. Also, descriptions do not explicitly state what the tool RETURNS or when to use it vs similar tools.