Loading ToolBench
Deterministic repository intelligence for AI coding agents (MCP server): exact source spans, call graphs, clone detection, honest evidence boundaries.
Euthynos demonstrates strong naming conventions (verb_noun pattern: repo_map, file_outline, read_function) and comprehensive parameter descriptions. All 23 tools have clear, detailed descriptions (100-300 chars typical) explaining WHAT they do and WHEN to use them. Input schemas are present and properly typed with required fields marked. However, output schemas are NOT documented in the visible source, the tool definitions show inputs only. Error handling guidance is minimal; tools do not describe recovery paths or error categories. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible despite all tools being read-only. Parameter descriptions are strong but some tools (e.g., query_repository) accept free-form strings without validation constraints.
What is the worst-shaped area of this codebase? Returns architecture metrics (depth, seams, leverage, contamination) per module, sorted by health score, with actionable guidance.
Does this module break the architecture boundaries? Checks the current working tree against declared module boundaries and reports violations.
What does this function call? Returns every call it makes with its source line, plus what those callees call so you can trace downward without re-querying.
Who calls this function/method? Returns every call site with its source line, plus the callers' own callers so you can trace upward without re-querying.
What is the blast radius of my whole diff? Returns the set of all functions, modules, and tests affected by the changes in the working tree.
I just edited code — what changed, what breaks, what should I re-check? Compares the working tree to HEAD: files and symbols changed, boundary violations introduced, blast radius, route-labeled tests, policy deltas.
Output schemas not documented. Tool definitions show input schemas only; return types are not specified in the visible source. LLMs cannot plan downstream tool calls or extract required fields without knowing what each tool returns.
No tool annotations present. All 23 tools are read-only (Risk: READ_ONLY declared), but readOnlyHint is not visible in the schema. Tool annotations enable agents to reason about safety and idempotency.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Two functions look like copies — which should win? Returns both source spans, what differs between them, caller counts, and test coverage so you can make the choice.
I am about to edit X and need the whole picture first: source + callers + callees + types + tests + blast radius in ONE budgeted answer. Composes multiple graph queries into a single token-budgeted response.
What does this module depend on? Returns the module's imports and their transitive dependencies, with cycle detection.
What depends on this module? Returns every module that imports from it, with counts so you can see how widely used it is.
Context for what I changed: the source spans of every symbol touched by the diff, plus their callers and callees, so you have the full picture before reviewing.
Use this INSTEAD OF READING A FILE to see what is in it: every declaration with its exact line range, so you can then read only the one span you need. A file outline costs ~100 tokens; the file costs thousands.
Every place a symbol is used: definitions, call sites, imports. Returns all references with their source lines so you can see the full picture without grepping.
Where does a name live? Searches the repository for a symbol (function, class, type, constant) by name or description, returns every definition with its file and line range.
What breaks if I change this? Returns the blast radius: every caller, every test that exercises it, every dependent module, and a summary of whether the change is isolated or widespread.
Metrics for one module: size, depth, seams, leverage, contamination, callers, test coverage. Use this to understand a module's role and health.
Is there a call path from function A to function B? Returns the shortest path if one exists, or confirms isolation if there is none.
A question in plain words, when none of the above is obviously the fit. Routes the question deterministically to the right tool, resolves the target against the repository's vocabulary, and returns structured evidence.
ALWAYS prefer this over reading a file to see one function: returns the EXACT source span of a function/class/type from the current working tree, plus its direct callers and callees so the next hop needs no search. Reading a 500-line file to inspect a 20-line function is the waste this replaces.
Read an exact line range of one file when you already know the location (e.g. from file_outline or a stack trace). Never returns the whole file.
CALL THIS FIRST in a new session instead of listing directories and reading entry files: one compact map of the whole repository — modules with their size and metrics, entry points, languages, test layout, dependency edges and cycles. Replaces the entire orientation phase for a fraction of the tokens.
Does something like this already exist? Structural clone detection across the whole repository — finds renamed copies, refactored versions, and near-duplicates that text search cannot match.
Which tests exercise this function? Returns every test that calls it (directly or indirectly), with route labels so you know what to re-check after an edit.
query_repository accepts free-form 'question' parameter with no validation constraints. LLMs may pass ambiguous or malformed queries. Add enum-like guidance or validation rules in the description.
No error handling guidance visible. Tools do not document what errors they return, how to recover, or whether failures are retryable. LLMs cannot self-correct on failure.
Numeric parameters (context, budget) lack min/max constraints in visible schema. LLMs may pass unbounded values causing performance issues.