Loading ToolBench
Local-first MCP server giving AI coding agents fast, structured, and semantic context over any codebase.
Argyph is a Rust-based codebase analysis MCP server with 5 semantic search and introspection tools. Tool definitions are present with reasonable naming (all verb-noun form: locate, read_file_range, get_symbol_outline, get_repo_overview, get_index_status) and brief descriptions. However, descriptions are minimalist (averaging 65 chars, well below the 194-char baseline for production tools), parameter descriptions are generic or absent, and no output schemas are documented in the provided source. All tools are READ_ONLY, reducing risk, but the schema and description quality falls short of the 70+ threshold. The implementation is well-structured (monorepo with 12 crates, proper linting, no unsafe code), suggesting solid engineering, but tool interface design needs strengthening for LLM integration.
Get the current indexing status including tier readiness, file counts, and symbol counts
Get a high-level overview of the repository including file counts, language breakdown, and largest files
Get the hierarchical symbol structure (functions, classes, methods, etc.) of a file
Semantic search for symbols, files, and concepts in the codebase using embeddings
Read a specific byte range from a file in the repository
Output schemas not documented. No evidence in source that return types, field names, or response structures are specified for any tool. LLMs cannot plan downstream tool calls or extract required data without knowing what fields to expect.
Descriptions are below-baseline brevity and lack LLM context. 'Semantic search for symbols, files, and concepts in the codebase using embeddings' (65 chars) lacks WHEN to use, dependencies (e.g., 'Call get_index_status() first to check readiness'), or what structure is returned. Baseline is 194 chars; production A+ tools range 50 - 200 chars with actionable context.
Parameter descriptions are generic or missing context. 'query' lacks guidance on syntax (keywords vs. natural language?), 'k' has no min/max bounds or default, 'file' has no validation rules (e.g., 'path relative to repo root, no ../ traversal'), 'byte_range' lacks format explanation (inclusive/exclusive bounds?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
No pagination or result-limiting strategy documented for locate(). Semantic search can return hundreds of matches; returning all risks context explosion. Production pattern requires limit, offset/cursor, and total count in response.
No error handling guidance. Tools lack descriptions of failure modes (e.g., 'file not found', 'index not ready', 'query syntax error') or recovery instructions. An LLM receiving a bare error code has no context for retry or alternate paths.
read_file_range() parameter 'byte_range' is typed as array of integers but lacks description of bounds semantics. Are bounds inclusive or exclusive? What happens if start > end or range exceeds file size? LLMs need explicit behavior specification.
Tools lack composition guidance. For example, locate() is described as semantic search, but no documentation hints whether get_symbol_outline() is needed for precise code structure after a semantic match, or what each tool's response contains to support chaining.