Loading ToolBench
Provides AI-driven codebase context using Google Gemini API. Analyzes local code repositories and generates intelligent context for AI assistants.
The Kontxt server provides 4 READ_ONLY code exploration tools with clear action-verb naming (list_, read_, grep_, referred_). All tools have descriptions and input schemas visible in the code. However, descriptions are moderately detailed but lack optimal LLM-targeting (many exceed 200 chars), parameter descriptions are adequate but generic in places, and output schemas are NOT documented anywhere in the source. The TokenTracker utility and response analysis functions are well-implemented internally but not exposed as tools. Security is appropriate (all operations are read-only with no secrets in parameters). Error handling is minimal, tools will fail with unguided errors rather than recovery instructions. This is a solid utility server that works well for its narrow use case but lacks polish for production recommendation.
Searches the codebase for a pattern using grep, returning matching lines with file paths and line numbers.
Lists the structure of the repository starting from the given path, optionally filtering by file extensions or excluding certain directories.
Reads the content of specified files from the repository.
Reads a specific file referenced in the conversation context, with optional line range specification.
Output schemas not documented. Tools return results but no schema definition is visible in source code (e.g., what fields does list_repository_structure return? Is it a tree object with name/type/size? A list of strings?). LLMs cannot plan downstream operations without knowing response structure.
'referred_file' naming is ambiguous and passive. 'referred' suggests the file was already mentioned (past tense), but the tool reads ANY file. Better names: 'read_file' (if single), 'read_file_range', or 'read_file_slice'. The current name does not convey the action clearly.
Error handling and recovery guidance are absent. Tools will fail silently or return unstructured errors (e.g., 'file not found', 'invalid regex'). No error descriptions guide the LLM to retry differently or use an alternative tool. Per pattern:recovery-guide, errors should say 'Try list_repository_structure first if you do not know the path.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | <=2025-11-25 | v2 |
Parameter descriptions in 'read_files' and 'referred_file' lack detail. 'file_paths' description is only 'List of file paths to read from the repository', no guidance on whether paths are relative to repo root, must exist, or have size limits. LLMs cannot validate inputs without detailed constraints.
No pagination or result limits documented. 'grep_codebase' could match thousands of lines; 'list_repository_structure' could return thousands of files. Without max_results or pagination guidance, these tools risk blowing the context window. Per mxe:enforce-result-limits, cap results at 20-50 and document in descriptions.
'max_depth' parameter in list_repository_structure defaults to 3 but this constraint is not documented in the parameter description. LLMs will not know the default behavior if they omit the parameter.