Loading ToolBench
Model context protocol server for offloading ai coding work to Aider
Aider MCP Server has basic tool definitions with schemas present, but suffers from several critical gaps. Both tools have descriptions and input schemas visible in the source code, but descriptions are generic and lack LLM-optimized guidance. Parameter descriptions exist but are sparse. No output schemas are documented. The tool 'aider_ai_code' is high-risk (WRITE) but lacks confirmation/dry-run patterns. 'list_models' is READ_ONLY and straightforward. Overall, definitions are functional but below production quality, they lack the depth, structure, and error guidance needed for reliable LLM orchestration.
Run Aider to perform AI coding tasks based on the provided prompt and files
List available models that match the provided substring
High-risk tool (aider_ai_code) lacks confirmation/dry-run pattern and destructiveHint annotation. WRITE operations should support preview or confirmation before execution to prevent unintended code modifications.
No output schemas documented for either tool. LLMs cannot plan downstream operations or extract required fields without knowing the response structure. aider_ai_code returns {success, diff}; list_models returns {models}, both need formal schema declarations.
Tool descriptions are generic and lack actionable guidance. 'Run Aider to perform AI coding tasks' does not tell an LLM WHEN to use this tool vs. alternatives, WHAT dependencies exist (git repo, working directory), or what files are modified. Descriptions should be 50-200 characters and include prerequisite hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Parameter descriptions are minimal. 'relative_editable_files' says 'LIST of relative paths...' but does not specify: required format (e.g., must be relative to working_dir), whether paths are verified to exist, or what happens if a file is not found. 'model' parameter description suggests 'leave blank', unconventional; should use null default or enum.
No error handling guidance. If aider_ai_code fails (invalid files, git error, API failure), the response structure and recovery steps are not documented. LLM cannot distinguish retryable from fatal errors.
aider_ai_code parameters lack validation constraints. 'relative_editable_files' accepts any strings; no documentation of valid path patterns, max array length, or file existence checks. LLM can pass invalid paths; server must validate and return actionable errors.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing from both tools. aider_ai_code should carry destructiveHint=true; list_models should have readOnlyHint=true. These guide LLM safety reasoning.
Naming: 'aider_ai_code' is acceptable but generic. 'ai_code' suggests LLM-based code generation, but the action verb is muted. Clearer name: 'run_aider_code_generation' or 'generate_code_with_aider'. Current name risks LLM confusion with other code-generation tools.