Loading ToolBench
Repo-local code intelligence for AI coding agents - symbols, semantic search, call graphs, routes, and token savings
SymDex MCP provides 21 well-named tools with mostly clear descriptions and reasonable input schemas. However, multiple issues reduce quality: (1) Output schemas are not formally documented, only tool descriptions mention what fields are returned, forcing LLMs to infer structure; (2) Error handling is basic, _err() helper returns structured errors but lacks recovery guidance or actionable next steps; (3) Several parameters lack descriptions or have vague ones; (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification (WRITE, DESTRUCTIVE, READ_ONLY); (5) Responses include ROI metadata and token metrics that may dilute signal. On the positive side: naming is verb-first and consistent (index_*, search_*, get_*, list_*), descriptions clearly state what each tool does, and most parameters have type hints. Per-tool analysis reveals 11 tools scoring 60-70, 10 tools scoring 70-80, indicating middling-to-fair quality across the board.
Build a token-budgeted context pack for an agent query.
Detect circular dependencies in a repo's call graph. Returns up to 20 cycles. Each cycle is a list of files representing the dependency loop.
Remove stale index databases for repos whose directories no longer exist on disk.
Return all symbols called by the named function.
Return all symbols that call the named function.
All symbols in a file without reading full content.
Directory tree of an indexed repo without file contents.
No output schemas documented. Tool descriptions mention return values (e.g., search_symbols returns 'symbols array', build_context_pack returns 'context pack') but formal JSON Schema or structured documentation of response fields is absent. LLMs must infer output structure from descriptions, risking misinterpretation of nested fields, data types, and presence/absence of optional fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Generate a Mermaid call-graph diagram for an indexed repo. Nodes are files; edges are call relationships. Optionally focus on a single file with BFS depth limit. Cycle edges are marked red. Renders in GitHub, Cursor, and Markdown viewers.
Get indexing status for a repo: symbol count, file count, Lines of Code, last indexed time, staleness, and watcher status.
Directory tree and code summary for an indexed repo.
Get comprehensive statistics for a repo: Lines of Code, symbol count, language distribution, top callers/callees, orphan files, and circular dependency count.
Get full source of a symbol by byte offsets.
Bulk symbol retrieval by exact name list.
Index a local folder and return indexing statistics.
Index a repo and register it in the central registry.
Force re-index of a repo or specific file on next call.
List all indexed repositories in the central registry.
Find HTTP routes indexed from a repo. Filter by method or path substring.
Find functions/classes by name. ~200 tokens per lookup.
Text search across indexed files. Returns matching lines only.
Find symbols by meaning using embedding similarity.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification in the spec. Tools marked WRITE (index_folder, index_repo, invalidate_cache) and DESTRUCTIVE (gc_stale_indexes) in the server metadata but not in the tool definition itself. This forces LLMs to remember these classifications from the description alone rather than relying on machine-readable hints.
Missing result limits and pagination guidance. Several tools (search_symbols, semantic_search, search_routes, search_text, get_callers, get_callees) can return many results but descriptions do not mention maximum result count or whether pagination is supported. LLMs may trigger unbounded queries that overflow context or waste tokens.
Error handling lacks recovery guidance. The _err() helper returns structured errors (code, key, message) but error messages are brief and do not suggest next steps. For example, 'Repo not indexed: X' does not guide the LLM to call index_folder or list_repos first. Error responses should include actionable recovery paths.
Parameter 'kind' in search_symbols and 'format' in build_context_pack lack enum constraints. 'kind' description suggests examples (e.g., 'function, class') but does not declare valid values formally. 'format' in build_context_pack has a default ('json') but no enum listing valid formats (json, markdown, plaintext?). This invites LLMs to pass invalid values.
Ambiguity between index_folder and index_repo. Both tools index directories and register repos, with nearly identical parameters (path, repo, name). Descriptions do not clarify when to use which tool, index_folder says 'index a local folder', index_repo says 'index a repo and register'. Are these aliases? Is index_repo deprecated? The naming does not clearly distinguish intent.
Potential response bloat from ROI metadata. The tools (e.g., search_symbols_tool) return responses with 'roi' (return-on-investment), 'roi_summary', and 'roi_agent_hint' fields in addition to the core results (symbols). While potentially useful, these add tokens to every search response, risking context window exhaustion for large queries. The value of token metrics in the response should be weighed against cost.