Loading ToolBench
MCP Server for Codebase Management providing 8 MCP tools that proxy requests to FastAPI backend via HTTP calls for code analysis, search, file operations, git management, sessions, and memory systems.
This MCP server exposes 8 tools for codebase management via HTTP proxy to a FastAPI backend. Tool definitions are present with names, descriptions, and input schemas visible in code. However, critical quality gaps emerge: (1) Tool names lack action verbs (session_tool, search_tool, index_tool, read_tool, write_tool, edit_tool, git_tool, memory_tool are all suffixed with '_tool' rather than verb-first naming like 'start_session', 'search_codebase'); (2) Descriptions are present but often generic or procedural rather than LLM-optimized, they explain WHAT the tool does but lack WHEN to use it and clear WHAT it returns; (3) Output schemas are not documented in the visible code, tool descriptions mention returns but there's no structured schema specification for LLM planning; (4) Error handling exists but lacks recovery guidance, errors return structured data with 'debug_help' fields, which is good, but no categorization of retryable vs. unrecoverable errors; (5) Parameters are mostly documented but lack constraints (enums, ranges, patterns) that would prevent hallucination; (6) No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint) despite clear WRITE vs READ_ONLY risk classifications in metadata. The server averages tool quality around 50-55, which is below the baseline for production readiness.
AI-assisted code editing with comprehensive error reporting and quality validation. Modifies specific sections of code files.
Execute git operations including status, log, diff, add, commit, blame, branching, and tree visualization.
Rebuild semantic search index for codebase with configurable processing and memory options.
Store, search, and manage long-term memory of codebase insights with categorization, importance levels, and context association.
Read code from files with optional filtering by symbol, line range, or occurrence number. Supports reading specific functions, classes, or file sections.
Semantic search across codebase with configurable search type, file patterns, and result limits for finding code blocks and symbols.
Manage development sessions with automatic branch creation and switching. Operations: start (Create a new session branch and switch to it), end (End current session and return to main branch), switch (Switch to an existing session branch), list (List all session branches), merge (Merge a session branch into main), current (Show current session status), delete (Delete the session by specifying the session name).
All tool names use '_tool' suffix without action verbs. Naming convention 'session_tool', 'search_tool', etc. violates pattern:tool principle that LLMs infer intent from tool name. Should be 'start_session', 'search_codebase', 'rebuild_index', etc.
Multi-purpose tools with operation/command parameters (session_tool, git_tool, memory_tool) lack enum constraints on operation strings in schemas. LLMs will hallucinate invalid operation values.
No output schemas documented for any tool. Tool descriptions mention results but don't specify returned field names, types, or structure. LLMs cannot plan downstream tool calls without knowing what fields to extract.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Intelligent write operation with automatic formatting, dependency checking, and quality scoring. Creates new files or overwrites existing ones with validation.
Destructive operations (write_tool, edit_tool, session_tool merge/delete, git_tool commit/add) lack confirmation or dry-run patterns. No protection against agent mistakes.
write_tool has 'save_to_file' parameter defaulting to true. Destructive default on a WRITE operation risks unintended file overwrites when LLM omits the parameter.
search_tool and index_tool lack parameter constraints. max_results unbounded (no range), min_score unbounded (no range 0-1 or 0-100), file_pattern syntax undocumented (glob? regex? wildcard?).
edit_tool has conflicting inputs: 'instructions' (natural language) and 'code_edit' (code). Unclear which is authoritative or how they interact. Violates single responsibility.
No tool annotations visible in code (readOnlyHint, destructiveHint, idempotentHint) despite clear WRITE vs READ_ONLY risk classifications in metadata. LLMs cannot infer operation safety from schema alone.
Error handling returns structured debug_help but does not categorize errors as retryable vs. user-fixable vs. fatal. LLM doesn't know whether to retry, ask user, or give up.