Loading ToolBench
Docker security scanning with Copacetic patching. Single-file implementation: Trivy scanning + Copa patching + vulnerability analysis.
The server defines a single tool 'scan_dockerfiles_security' with a descriptive docstring and a schema. However, the tool name violates verb_noun conventions (scan_dockerfiles_security uses scan_noun_noun format which is ambiguous about what 'security' scans), the parameter descriptions lack depth and constraints, the output schema is completely undocumented (returns Dict[str, Any] with no structure), and there is no error guidance or recovery paths. The tool performs a write operation (updates Dockerfiles, applies patches, builds Docker images) but lacks idempotence guarantees and confirmation patterns. The schema structure is present in function signature but lacks formal JSON Schema documentation visible to LLMs. This server would require significant refinement before production use.
Docker security scanner with optional Copacetic patching. Args: repo_path: Repository path to scan severity_filter: Optional severity filter (e.g., ["CRITICAL", "HIGH"]) apply_patches: Whether to apply Copa patches (default: false) update_dockerfile: Whether to update the original Dockerfile with fixes (default: false) Returns: Scan results with vulnerability analysis and optional patching results
Tool name lacks clarity: 'scan_dockerfiles_security' does not follow verb_noun pattern and is ambiguous about what is being scanned (vulnerabilities? configuration? both?). LLMs may confuse this with generic security scanning vs Docker-specific vulnerability scanning.
Output schema completely undocumented. Function returns Dict[str, Any] with no declared structure. LLMs cannot predict what fields to expect (e.g., will patching_results always be present? what are the types within scan_results array?). This violates the documented-output-schema requirement.
No error guidance or recovery paths. The tool returns errors as plain dicts with 'error' keys (e.g., 'Cannot access repository: ...', 'Build/scan failed: ...') but provides no actionable next steps. An LLM receiving 'Build/scan failed' cannot determine if it should retry, ask the user, or try a different approach.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Destructive operation without confirmation pattern. Tool accepts update_dockerfile=true which modifies user files irreversibly, yet provides no dry-run option or confirmation step. An agent could corrupt Dockerfiles without intervention.
Parameter 'severity_filter' description lacks constraints and format guidance. Users/LLMs cannot infer valid enum values (CRITICAL, HIGH, MEDIUM, LOW?) or whether the array is AND/OR logic. Current description is 'Optional severity filter (e.g., ["CRITICAL", "HIGH"])', example values do not constitute a formal constraint.
No pagination or result limiting documented. Tool recursively scans all Dockerfiles in a repo and returns all results without size bounds. If a repo has 1000 Dockerfiles and each scan returns detailed Trivy output, results could be enormous, exhausting LLM context.
No idempotence guarantees or side-effect documentation. Calling the tool with apply_patches=true triggers Docker builds and Copa patch operations, which may partially succeed (e.g., patch applied but re-scan fails). Retry behavior is undefined, could a second call apply patches twice?
Parameter descriptions are minimal (1-2 lines). 'repo_path: Repository path to scan' does not specify format (absolute path? relative? URL?), validation rules (must exist? must be readable?), or typical values. Description should be 10-1024 chars; these are ~10-40.
No output field documentation. Tool docstring says 'Returns: Scan results with vulnerability analysis and optional patching results' but does not describe the structure. What keys are in the response? Are vulnerabilities an array? What fields does each vulnerability object contain?