Loading ToolBench
Model Context Protocol integration for Claude Context - provides semantic code search and indexing capabilities for codebases
This MCP server has 4 tools with complete input schemas and descriptions, but several quality gaps limit its score. Tool names follow verb_noun convention and are clear (index_codebase, search_code, clear_index, get_indexing_status). Descriptions are detailed and include usage guidance with warnings. However, the descriptions are verbose (300-500+ chars for some tools), exceeding best practice (10-1024 chars target, 194 char average baseline). Parameters all have type definitions and descriptions, which is strong. Output schemas are NOT documented, a critical gap. Parameter descriptions mention behaviors (e.g., 'Force re-indexing... you MUST prompt the user to confirm') that suggest stateful expectations, but this is a STDIO-only server with no persistent session context. Error handling is not visible in schemas. Overall, the definitions are above-average in completeness but lack output schema documentation and have some verbosity issues.
Clear the search index. IMPORTANT: You MUST provide an absolute path.
Get the current indexing status of a codebase. Shows progress percentage for actively indexing codebases and completion status for indexed codebases.
Index a codebase directory to enable semantic search using a configurable code splitter. ⚠️ **IMPORTANT**: - You MUST provide an absolute path to the target codebase. ✨ **Usage Guidance**: - This tool is typically used when search fails due to an unindexed codebase. - If indexing is attempted on an already indexed path, and a conflict is detected, you MUST prompt the user to confirm whether to proceed with a force index (i.e., re-indexing and overwriting the previous index).
Search the indexed codebase using natural language queries within a specified absolute path. ⚠️ **IMPORTANT**: - You MUST provide an absolute path. 🎯 **When to Use**: This tool is versatile and can be used before completing various tasks to retrieve relevant context: - **Code search**: Find specific functions, classes, or implementations - **Context-aware assistance**: Gather relevant code context before making changes - **Issue identification**: Locate problematic code sections or bugs - **Code review**: Understand existing implementations and patterns - **Refactoring**: Find all related code pieces that need to be updated - **Feature development**: Understand existing architecture and similar implementations - **Duplicate detection**: Identify redundant or duplicated code patterns across the codebase ✨ **Usage Guidance**: - If the codebase is not indexed, this tool will return a clear error message indicating that indexing is required first. - You can then use the index_codebase tool to index the codebase before searching again.
No output schemas documented for any tool. LLMs cannot infer return structure, fields, or plan downstream calls. This is a hard requirement for agent integration.
Tool descriptions are 300 - 500+ characters, well above the best-practice range of 50 - 200 chars. Excessive length wastes tokens and buries key information. Example: index_codebase description spans ~380 chars with redundant emphasis (bold warnings, multiple bullet sections).
index_codebase description states 'you MUST prompt the user to confirm' for force re-indexing. This implies stateful interaction and user confirmation within tool execution, which is not a standard MCP pattern. STDIO-only servers cannot reliably implement this without Multi Round-Trip Requests (MRTR). Clarify whether confirmation is expected via MRTR or if the tool proceeds without confirmation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
clear_index has minimal description ('Clear the search index. IMPORTANT: You MUST provide an absolute path.'), 63 chars, below the 194-char baseline. This is a destructive operation (marked Risk: DESTRUCTIVE) but lacks guidance on consequences, error recovery, or why absolute paths are mandatory.
No error handling patterns visible in schemas. No recovery guidance, retryability classification, or actionable error messages documented. A search failure (e.g., codebase not indexed) returns 'a clear error message' per description, but the schema doesn't define error structure or how LLMs should respond.
search_code has no pagination constraint visible in the schema description or limit parameter. The 'limit' param has a 'maximum': 50 constraint in JSON Schema, which is good, but the description does not mention pagination behavior or total count return field, critical for large result sets.