Loading ToolBench
Indexes code repositories into a knowledge graph and exposes code intelligence via MCP tools. Enables hybrid search, impact analysis, change detection, and refactoring support across codebases.
Mimir has well-structured tool definitions with clear names, detailed descriptions, and proper JSON schemas. However, there are systematic gaps in parameter descriptions and missing output schema documentation. All 12 tools are explicitly registered in mcp/tools.go with name, description, and inputSchema. Tools follow verb_noun naming (query, context, impact, detect_changes, rename, cypher, list_repos, find_referencing, symbol_coordinates, get_symbols_overview, find_symbol_body, query_repo). Tool descriptions are generally strong (avg ~100-150 chars), addressing what the tool does and when to use it. Input schemas are present for all tools and properly typed. However, many parameter descriptions in schemas are either missing entirely or minimal. Output schemas are not documented anywhere in the provided code, LLMs cannot predict what fields will be returned. Error handling guidance is absent. The rename and cypher tools accept write operations but lack dry-run/confirmation patterns despite one tool supporting dry_run. The query_repo tool correctly whitelists read-only operations.
360-degree view of a symbol: definition, incoming/outgoing edges, processes.
Run a Cypher-subset query against the knowledge graph (translated to SQL).
Detect uncommitted/recent git changes and their impact on the codebase.
Find all symbols that directly reference (call, import, extend, implement) a given symbol. Lighter than impact — returns 1-hop inbound edges only.
Returns the exact source code body of a symbol (function, method, class) by name, including file_path, start_line, end_line, and the full implementation text. Use when you see a function name in logs or stack traces — fetches only the relevant lines instead of reading the whole file.
Gets an overview of all top-level symbols defined in a given file, sorted by line number. Excludes nested methods and members. Use to understand file structure before editing.
Output schemas not documented. Tools return results but LLMs cannot predict field names, types, or structure. This forces LLMs to guess how to parse responses, increasing hallucination risk and preventing composition of tool chains (e.g., does 'query' return symbol_ids for use in 'context'?).
Parameter descriptions are minimal or absent in JSON schemas. The 'query' parameter in 'query' tool has no description beyond the field name. The 'scope' parameter in 'detect_changes' lacks context. The 'edge_types' array in 'find_referencing' has a description but no format guidance on what a single edge_type string should contain.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Blast radius analysis: what does changing this symbol break?
List all indexed repositories.
Hybrid search over the code knowledge graph. Returns process-grouped results.
Execute a whitelisted read-only tool against a different indexed repository. Pass tool_name, arguments, target_repo, and optional current_repo. Allowed tools: query, context, find_referencing, symbol_coordinates, get_symbols_overview, impact.
Plan a coordinated multi-file rename of a symbol.
Return the exact file path and line range for a symbol. Use before editing — gives the precise location to replace.
No error handling guidance. Tools do not document what errors can occur, what they mean, or how LLMs should recover. E.g., 'cypher' may fail with invalid Cypher syntax, but no error schema tells the agent what went wrong or what to try next.
Write tools (rename, cypher) lack confirmation or dry-run enforcement. The 'rename' tool supports dry_run as optional, but 'cypher' can execute arbitrary queries with no safety guard. A malformed Cypher query could corrupt the knowledge graph.
Parameter 'edge_types' in 'find_referencing' documented as array of strings with enum values ('CALLS', 'IMPORTS', 'EXTENDS', 'IMPLEMENTS', 'MEMBER_OF') inline in description, but not as a JSON Schema enum constraint. LLMs cannot programmatically validate and may hallucinate invalid values.
Parameter 'direction' in 'impact' tool is an enum ('downstream', 'upstream') but lacks description text explaining what each direction means in the context of impact analysis.
No pagination guidance. 'query', 'find_referencing', and 'context' accept optional 'limit' or no limit parameters. The description states 'default 20' for query, but missing documentation on whether results are paginated, how to fetch the next page, and whether there is a hard cap on results.
Tool 'cypher' description states 'Cypher-subset query against the knowledge graph (translated to SQL)' but does not document what subset is supported, error cases, or examples. LLMs may attempt full Cypher syntax and fail.