Loading ToolBench
Hybrid code search for agents. Bun, TypeScript, Takara embeddings. Semantic and keyword search via MCP.
Miru provides 6 code-search-focused tools with solid descriptions (avg 180 chars) and reasonable parameter schemas. Naming is verb-forward (search, locate, expand, find_related, read_benchmark) and clear. However, output schemas are not explicitly documented in the source code provided, parameter constraints are inconsistent (some enums present, others missing), and error handling guidance is minimal. The auth tool is well-described with recovery hints, but the remaining tools lack actionable error messages and post-conditions. No tool annotations (readOnlyHint, destructiveHint) are visible. This is solid domain-specific tooling but falls short of A-grade polish.
Sign in with Takara credentials via device-code login — no terminal required. Only call this in direct response to a tool error mentioning missing, expired, rejected, or invalid credentials — never speculatively, since it starts a real sign-in prompt for the user. Call with no arguments (or action "start") to begin: it opens the device-login page in the user's browser and returns that URL plus a short code. Once the user approves, call `auth` again with action "check" to finish signing in.
Expand a code snippet around a specific line to see more context. Returns the file content with line range expanded up to 100 lines before/after.
Find code snippets related to an existing search result or chunk. Semantic similarity search within the indexed repository.
Find exact literal substrings, environment variables, symbols, error codes, or quoted text in a repository. Returns count, locations (path:line), or lines with context.
Read benchmark history and comparison metrics for code search queries. Inspect token counts, recall, and performance deltas between different search backends.
Output schemas not documented. Tools return results but LLMs cannot plan downstream chaining without knowing field structure (e.g., does search return chunk_id, file_path, score, text? In what order?). Rubric requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.'
Missing tool annotations. No readOnlyHint visible in code. All 6 tools are marked READ_ONLY in metadata but not exposed as tool annotations in schema or response structure. Current spec (2026-07-28) expects toolAnnotations for production tools.
Error handling lacks recovery guidance. Tools provide no hint text (e.g., if search fails with 'repo not found', what should the agent do next?). auth-tool.ts defines toolErrorText() and RECOVERY_HINT for auth, but other tools do not expose similar patterns in their definitions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Natural language or code search for finding relevant code snippets in a repository using hybrid keyword + semantic retrieval. Indexes `repo` on first call; later calls reuse the session cache.
Parameter schema inconsistency. Some params have full type + description (search: query, repo, top_k, dedupe_by_file); others lack clarity. E.g., locate.literal is documented as 'union' but JSON Schema type is unclear, does it accept string OR array? Rubric: 'Every parameter needs a description explaining what it controls.'
No pagination documented for list-style results. search and locate can return many matches (locate even says 'Omit to return ALL matches'). Rubric: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.' locate.limit exists but no mention of total_count or next_cursor in response.