Loading ToolBench
MCP server enabling symbol-aware semantic search in Claude Code
Single tool 'index_codebase' has a reasonable high-level description but critical gaps in parameter documentation and schema completeness. Description is adequate (~180 chars) but parameter descriptions are sparse or missing critical constraints. No output schema is documented in the visible code. The tool performs a complex orchestration (discovery, AST parsing, chunking, vector upload) that should be split into separate tools per the single-responsibility pattern. STDIO transport caps overall score at 50, but definition quality issues lower it further.
Main indexing orchestration method that discovers files, extracts symbols with AST parsing, generates chunks with dependency context, and uploads to vector store
Missing output schema documentation. No visible definition of what index_codebase returns (success boolean, chunksCreated count, errors array, etc.). LLMs cannot plan downstream actions without knowing response fields.
Tool name 'index_codebase' is vague and does not follow verb_noun convention. Does not clearly express that this is a WRITE operation with side effects (creates vector index, mutates namespace). Better: 'create_codebase_index' or 'index_and_upload_codebase'.
Parameter 'supportedLanguages' has no validation constraints in visible schema. Acceptable values are not enumerated. LLM could pass invalid language names (e.g., 'python3' vs 'python', 'typescript' vs 'ts'). Should be enum or have format constraint.
Parameter descriptions are terse and lack practical constraints. 'forceReindex' says 'Whether to force reindex and clear existing namespace' but does not warn that this is DESTRUCTIVE and irreversible. Risk classification missing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Tool conflates multiple distinct operations: file discovery, AST parsing, chunking, and vector database upload. Should be split into separate tools (list_codebase_files, parse_symbols, create_chunks, upload_vectors) so agent can compose them or retry individual steps.
Parameter 'codebasePath' accepts a filesystem path as a string but no validation is visible. No documentation of allowed paths, path traversal prevention, or sanitization. Agents could pass paths like '../../../etc/passwd'. Missing security pattern application.
No error handling guidance. If indexing fails (e.g., invalid path, no indexable files, vector DB unavailable), the LLM receives no recovery hint. Should return error messages like 'Path not found: /foo/bar. Check path exists and is readable' or 'No indexable files found in /path, supported formats: .ts, .js, .py'.
No idempotency or dry-run support. Tool description does not clarify whether multiple calls with same codebase path and forceReindex=false will be safe (idempotent) or create duplicates. Agents retrying on transient failures could corrupt the index.
Risk classification present ('Risk: WRITE') but not propagated to schema annotations or description. No destructiveHint or idempotentHint present in tool definition (toolAnnotations feature is false). LLM cannot infer tool safety from metadata.
Parameter 'enableContentFiltering' and 'enableDependencyAnalysis' provide boolean flags but lack documentation of what filtering/analysis actually does, what content is filtered, and when you would disable it. Descriptions should explain use cases and trade-offs.