Loading ToolBench
An MCP server that exposes Trivy vulnerability scanning and security analysis capabilities through the Model Context Protocol. Enables scanning of filesystems, container images, and repositories for vulnerabilities, misconfigurations, licenses, and secrets.
The Trivy MCP server has basic tool definitions with action-verb naming and parameter descriptions, but suffers from significant gaps in schema completeness, output documentation, and error handling guidance. Of the 6 tools, all have descriptions (good), but input schemas lack type constraints (enums, min/max), and critically, NO output schemas are documented. Parameter descriptions are present but minimal (20-30 chars, below the 72-char production baseline). The severity filter accepts free-form strings instead of enums, inviting hallucinated values. Tool descriptions are adequate (80-120 chars) but do not explain error recovery or distinguish when to use list_findings vs scan_* tools. No error handling guidance is visible in the definitions, agents calling scan_* on a non-existent path or scan_image on an invalid image reference will receive no recovery hints. The composition is sound (six single-purpose tools), but output fields are not documented, breaking the tool-chaining patterns essential for multi-step workflows (e.g., does scan_filesystem return finding_id values that get_finding expects?).
Retrieve detailed information about a specific finding by ID
List all findings from previous scans stored in memory
Scan a filesystem path for vulnerabilities, misconfigurations, licenses, and secrets using Trivy
Scan a container image for vulnerabilities, misconfigurations, licenses, and secrets using Trivy
Scan a git repository for vulnerabilities, misconfigurations, licenses, and secrets using Trivy
Get the version information of the Trivy scanner and MCP server
No output schemas documented for any tool. LLMs cannot determine what fields to expect or plan downstream tool calls. Critical for tool chaining (e.g., does scan_filesystem return finding_id values that get_finding accepts?).
severity and type parameters accept free-form strings instead of enums. LLMs will hallucinate invalid values like 'SEVERE', 'critical_high', or 'vulnerability' instead of the valid set. Should be enums: severity: [CRITICAL, HIGH, MEDIUM, LOW, UNKNOWN], type: [vuln, misconfig, license, secret].
Parameter descriptions are minimal (18-28 chars, well below 72-char production baseline). E.g., 'Filter by severity level (CRITICAL, HIGH, MEDIUM, LOW, UNKNOWN)', no guidance on default behavior, whether filtering is inclusive/exclusive, or what happens if the parameter is omitted.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling guidance in tool descriptions. Agents calling scan_filesystem on a non-existent path or scan_image on an invalid reference will receive an error but no recovery hints (e.g., 'Call list_findings to see previous scans' or 'Verify the image reference format'). Missing recovery-guide pattern.
Tool descriptions do not distinguish use cases or prerequisites. E.g., scan_filesystem vs scan_repository overlap conceptually, when should an agent choose one over the other? scan_repository description does not state whether it requires a git clone or if it accepts remote URLs directly.
list_findings and get_finding descriptions do not clarify the relationship between them or how finding_id is populated. Do scan_* tools return finding_id? Is the memory-based findings store persistent across server restarts? Undocumented coupling breaks tool chaining.
No indication of result limits or pagination for scan_* tools. If a filesystem scan finds thousands of vulnerabilities, is there pagination? Does scan_filesystem truncate results at a threshold? Production baseline requires explicit limits and pagination guidance.