Loading ToolBench
MCP Server for Software Project Indexing & Semantic Search
Server has 3 tools with clear verb-based names and non-empty descriptions. All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented, parameter constraints are minimal, and error handling guidance is absent. Descriptions are adequate but could be more specific about when to use each tool vs. alternatives. No tool annotations present. The server follows basic definition patterns but lacks production-grade polish in error recovery and output documentation.
Retrieves the current operational status of the server. This includes information on whether the server is initializing, actively scanning files, or ready and watching for changes. It also provides statistics such as the number of indexed document chunks, helping to monitor the server's health and progress.
Performs a semantic search for a given query against the project's indexed content. It returns the most relevant text chunks from your files based on their meaning, not just keywords. The `top_k` parameter controls the number of results returned. Ideal for finding code snippets, documentation, or relevant context within your project.
Triggers the process of scanning project files, extracting text, and storing it in a vector index for subsequent searching. Use this tool after making significant changes to the project or for initial setup. The `force_reindex` parameter will first delete the existing index, which is useful if files have been deleted or the configuration has changed.
Output schemas are undocumented for all three tools. LLMs cannot determine what fields to extract from responses or plan chained calls without knowing the structure.
Error handling lacks recovery guidance. No tool description explains what to do if the operation fails or what error codes/messages to expect.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Tools lack explicit risk classification that modern MCP clients use to optimize execution.
get_status output schema is undefined. Description mentions 'operational status' (initializing, scanning, ready, watching) and 'statistics such as number of indexed document chunks', but actual response structure is not documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
search_index does not document what fields each result chunk contains. Are results just text, or do they include file path, line number, relevance score?
No guidance on when search_index is NOT appropriate. Description says it is 'ideal for finding code snippets, documentation, or relevant context', but does not explain when to use an alternative (e.g., grep for exact matches vs. semantic search for intent).
Parameter constraints on search_index.top_k are minimal. Min=1, Max=100, default=5. No guidance on what happens if top_k is omitted (does it default to 5?) or if the user passes 1000 (is it clamped or rejected?).
trigger_index does not document whether the operation is synchronous or asynchronous. Should the LLM poll get_status after calling trigger_index, or does it return when complete?