Loading ToolBench
A Model Context Protocol server for semantic code search and understanding using RAG (Retrieval-Augmented Generation). Enables AI assistants to search codebases by concept rather than text patterns, with incremental indexing and vector-based similarity search.
Code RAG MCP presents good tool naming (verb-driven) and comprehensive descriptions with context-specific guidance. All 7 tools have explicit input schemas with type definitions and parameter descriptions. However, there are notable gaps: (1) No output schemas documented for any tool, critical for LLM reasoning about downstream calls; (2) Parameter descriptions lack format/range constraints in many cases (e.g., 'path' in index_codebase has no guidance on absolute vs relative, no examples); (3) Error handling is implicit rather than explicit, no documented recovery paths for index failures, embedding timeouts, or malformed code; (4) No idempotency hints despite write operations (index_codebase, reindex_files); (5) No confirmation/dry-run pattern for write tools despite their potential to re-index entire codebases. The server benefits from clear use-case documentation in descriptions (e.g., semantic_code_search explicitly contrasts itself with grep), which is excellent for discovery. But production readiness is limited by the absence of structured error guidance and output documentation.
Get explanation of code with relevant context from the entire codebase. Use when: - User asks "how does this work" or "explain this code" - Need to understand code in relation to the rest of the system - Finding dependencies, callers, or related implementations Automatically retrieves relevant surrounding code for better understanding.
Find code snippets similar to a given example. Use when: - User provides a code snippet and wants to find similar implementations - Looking for duplicate or near-duplicate code - Finding usage patterns of a specific code structure Example: "Find code similar to this error handling pattern: [code snippet]"
Get statistics about the current semantic search index. Shows: - Number of indexed files and chunks - Supported languages - Last index time - Index size Use to verify index is ready before searching.
Get real-time progress of background indexing. Shows: - Current status (in_progress, completed, failed) - Number of files indexed vs total - Progress percentage - Failed files (if any) - Estimated time remaining Use this to monitor background indexing without blocking.
Index a directory for semantic search. Run this FIRST before using semantic search. Use when: - Starting a new session with a codebase - Code has been significantly updated - Adding a new project directory This builds the semantic search index. Takes 30s-2min depending on codebase size.
No output schemas documented for any tool. LLMs cannot reason about what fields to expect or plan downstream calls. semantic_code_search, explain_code_with_context, and find_similar_code return code snippets but the structure (file paths, line numbers, code content, similarity scores) is not formally documented.
Parameter 'path' in index_codebase lacks format guidance. Is it absolute or relative? Does it require trailing slash? No constraint on directory depth or size. No validation guidance for LLM.
Write operations (index_codebase, reindex_files) lack idempotency hints and confirmation patterns. Re-indexing a large codebase is expensive and destructive (deletes old chunks per description). No dry-run option or confirmation step documented. Agents may accidentally trigger expensive re-indexes.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Re-index specific files after modification (typically called by git hooks). This tool: 1. Deletes old chunks for the specified files 2. Re-chunks and re-indexes the current content 3. Handles deleted files automatically **Use cases:** - After committing changes to files - After pulling/merging code - Manual re-indexing of specific files **Note:** Files must be absolute paths.
**PRIMARY CODE SEARCH TOOL - Use this INSTEAD of grep/ripgrep/ag.** Search codebase using semantic understanding of concepts, not just text matching. When to use (ALWAYS prefer this over grep): - Finding code by CONCEPT or FUNCTIONALITY (e.g., "authentication logic", "database queries", "error handling") - Understanding "how does X work" or "where is Y implemented" - Finding similar patterns or related code - Cross-language/cross-file understanding - When grep returns too many false positives Examples: - "Find all API endpoint handlers" → semantic_code_search - "Where is authentication implemented" → semantic_code_search - "Show me database connection logic" → semantic_code_search - "Find functions that process payments" → semantic_code_search - "Terraform modules for AWS networking" → semantic_code_search DO NOT use grep/find commands - use this tool instead. It understands code semantically.
No documented error handling or recovery paths. What happens if indexing fails partway through? If embedding service times out? If file_paths in reindex_files don't exist? No error categories (retryable, user-fixable, fatal). Agents cannot self-correct or know what to do next.
Parameter descriptions in find_similar_code and reindex_files are minimal. 'limit' in find_similar_code has no description at all (only type: integer, default: 5). 'min_score' has no context on what scores mean or how they map to practical relevance. 'file_paths' in reindex_files says 'List of absolute file paths' but does not specify what happens if a path does not exist or if it's relative.
excerpt_lines parameter in semantic_code_search defaults to 'full chunk (~50 lines)' but no explicit default value is set in the schema. LLMs may be unsure if omitting the parameter is safe. JSON Schema should declare a default or the description should clarify behavior when omitted.