Loading ToolBench
CTX provides 6 well-named, read-only code-intelligence tools with clear descriptions and documented schemas. Tool names follow verb_noun convention (ctx_search, ctx_symbol, ctx_dependencies). Descriptions are substantive (90-250 chars) and explain WHEN to use each tool and what it returns. All tools have proper input schemas with type definitions and parameter descriptions. Output schemas are documented for at least ctx_project. However, output schemas are missing for 5 of 6 tools (ctx_search, ctx_skeleton, ctx_symbol, ctx_dependencies, ctx_dependents), which limits downstream LLM planning. Parameters are well-constrained (e.g., ctx_search.kind uses enum, limit is bounded 1-500). No security issues detected (read-only, no secrets, no injection vectors). Error handling relies on the framework and is not explicitly documented in tool descriptions. Tool composition is excellent, each tool has a single responsibility and output fields chain cleanly (e.g., ctx_search returns paths that ctx_skeleton accepts). Descriptions follow the LLM-optimized pattern of stating WHAT, WHEN to use, and what to expect.
Return the outbound import edges of a file as JSON: [{target, imported_symbol}] — the project files/modules it imports and, where known, the symbol imported. Use to see what a file depends on before refactoring it. path is project-relative or absolute (traversal rejected). For the reverse direction (who imports this) use ctx_dependents. Requires the project to be indexed.
Return the inbound (reverse) dependency edges of a file as JSON: [{source, imported_symbol}] — the project files that import it and, where known, the symbol they import. Use to find every consumer of a file before changing or removing it. path is project-relative or absolute (traversal rejected). For the forward direction (what a file imports) use ctx_dependencies.
Return the project overview as JSON: {root, git, files, symbols, dependencies, languages}. Use this first to orient a coding agent on a repo: absolute root path, git root, and how large the codebase is (counts of indexed files, symbols and dependency edges, plus the distinct languages present). Requires the project to have been indexed (see ctx_search for symbol lookup). Returns only counts, never file contents. Prefer ctx_stats for detailed index-health numbers (e.g. index.db size) and ctx_search to actually find symbols.
Search the project's code graph for symbols or file paths by name and return JSON. Symbol results give {name, parent, kind, path, line, signature}; with files=true results give {path, language, size}. Use to find where a function/class/type is defined before reading it, or to locate files by path fragment. Use ctx_symbol for deep detail on a single exact symbol, and ctx_impact to see what depends on a match. query is a case-insensitive substring/name match. Constrain with kind (function, method, class, struct, trait, enum, interface, type, constant, variable, module, field, constructor, impl) and limit results (default 50, 1-500).
Output schemas missing for 5 of 6 tools (ctx_search, ctx_skeleton, ctx_symbol, ctx_dependencies, ctx_dependents). Only ctx_project has a documented output_schema. LLMs cannot predict return structure for downstream planning without these schemas.
Error handling not explicitly documented in tool descriptions. Tools reference 'Requires the project to have been indexed' and 'traversal rejected' but do not explain what errors the LLM should expect or how to recover. E.g., what error if a path is outside the project? What if the project is not indexed?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in tool definitions. While all 6 tools are clearly read-only, explicit annotations would help clients optimize caching and retry behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 72 | 2026-07-28+ | v2 |
Return a body-less structural skeleton of one source file as {path, language, skeleton}. The skeleton preserves signatures, types, exports and doc comments but strips function bodies, so it is a compact map of a file's public API and structure. Use before editing a file to understand its shape without reading the whole body. path is project-relative or absolute (must be inside the project; traversal is rejected). Set with_stats=true to also include {stats} (symbol counts). Only paths for supported languages can be resolved (error otherwise); use ctx_search (files=true) to confirm a path first.
Return deep detail for a single symbol as JSON: [{name, kind, signature, file, line, methods, references, dependencies}]. Use when you already know the exact symbol name and need its definition, signature, methods it exposes, everywhere it is referenced, and its dependencies. For fuzzy or name-based discovery use ctx_search first, then ctx_symbol for the best match. Returns an array because a name may resolve in multiple files.