Loading ToolBench
Security auditor for Claude Code skills, hooks, and MCP servers providing security scanning capabilities via MCP protocol
cc-audit MCP server has basic tool definitions with some schemas visible, but significant gaps in descriptions, parameter documentation, and output schema clarity. All 5 tools are READ_ONLY and well-scoped (no composition issues), but descriptions are generic and parameter descriptions are minimal or missing. No evidence of output schema documentation. Error handling not visible in source excerpt. Tool names follow verb_noun pattern adequately but descriptions lack depth needed for LLM selection.
Check if content matches a specific rule
Get a fix suggestion for a finding
List all available security rules
Scan a file or directory for security issues
Scan content string for security issues
Tool descriptions are too generic and lack context for LLM selection. Examples: 'Scan a file or directory for security issues' (48 chars) does not explain WHEN to use this vs scan_content, what findings are returned, or what rule categories are checked.
Parameter descriptions are minimal or absent. 'path' parameter in scan tool has description 'Path to scan (file or directory)' but lacks context: does it accept both? Are symlinks followed? What file size limits exist? Same issue in scan_content where 'filename' lacks description of its purpose (used for rule context? error reporting?).
Output schemas are not documented in visible source. Callers cannot know what fields to expect from scan results (e.g., does it return findings as array? Does each finding have rule_id, severity, code_snippet, line_number, fix_suggestion?). This forces LLMs to guess or re-call tools to extract needed data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
list_rules accepts optional 'category' parameter but no enum or valid values are documented. LLMs cannot know valid categories (security, docker, kubernetes, etc.). Parameter description should either list valid categories or reference a discovery tool.
Error handling strategy is not visible in source excerpt. No evidence of recovery guidance (pattern:recovery-guide), error classification, or actionable error messages. E.g., if scan() fails on a permission-denied path, does it guide the LLM to retry with a different path or skip that file?
check_rule and get_fix_suggestion reference 'rule_id' and 'finding_id' but do not explain how to obtain valid IDs. LLMs must first call list_rules() to discover IDs, then call check_rule or get_fix_suggestion, a multi-step pattern not documented. Should include discovery hints in parameter descriptions.