Loading ToolBench
Code review as an MCP server — structured local security-pattern checks
Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools lack descriptions for the 'language' parameter (review_code, review_file). No output schemas documented. Descriptions are present but generic (avg ~80 chars, below 194-char baseline). No error handling guidance. Tools are read-only and well-named (verb_noun pattern), but parameter completeness and output structure fall short of production standards.
Review source code for bugs, security, performance, and quality issues.
Review a git diff for potential issues before merging.
Review a local file for code quality and security issues.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract structured data from review results. No indication of what fields (issues, severity, line_number, etc.) are returned.
'language' parameter in review_code and review_file lacks description. LLMs cannot determine valid values, format, or whether it is required. Parameter descriptions are mandatory per pattern:tool-description.
No error handling guidance. If review fails (e.g., unsupported language, file not found), LLMs receive no recovery hints. Descriptions do not explain when/why to call each tool or prerequisites.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Tool descriptions are generic and under 100 chars (avg ~80). Baseline is 194 chars. Descriptions lack context on WHEN to use each tool (e.g., review_code vs review_file vs review_diff distinction is unclear).
'language' parameter in review_code and review_file should be an enum (python, typescript, go, rust, etc.) to prevent hallucinated values. Currently free-form string with no constraint.