Loading ToolBench
A Codebase MCP Tools server for semantic code search and indexing
WindCodeAssistant provides 4 tools with basic descriptions and functional schemas, but exhibits significant quality gaps. Tool naming is clear and verb-prefixed (list_, get_, index_, search_), which is good. However, parameter descriptions are sparse, error handling guidance is minimal, and schema documentation is incomplete. The server lacks explicit output schema definitions, making it unclear what structured data LLMs should expect. Descriptions exist but are generic, they explain what happens but not when to use each tool or how they chain together. Most critically, there is no error handling guidance in any tool definition, and several security concerns (file path traversal) go unaddressed.
Get the status of background initialization process. The background initialization process includes initializing ChromaDB and embedding model.
Index code files from the specified directories into ChromaDB for later search. This tool scans the specified directories for code files, indexes their content in ChromaDB, and updates existing entries if they have changed. This enables high-quality semantic search over the codebase.
List the contents of a directory. Directory path must be an absolute path to a directory that exists. For each child in the directory, output will have: - relative path to the directory - whether it is a directory or file - size in bytes if file - number of children (recursive) if directory
Search for code snippets based on semantic similarity. This tool uses the embedding model to find code that matches the semantic meaning of your query, allowing you to find related code without exact keyword matches.
No output schema documentation. Tools return JSON strings but LLMs cannot parse structure without a declared schema. list_dir returns JSON array, get_initialization_status returns object, but formats are undocumented.
Insufficient parameter descriptions. 'directory_path' in list_dir has only 'Path to list contents of, should be absolute path to a directory' (70 chars), does not mention format constraints, forbidden paths, or what happens with symlinks. 'query' in search_code has no detail on search syntax, query length limits, or failure modes.
No error handling guidance in any tool description. What should an LLM do if ChromaDB initialization fails? If index_repository fails on one file out of 100? If search_code finds zero results? Descriptions do not guide recovery.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 17 | - | v1 |
Path traversal security gap. list_dir accepts 'directory_path' as a string with no validation beyond 'must be absolute'. An agent could pass '/etc/passwd' or '../../../sensitive' if those resolve to valid directories. No input sanitization visible in tool implementation.
Missing idempotency declaration. index_repository has a 'force_reindex' flag but does not state whether repeated calls with same parameters produce identical results. Agents need to know if retry is safe.
get_initialization_status description (65 chars) lacks context on when to call it or what the response structure is. Does it return a boolean, a progress percentage, or an object? Is there a health check, or only binary initialized/not-initialized?
No pagination support in search_code despite potentially large result sets. A semantic search could match hundreds of code snippets. Without limit enforcement and pagination guidance, LLMs may receive overwhelming responses or miss truncation.