Loading ToolBench
The ultimate RAG for your monorepo. Query, understand, and edit multi-language codebases with the power of AI and knowledge graphs
The server provides 33 tools with mostly clear naming and reasonable descriptions, but exhibits significant inconsistencies in schema completeness, parameter documentation, and error handling guidance. Tool names follow verb-noun conventions well (list_projects, delete_project, query_code_graph), and most descriptions are substantive (100-300 chars), but many parameters lack type definitions or detailed constraints. Output schemas are not documented in the source code provided. Error handling is minimal, tools provide no recovery guidance or actionable next steps. The 'destructive' operations (wipe_database, index_repository, delete_project) are properly flagged in descriptions but lack confirmation/dry-run patterns. A few high-value tools (query_code_graph, semantic_search, structural_search) are well-described, but discovery tools and batch operations could be stronger.
Add or update a custom annotation (gloss) to a definition in the code graph. Annotations help document intent, explain non-obvious code, or flag items for later review.
Delegate a task to a sandboxed AI agent with access to repository tools (query, read, search) but no write or shell access. Use for complex analysis, pattern detection, or multi-step reasoning over code.
Call sites inside a qualified name, one row per site with the callee and the location of the call; `depth` > 1 follows the callees' callees. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
Call sites that invoke a qualified name, one row per site with the caller, file, line, column, argument count and keyword names taken from the CALLS edges; `depth` > 1 follows the callers' callers (`through` names the callee each site invokes). Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
File, line span, docstring and source of one definition by qualified name (`found` is false when the graph has no such node). Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
Output schemas not documented in tool definitions. Tools like query_code_graph, semantic_search, callers, and callees return structured results but no explicit schema is provided for LLM to understand response fields, forcing trial-and-error reasoning about what to extract.
Many parameters lack type constraints and ranges. For example, reingest/paths and reingest/deleted are arrays but specify no element type or length constraints. structural_search/pattern and structural_replace/pattern are strings with no format guidance. depth parameters (in callers, callees) lack min/max bounds, inviting unbounded recursion requests.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Delete a specific project from the knowledge graph database. This removes all nodes associated with the project while preserving other projects. Use list_projects first to see available projects.
Code that reaches an endpoint by its verb and route pattern, or handlers that define that endpoint. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
Endpoints that reach a handler by name or by ID, with their request verb and route pattern. Handler names are scope-sensitive: a top-level handler must name exactly that handler; an inner handler must be qualified to disambiguate. The endpoint identity (verb and pattern) is as listed by endpoints; a handler may have multiple. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
Finds structurally duplicated functions and methods (copy-pastes, including renamed and lightly edited copies) by comparing AST fingerprints stored in the graph. Returns clone groups with file:line locations, largest first: 'exact' groups are certain copies, 'similar' pairs carry a branch-overlap score. Use it to answer DRY questions ('where is this logic repeated?') and before writing a new helper to check whether an implementation already exists. Tune with 'threshold' (0-1 similarity, default 0.8) and 'min_size' (skeleton nodes, filters trivial getters).
Retrieves a specific code snippet from a file by file path and optional line range. Returns the source code with line numbers and pagination information.
Retrieves the source code for a specific function or method using its internal node ID, typically obtained from a semantic search result.
List custom annotations attached to definitions in the code graph. Each gloss includes the definition's qualified name, file location, the annotation text, and the user who added it.
Types that inherit from or implement a class, interface or trait (INHERITS / IMPLEMENTS edges). Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
Modules that import a module, with each import statement's line, column, bound alias and imported symbol. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
WARNING: Clears all data for the current project including its embeddings. Parse and ingest the repository into the Memgraph knowledge graph. Use update_repository for incremental updates. Only use when explicitly requested.
Lists the contents of a directory to explore the codebase.
List all indexed projects in the knowledge graph database. Returns a list of project names that have been indexed.
Methods overriding a method, and the method it overrides (OVERRIDES edges in both directions). Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
Query the codebase knowledge graph using natural language questions. Ask in plain English about classes, functions, methods, dependencies, or code structure. Examples: 'Find all functions that call each other', 'What classes are in the user module', 'Show me functions with the longest call chains'. Results come from a machine-generated Cypher query (returned as query_used) that may be narrower than your question, so treat rows as candidates, not answers. Check the relationship column when present: an import or definition relationship alone does not prove a call. Before reporting call sites, verify them in the source (read the file or fetch the function source), and cross-check suspiciously short result lists with a text search.
Reads the content of text-based files. Images and PDFs the user references are attached inline; read them directly.
Re-ingest specific files into the knowledge graph after editing them. Re-parses only the given files and the files that depend on them, and re-resolves calls in that set only, so an edit lands in the graph in the time it takes to parse the affected dependents (hundreds of milliseconds for a typical file, seconds for a hub imported by dozens) instead of a full update_repository pass. Paths are relative to the project root; files that no longer exist are removed from the graph; paths the project's ignore rules exclude are skipped and reported rather than indexed. Repository-wide passes are not re-run: code-quality findings (smells, vulnerabilities, patterns) and URL-to-endpoint links are rebuilt only by update_repository. Returns the files re-parsed, the dependents re-parsed with them, the files removed, the paths skipped, and the elapsed milliseconds.
External dependencies and the code that imports them. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
Rename a definition (function, class, method, variable) throughout the codebase, updating all call sites, references, and imports. Validates that the new name does not conflict with existing definitions and safely updates the graph.
Resolve a name or a location to qualified names in the graph. `target` is a qualified name, a bare name like `helper` or `Store.get`, or `path:line` (repo-relative path, 1-based line) for the definitions spanning that line, innermost first. Exact matches come first, then dotted-suffix matches, then same-name matches. Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
Performs a semantic search for functions based on a natural language query describing their purpose, returning a list of potential matches with similarity scores. Pass a project name to restrict matches to a single indexed project.
Executes shell commands from allowlist. Read-only commands run without approval; write operations require user confirmation.
Rewrite code by AST pattern using ast-grep syntax. Give a 'pattern' to match and a 'rewrite' template; metavariables captured by the pattern ($A, $$$ARGS) are substituted into the rewrite. Defaults to dry_run=True, which returns a diff without touching files; call again with dry_run=false to apply. Optional 'language' restricts the rewrite to one language.
Search code by AST pattern using ast-grep syntax (not text/regex). Patterns use metavariables: $NAME matches one node, $$$NAME matches many (e.g. 'print($A)', 'def $F($$$ARGS): $$$BODY'). Returns file:line:column and the matched code. Optional 'language' (e.g. 'python', 'typescript', 'csharp') restricts the search.
Surgically replaces specific code blocks in files. Requires exact target code and replacement. Only modifies the specified block, leaving rest of file unchanged. True surgical patching.
Test cases that reach a qualified name (call it, directly or transitively). Deterministic: fixed graph queries, no LLM, same graph gives the same JSON. Use this instead of query_code_graph whenever you know the exact name or location.
Update the repository in the Memgraph knowledge graph without clearing existing data. Use this for incremental updates.
WARNING: Completely wipe the entire database, removing ALL indexed projects. This cannot be undone. Use delete_project for removing individual projects.
Creates a new file with content. IMPORTANT: Check file existence first! Overwrites completely WITHOUT showing diff. Use only for new files, not existing file modifications.
Destructive operations (wipe_database, index_repository, delete_project) lack dry-run or confirmation patterns. Descriptions warn users but no mechanism prevents accidental invocation, agents cannot easily confirm before permanent data loss.
Error handling and recovery guidance missing. No documented error categories (retryable vs fatal). Tools like query_code_graph note that results are 'candidates, not answers' and recommend verification, but no structured error codes or recovery paths are provided. If a graph query returns empty results or times out, LLMs have no actionable next step.
Parameter relationships and dependencies not documented. For example, semantic_search accepts both query and optional project_name, but tool description does not clarify what happens if project_name does not exist or is invalid. reingest/paths vs reingest/deleted, unclear if both can be empty or if one is required.
No pagination or result limits documented for list operations. list_projects, importers, endpoints, endpoint_callers, and remote_dependencies may return large result sets but descriptions do not mention pagination, limits, or total counts. For large codebases, returning thousands of results could exhaust context windows.
query_code_graph description warns that 'results come from a machine-generated Cypher query (returned as query_used) that may be narrower than your question', implying LLM reasoning is needed to verify. No structured error or partial-success handling, if the query is too narrow, the tool silently returns incomplete results rather than signaling lower confidence.
shell_command tool provides no allowlist definition or risk boundary in the schema. Description states 'Read-only commands run without approval; write operations require user confirmation' but no schema documents valid commands, categories, or examples, LLM cannot anticipate which commands are allowed without trial-and-error.