Loading ToolBench
Code Intelligence MCP server that indexes and semantically searches a codebase using Tree-sitter AST parsing and vector embeddings (ChromaDB)
RepoAI-MCP has 11 tools with clear naming (verb_noun pattern) and detailed descriptions (100-300 chars each). However, critical gaps undermine production readiness: (1) Input schemas are visible but lack formal JSON Schema type declarations in the provided code snippet, parameters are documented in docstrings but not in structured schema objects; (2) Output schemas are entirely undocumented, no tool specifies what fields it returns, forcing LLMs to infer structure; (3) Error handling is minimal, most tools return plain strings with no recovery guidance or error classification; (4) No pagination support despite tools like list_symbols and search_codebase that could return large result sets; (5) Security concerns: tools accept local file paths without visible sanitization against path traversal; (6) Composition issues: check_indexing_status and check_repo_changes are workflow steps, not independent tools, they should be optional, not mandatory. Naming is strong (start_new_project, setup_existing_repo, search_codebase are clear), but schema and output documentation are the primary blockers.
[STEP 2 OF WORKFLOW]: Real-time monitor for background indexing. AST parsing and vector embedding are CPU intensive and run asynchronously. This tool queries the SQLite database to report how many files have been successfully parsed and embedded.
[STEP 3 OF WORKFLOW]: The Reality Check. Detects untracked or modified files on disk. AI Context Memory is inherently flawed and easily outdated. The actual files on the user's hard drive are the only ground truth. This tool runs `git status` and `git diff` to identify any files that have been added, modified, or deleted by the user (or by you) since the vector store was last updated.
Retrieves the exact source code and metadata for a specific class, including all its methods.
Retrieves all indexed nodes (functions, classes, methods) from a specific file, providing a summary of the file's structure.
Retrieves the exact source code and metadata for a specific function by name.
Incrementally indexes a single file after it has been modified. Parses the file into AST nodes, generates embeddings, and updates the vector store with only the changed or new nodes.
Output schemas completely undocumented. No tool specifies what fields it returns (e.g., search_codebase returns 'most relevant code nodes' but no field list). LLMs cannot plan downstream calls or extract data reliably.
Input schemas lack formal JSON Schema type declarations. Parameters documented in docstrings but not in structured schema objects visible in code. Cannot verify parameter types, constraints, or enums programmatically.
No pagination support. search_codebase accepts top_k but list_symbols and get_file_summary have no limit/offset. Large codebases could return thousands of symbols, exhausting context window.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Lists all indexed symbols (functions, classes, methods) in the repository, optionally filtered by type. Provides a lightweight architecture map of the codebase.
Creates a GitHub pull request with proposed code changes. Only registered if GITHUB_TOKEN is configured.
Semantically searches the indexed codebase using vector embeddings. Accepts a natural language query and returns the most relevant code nodes ranked by similarity.
[STEP 1 OF WORKFLOW]: Indexes an existing codebase full of code. Use this when the developer points you to a folder that already contains existing source code. This tool safely initializes git (if missing) without touching user code, then spawns a background thread that walks the directory, parses all files into AST nodes via Tree-sitter, and generates semantic embeddings in ChromaDB.
[STEP 1 OF WORKFLOW]: Initializes a brand new, empty project folder for AI tracking. Use this strictly when the developer is starting something from scratch (an empty folder, no existing code). It creates the folder if it doesn't exist, establishes a git baseline (required for change tracking), registers the project in the local SQLite database, and prepares the vector store.
Error handling is minimal. Tools return plain strings (e.g., 'Repo not found') with no recovery guidance, error classification, or actionable next steps. LLMs cannot distinguish retryable from fatal errors.
Path traversal risk. start_new_project and setup_existing_repo accept repo_path without visible sanitization. Malicious input like '../../../etc/passwd' could access unintended directories. No validation against path traversal patterns.