Loading ToolBench
MCP server for instant code search and semantic code exploration across local or remote git repositories
Ken is a codebase search and analysis MCP server with 10 tools focused on code intelligence. All tools are READ_ONLY except reindex_db. Tools have clear names (search, find_related, definition, references, callers, outline, symbols) and comprehensive descriptions (150-250 chars each). Input schemas are fully visible with proper type definitions and parameter descriptions. Output format selection is consistent across tools. However, output schemas are NOT documented, the tool descriptions explain WHAT is returned but not the structured response schema. Error handling is implicit rather than explicit (no recovery guidance). The server follows good naming conventions (verb_noun pattern) and provides well-scoped tools, but lacks specification of return types and error categorization patterns. This is solid for a code-analysis tool but falls short of production A-grade by omitting output schema documentation and structured error handling.
Given a function name, return the list of FILES that contain a call to it. File-level granularity: if a file has 5 functions and one of them calls the target, the file shows once in the list.
Given a symbol name, return the file(s) where it's defined. Tree-sitter-grade: collisions return all sites (ordered alphabetically by file path); ambiguity is NOT resolved by type.
Find code chunks semantically similar to a specific location in a file. Use after `search` to explore related implementations or callers. Pass file_path and line from a prior search result.
Return the structural outline of a file or directory: top-level symbols, classes, methods, and functions with their line numbers.
Returns recently changed files in a git repository by walking the commit history.
Given a name, return every file where it appears in a recognized syntactic context (call site, import statement, or raise statement). Name-resolved, not type-resolved — same-spelled identifiers in different contexts collapse into one list.
Output schemas are not documented. Tool descriptions explain conceptually what is returned (e.g., 'Returns recently changed files') but do not specify the JSON structure, field names, types, or pagination metadata. LLMs cannot reliably extract and chain results without knowing the response schema.
Error handling and recovery guidance are absent. Tools do not document what errors can occur (e.g., 'repo not found', 'invalid symbol name', 'tree-sitter parse error') or how to recover. Descriptions mention tree-sitter and collisions but do not map these to error conditions and suggested next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Trigger an immediate refresh of database-backed chunks. Returns the outcome and elapsed time. Only available when the server is configured with a database integration.
Search a codebase with a natural-language or code query. Pass a git URL or local path as `repo` to index it on demand; indexes are cached for the session. Use this to find where something is implemented, understand a library, or locate related code.
Returns the server status including cache state and index information for a repository.
Return every top-level symbol in a path (file or directory): functions, classes, methods with line numbers.
No documented pagination or result limits. Tools like 'search' and 'references' can return many results but do not specify how many are returned by default, what the max is, or how to iterate. This risks context window exhaustion and incomplete result sets.
'limit' parameter exists in 'search' tool but is not documented with a range (e.g., 'max 100', 'default 20'). This leaves the LLM guessing what values are valid. Same for 'n' in 'recently_changed', stated as 'default 10, max 100' but this constraint should be in the parameter description, not just the main description.
'reindex_db' tool has minimal description ('Trigger an immediate refresh...') and is conditional ('Only available when the server is configured with a database integration'). The condition should be documented in the description, and error handling for the unavailable case should be specified.