Loading ToolBench
MCP server for codebase analysis with Treesitter (SCM queries), AST parsing, and embedding-based indexing
SRC MCP server provides 22 well-intentioned tools for codebase analysis with consistent naming patterns and basic parameter schemas. However, definitions lack depth: descriptions are often minimal (10-50 chars), output schemas are not documented in the source, error handling guidance is missing, and parameter descriptions lack implementation details. Tool names follow verb_noun convention well (list_, get_, search_, analyze_). Most tools have at least one parameter, but parameter descriptions are generic ('File path relative to project root' repeated verbatim across 10+ tools). No evidence of field-level documentation in responses or chaining guidance. Security surface (WRITE tools index_codebase, update_index) has no mention of permissions or audit trails. Composition is strong, tools have single responsibilities and are designed for semantic code analysis. This is a solid mid-range server with room for polish.
Analyze the impact of changes on the codebase
Assemble context for a specific task or feature
Find unused or dead code in the codebase
Find symbols in the codebase by name or pattern
Get the call graph for a symbol or file
Get symbols changed in a git revision
Get a code snippet from a file
Get the dependency graph of modules or packages
Output schemas not documented in source code. No visible schema definitions for return values across all 22 tools. LLMs cannot plan downstream calls or extract specific fields without documented output structure.
Parameter descriptions are generic and repeated verbatim. 'File path relative to project root' appears in 10+ tools without explaining what format the path should take, how it's resolved, or what happens if the path doesn't exist. Descriptions lack actionable constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Get git context and history information
Get the current indexing status of a project
Get project artifacts and metadata
Get project context and configuration for onboarding
Get a map of the repository structure and organization
Get the symbol at a specific code position
Get the symbol dependency graph
Index the codebase for semantic search and analysis
List available projects for analysis
List all symbols in a file or project
Run static analysis using local opt-in tools (ast-grep, Semgrep, CodeQL)
Search code using hybrid search (FTS plus lexical or code-aware reranking)
Navigate code semantically using LSP or SCIP
Update the project index after changes
WRITE tools (index_codebase, update_index) lack idempotency documentation and error recovery guidance. No evidence of dry-run support, confirmation patterns, or rollback capabilities. Critical for stateful indexing operations that could corrupt project state.
No permission gates, audit trails, or secret injection patterns visible. WRITE operations (index_codebase, update_index) modify local filesystem state but show no access control checks. Credentials for LSP servers (pyright, rust-analyzer, etc.) may be exposed if configured.
Error handling is opaque. No visible error recovery guidance in tool definitions. LLMs cannot determine if a failed index_codebase call is retryable, user-fixable, or fatal. No guidance on 'call search_code() instead' or 'configure LSP server first' patterns.
No pagination support visible in tools that return lists (list_projects, list_symbols, find_symbols, get_call_graph). Large result sets could blow context window. No limit/offset or cursor parameters documented.
Multi-parameter tools (e.g., semantic_navigation with line/column; run_static_analysis with tool/ruleFile) lack documentation of parameter relationships and dependencies. No guidance on which combinations are valid or what happens if optional params are omitted.
Descriptions are below the 50-200 char production baseline for many tools. get_index_status ('Get the current indexing status of a project') is 50 chars but lacks context on why an LLM should call it vs. other tools or what the response format is.