Loading ToolBench
Stdio MCP server that delegates bulk reads and boilerplate generation to the Cursor CLI
Three tools with complete schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. bulk_read and code_write lack descriptions for several parameters (root, model). No output schemas documented for any tool. Error handling present but minimal guidance. Naming is clear (verb_noun pattern), but composition raises concerns: code_write performs both generation AND optional write, violating single-responsibility principle. Tool definitions are explicitly registered in tool_definitions() function with proper JSON Schema structure.
Read authorized files and answer a question via Cursor CLI (read-only).
Generate code from a spec and reference file; optional server-side write.
Cursor CLI path, auth, cache location, and receipt counters.
code_write violates single-responsibility principle: generates code AND optionally writes to disk. Should split into code_write (generation only) and code_save (write to disk).
Missing parameter descriptions: 'root' and 'model' in bulk_read, 'model' in code_write lack explanations of what they control or expected format.
No output schemas documented. LLMs cannot plan downstream calls or extract required fields. bulk_read returns 'model_decision' and 'metrics' but structure is undocumented. code_write returns 'code', 'bytes_written', 'target_path' without type info.
Error handling returns _fail() dict with 'status', 'error', 'error_type', 'error_message' but provides no recovery guidance. LLM cannot determine if error is retryable or what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
bulk_read accepts 'paths' array with minItems=1, maxItems=16 but no description of what happens if paths are outside root or unreadable. Validation exists in code but not documented.