Loading ToolBench
Stria provides 11 tools with complete input schemas and descriptions. Naming is verb-forward (orient, search, code_search, who_calls, trace_callers, expand_body, find_hash, health, switch_repo) and mostly clear. Descriptions are detailed (80 - 250 tokens) and include usage guidance ('Use when:', expansion tiers, prerequisites). However, parameter descriptions are absent, no docs for 'task', 'query', 'name', 'depth', 'file', 'hash', 'path' fields. Output schemas are not documented anywhere in the source. Error handling and recovery guidance are not visible. The tool set is well-composed (single responsibilities, clear chains: code_search → expand_body → find_hash), but lack of parameter and output documentation significantly limits LLM reasoning quality.
Single composite tool for all code-search needs. Three expansion tiers: default (compact paths, ~80t), expand_plan (+read_order/risk, ~150t), expand_full (+who_calls/hidden_deps, ~250t). Use when: editing code, finding test files, checking impact.
Expand a [HORIZON: hash] marker to full function body. Use when: orient output shows an horizon marker and you need to read the function source. Input: the hex hash from the marker.
Find horizon hashes by function name. Use when: you know a function name and need its hash for expand_body. Input: function name or partial name.
Server health check. Returns DB stats and latency. Use when: connection issues or monitoring.
Find hidden cross-module dependencies that imports don't reveal. Use when: checking if a refactor reaches outside the current module. Input: file path relative to repo root.
One-time session orientation. Returns tool workflow map + language breakdown. Call this first. ~80t.
No parameter descriptions. All 11 tools expose parameters (task, query, name, depth, file, hash, path) with no documentation of what they accept, expected format, or constraints. LLMs cannot infer whether 'task' is a free-form string, a structured query, or a code snippet.
Output schemas not documented. No tool documents what fields it returns, data types, or structure. LLMs cannot plan downstream calls or extract required IDs (e.g., does code_search return file paths, line numbers, risk scores?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Full execution plan with read_order, edit target, verify candidates, fixtures, coupled files, risk level. Use when: you need detailed pre-edit guidance beyond what code_search default tier provides.
Find files by conceptual content (not filename). Use when: you know what the code does but not where it lives. Input: free-form query of 1-5 keywords. Returns: top 10 files with relevance scores.
Switch the active repo and rebuild index if needed. Use when: working on multiple projects in one agent session. Input: path to the repo root.
Find callers through N hops. depth=1 is same as who_calls, depth=2 finds callers of callers. Use when: need full impact analysis across module boundaries.
Find all files that reference a specific identifier. Use when: refactoring a function and need to check callers. Input: exact identifier name (case-sensitive).
No error handling or recovery guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next (e.g., if code_search finds no results, should the agent broaden the query or try a different tool?).
Parameter constraints not specified. 'depth' in trace_callers has no min/max; 'query' in search has no length limit or keyword count guidance (description says '1-5 keywords' but schema does not enforce it).
Tool composition risk: expand_body requires a 'hash' parameter, but find_hash returns function names, not hashes. The chain is unclear, does find_hash return hashes that expand_body accepts, or must the LLM infer the mapping?