Loading ToolBench
CLI-first semantic code search with MCP integration and interactive D3.js visualization for exploring code relationships
This server has 28 tools with widely varying quality. Naming is generally strong (action-verb prefixed, mostly clear), and descriptions range from excellent (search_code: 229 chars with use case) to minimal (project_status, find_smells: single phrase, ~15-20 chars). Input schemas are present for most search and analysis tools but entirely missing for 6 tools (project_status, find_smells, complexity_hotspots, circular_dependencies, analyze_project, analyze_tests, review_repository). Output schemas are completely undocumented across all 28 tools, we cannot verify what agents should expect back. Error handling and recovery guidance are absent. Composition is reasonable (tools are single-purpose), but response field naming consistency is not verifiable without seeing actual output schemas. Security is a concern: no evidence of secret injection patterns, permission gates, or audit trail capability.
Analyze a specific file for structure, complexity, and quality metrics.
Analyze project structure, complexity metrics, and code quality indicators.
Analyze test coverage and test quality metrics.
Detect circular dependencies and dependency cycles in the project.
Perform detailed code review on specified files.
Identify the most complex functions and modules in the codebase.
Embed code chunks using the configured embedding model.
6 tools lack input schemas entirely (project_status, find_smells, complexity_hotspots, circular_dependencies, analyze_project, analyze_tests, review_repository, wiki_generate, kg_stats, kg_ontology). Per hard scoring rule: schema score must be 0 for these tools.
Output schemas completely missing across all 28 tools. Agents cannot plan downstream tool calls or extract needed data without knowing what fields to expect. This violates the critical requirement that 'LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | 1.12.4+ | v1 |
Detect code smells and anti-patterns in the codebase.
Index or reindex the project codebase for semantic search.
Generate human-readable interpretation of code analysis results.
Build knowledge graph of code relationships and dependencies.
Find all callers of a function at a specific commit in history.
Query knowledge graph historical changes and evolution.
Perform impact analysis on knowledge graph (trace impact of changes).
Get knowledge graph ontology and entity types.
Query the knowledge graph for relationships and dependencies.
Get statistics about the knowledge graph.
Get current project status including index statistics and health metrics.
Review changes in a pull request or commit range.
Perform comprehensive code review on entire repository.
Save analysis report to a file.
Search codebase using natural language queries (text-to-code search). Use when you know what functionality you're looking for but not where it's implemented. Example: 'authentication middleware' or 'database connection pooling' to find relevant code.
Search for code using rich contextual descriptions with optional focus areas. Use when you need broader context around specific concerns. Example: 'code handling user sessions' with focus_areas=['security', 'authentication'] to find session management with security emphasis.
Hybrid search combining vector similarity and keyword matching for flexible code discovery.
Find code snippets similar to a specific file or function (code-to-code similarity). Use when looking for duplicate code, similar patterns, or related implementations. Example: 'Find functions similar to auth_handler.py' to discover related authentication code.
Generate narrative story about code changes and evolution.
Trace execution flow through code (call graph analysis).
Generate documentation wiki from codebase.
10 tools have descriptions under 20 characters (minimal/single phrase): project_status, find_smells, complexity_hotspots, circular_dependencies, analyze_project, analyze_tests, review_repository, wiki_generate, kg_stats, kg_ontology. Per hard scoring rule: description score capped at 0-20 for these. Descriptions lack WHEN to use guidance and contextual information LLMs need for tool selection.
No error handling or recovery guidance visible. Tools that call external services (embedding APIs, git operations, code analysis) lack timeout guidance, retryability classification, or actionable error messages. Agents cannot determine whether to retry or escalate.
No security patterns evident: no secret injection guidance (how are embedding API keys handled?), no permission gates for destructive operations (index_project, save_report, wiki_generate, kg_build), no audit trail capability, no rate limiting. Tools that write to the filesystem or call external APIs expose the server to prompt injection and runaway agents.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. Agents cannot infer which tools are safe to retry (search_code) vs which have side effects (index_project, save_report). Complicates agent error recovery strategies.
Parameter descriptions are sparse and sometimes missing in search tools. E.g., search_code documents 'similarity_threshold' but never explains what the scale means semantically (is 0.3 semantic distance or cosine similarity 0-1 normalized?). 'expand', 'use_mmr', 'use_rerank' lack guidance on when to enable/disable them.
Knowledge graph tools (kg_*) have unclear interdependencies. No documentation of whether kg_query requires kg_build to run first, or what the ontology structure looks like before calling kg_ia. Undocumented dependencies cause multi-step planning failures.