Loading ToolBench
AI-powered MCP server for codebase navigation and LLM prompt optimization
CodeCompass exhibits several definition quality issues common to community MCP servers. While 9 tools are present with descriptions, most descriptions are terse (34-194 chars range), parameter descriptions are sparse or missing, and no output schemas are documented. Input schemas are visible but incomplete, most parameters lack type annotations. The tool names follow verb_noun convention (search_code, get_changelog) but several are overly generic (agent_query, generate_suggestion). No tool has documented return types, pagination support, or error recovery guidance. The server relies on optional session_id parameters without explaining session lifecycle or dependencies. No parameters declare enums, constraints, or validation rules, leaving LLMs to guess valid inputs. Overall, definitions are functional but fall short of production-grade quality expected in the 70+ range.
Processes the user's complex query about the codebase. Analyzes the query, formulates a plan using available internal capabilities (like code search, file reading, history analysis), executes the plan step-by-step, and synthesizes the information to provide a comprehensive answer to the user's original request.
Generate AI-powered suggestions based on code context and user queries
Retrieve the changelog of the repository
Get the current status of repository indexing process
Get contextual information about the repository structure and recent changes
Retrieve the session history including queries and suggestions
No output schemas documented for any tool. LLMs cannot predict return types, fields, or structure. This forces LLMs to infer output format at runtime, risking parse failures and context loss.
Parameter type annotations largely missing or incomplete. The 'query' parameter in search_code has type 'string' but no constraints (length, pattern, required keywords). The 'modelName' in switch_suggestion_model has no enum declaring valid model names, forcing LLMs to hallucinate model identifiers.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Search the codebase for relevant code snippets and files using vector similarity search
Switch between available LLM models for suggestion generation
Trigger indexing and update of the repository in the vector database
Descriptions lack actionable detail. 'Processes the user's complex query' (agent_query) and 'Generate AI-powered suggestions' (generate_suggestion) tell LLMs little about when to invoke each tool vs. the other, what inputs trigger what behavior, or what constraints apply. Baseline production tools have 50-200 char descriptions explaining WHAT, WHEN, and PREREQUISITES.
session_id parameter is optional across multiple tools (agent_query, get_session_history, generate_suggestion) but session lifecycle and dependency semantics are undocumented. What happens if session_id is omitted? Does the tool create a new session or use a default? Can queries from different sessions interfere? This ambiguity forces LLMs to guess.
No error recovery guidance. Tools provide no documentation on retryable vs. fatal errors, what to do if a search returns no results, or how to handle indexing failures. Per pattern:recovery-guide, error responses must tell LLMs 'what to do next.'
Tool names agent_query and generate_suggestion are vague. 'agent_query' does not convey that it orchestrates multiple sub-tools internally, it reads as a simple query forwarding tool. 'generate_suggestion' is ambiguous: suggestions for what? Code refactoring? Architecture? Bug fixes? These names rely on description text rather than being self-documenting per pattern:tool.
No pagination or result limits declared. get_session_history and search_code offer no limit/offset parameters and document no maximum result count. Per pattern:paginated-result, tools returning lists should accept limit and return counts to prevent context window overrun.
write-classified tools (switch_suggestion_model, trigger_repository_update) provide no dry-run or confirmation step. Per pattern:confirmation-request, irreversible operations should support confirmation to prevent accidental state changes by agents.
No parameter descriptions for empty-input tools. get_changelog, get_indexing_status, trigger_repository_update have no parameters documented, making it unclear if they operate on the entire repository or require context (branch, project key, etc.). Tools with no inputs should still explain their scope.