Loading ToolBench
World's fastest code intelligence MCP server for multi-language code indexing, symbol search, call graph analysis, and impact radius computation
Kernava MCP demonstrates solid tool design with 16 well-named, verb-prefixed tools covering code intelligence operations. All tools have descriptions and input schemas with typed parameters. However, output schemas are not documented in the provided source, parameter descriptions lack depth (missing format constraints, ranges, and dependency hints), and error handling guidance is absent. Tool names follow verb_noun convention (search_symbols, get_symbol, find_references) and are action-oriented. The server supports 11 read-only tools and 1 write tool (index_project), with clear risk classification. Descriptions average ~80-120 chars, below the 194-char baseline for A+ tools. Parameters like 'max_depth' lack range documentation (default 20 stated but no min/max bounds). No examples of recovery guidance or actionable error messages visible in source.
Identify symbols that are never called (dead code detection)
Find the definition of a symbol that is called from a specific location
Find all references to a symbol throughout the codebase
Analyze and return the high-level architecture of the codebase based on call graph communities
Find a call path between two symbols in the call graph
Get all functions called by a given symbol, with optional depth limit for transitive callees
Get all functions that call a given symbol, with optional depth limit for transitive callers
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure. All 16 tools lack documented return types.
Parameter descriptions lack actionable constraints. 'max_depth' parameters (get_callers, get_callees, get_call_path, get_impact_radius, get_git_impact) state default 20 but omit min/max bounds, format requirements, or guidance on when to adjust. LLMs cannot validate inputs without explicit ranges.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
Detect and return communities (modules) in the call graph using Louvain algorithm
Get the outline of symbols defined in a specific file
Analyze the impact of recent git changes on the codebase
Compute the impact radius of a symbol - all transitive callers and their risk scores
Get the current status of the code index (number of files, symbols, edges indexed)
Retrieve detailed metadata for a specific symbol by its fully qualified name
Index a project from a specified root directory
Search for code patterns using regex across indexed files
Symbol name or fragment to search for (e.g. "handleRequest", "add", "process").
No error handling guidance. Tools lack recovery hints (e.g., 'If symbol not found, try search_symbols() with a partial name'). Error responses will not guide LLM recovery or next steps.
search_code accepts 'file_glob' parameter but lacks documentation on glob syntax (e.g., '*.ts' vs '**/*.ts' vs 'src/**/*.ts'). LLMs will guess at syntax, causing failed searches.
find_definition's 'call_line' parameter description mentions 'numeric string' handling but lacks clarity on when to use it vs omit. Dependency between 'caller_qualified_name' and 'call_line' is undocumented.