Loading ToolBench
MCP server providing system design review and code review via OpenRouter with optional Serena context.
The server defines 2 tools with complete input schemas and reasonable descriptions. Both tools follow verb_noun naming (system_design_review, code_review) and have descriptions in the 100-150 char range, within acceptable bounds. However, parameter descriptions are verbose and somewhat redundant across tools. Output schemas are not documented in the visible source. Error handling patterns are not evident in the tool definitions. The schemas are well-structured with proper JSON Schema types (string, list, null unions), but descriptions could be more concise and LLM-optimized.
Review code files for bugs, style issues, performance problems, and best practices. Optionally use Serena to search memory and codebase for context.
Review a system design or existing implementation files for architectural issues, scalability, performance, and best practices. Optionally use Serena to search memory and codebase for context.
Output schemas are not documented. The tool definitions show input schemas but no description of what is returned (structure, fields, error format). LLMs cannot plan downstream actions without knowing the output structure.
Parameter descriptions are excessively verbose (300+ chars for some params) and repeat similar guidance (e.g., 'Paths are relative to the current working directory; absolute paths also work' appears in both tools identically). This wastes tokens and dilutes signal. Descriptions should be 50-100 chars, with constraints (length, format, enum) stated formally in schema, not prose.
No error handling guidance in tool definitions. What happens if a file cannot be read? If the model override is invalid? If constraints/context exceed size limits? Tool descriptions must include recovery hints so LLMs can self-correct.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Parameter 'model' is exposed as a free-form override string (e.g., 'openai/gpt-4'). This violates secret injection and configuration management patterns, model selection should be configured server-side via environment or config, not exposed as a tool parameter. LLM contexts log all parameters.
Mutual exclusivity between 'proposal'/'code' and 'paths' is documented in descriptions but not enforced in schema. Schema should use oneOf or conditional logic, not prose. LLMs frequently ignore prose constraints.