Loading ToolBench
Compressed context provider for planner/reviewer/refactor agent harnesses. Rust MCP code intelligence for coding agents — live indexes, bounded hybrid retrieval, host-neutral workflows, single-writer sessions, and mutation gates.
CodeLens MCP exhibits significant definition quality gaps across all dimensions. While 21 tools are declared, most lack visible input schemas in the provided source code, and descriptions are present but often generic. The server demonstrates weak naming clarity (ambiguous names like 'search', 'review', 'start_analysis_job'), incomplete parameter documentation, and missing output schema declarations. Tools like 'prepare_harness_session', 'get_ranked_context', and 'semantic_search' have descriptions but no visible input schemas in the codebase provided. Of the 21 tools, only ~5 have clear input parameter structures documented. Error handling is not evident from the source. The HTTP transport is present, but definition quality itself is mediocre, typical of community servers that prioritize feature breadth over LLM-optimized schema clarity.
Queries the audit log for security events and access records
Searches for symbols using BM25 full-text search algorithm
Finds all symbols that reference a given symbol
Finds symbol definitions and locations in the codebase
Gets a list of functions that call a given symbol (hidden alias for get_referencing_symbols)
Gets the capabilities and supported file types for analysis
Calculates and returns code complexity metrics for a file
Missing or unverifiable input schemas: 11 of 21 tools (52%) have no visible schema definitions in provided source code (start_analysis_job, search, review, insert_after_symbol, write_memory, audit_log_query, get_callers, review_architecture, semantic_search, and others declared in integration_tests but not in implementation). Cannot verify parameter types, constraints, or format.
Generic and ambiguous tool names reduce LLM selectivity: 'search' (no object specified, search what?), 'review' (review code? generate review?), 'start_analysis_job' (ambiguous vs prepare_harness_session). These violate verb_noun clarity pattern; LLMs conflate similar names.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2025-06-18+ | v2 |
Gets diagnostics (errors, warnings, suggestions) for a file
Gets ranked context for a code intelligence query using hybrid retrieval
Gets an overview of symbols defined in a specific file
Generates an impact report showing how changes to a symbol would affect the codebase
Inserts code after a symbol definition (write operation)
Prepares a harness session for code analysis and symbol indexing on a given project
Initiates a pre-merge review analysis on the codebase
Reviews and analyzes the architecture of the codebase
Searches code and symbols across the project
Searches for symbols using fuzzy matching
Searches using semantic embeddings for code intelligence
Sets the analysis profile/preset for the session
Starts an asynchronous code analysis job on the project
Writes data to memory or persistent storage (write operation)
Multiple tools with overlapping functionality and unclear distinctions: prepare_harness_session vs start_analysis_job (both initiate analysis?), find_symbol vs search_symbols_fuzzy vs bm25_symbol_search vs semantic_search (4 symbol search tools with no documented differences or use-case guidance). LLM must reason about which to use.
Destructive tools (insert_after_symbol, write_memory) and high-risk tools (audit_log_query) lack confirmation mechanisms, dry-run options, or explicit documentation of side effects. No evidence of permission gates or audit trail logging in provided source.
Output schemas not documented in tool definitions. LLMs cannot plan downstream tool calls or extract return data without knowing the structure of responses (e.g., what fields does find_symbol return? Does it include line numbers, file paths, symbol type?). High risk of context loss between tool calls.
Incomplete parameter documentation: tools with visible schemas (prepare_harness_session, find_symbol, get_symbols_overview, bm25_symbol_search, get_ranked_context, find_referencing_symbols, get_file_diagnostics, search_symbols_fuzzy, get_complexity, impact_report, set_profile, get_capabilities) have descriptions and types, but descriptions are brief (30-60 chars). Missing guidance on when to use each parameter, valid ranges, constraints, or dependencies.
No evidence of error handling guidance in tool definitions. Tool descriptions do not explain recovery paths, retryability, or error classifications. Example: 'get_file_diagnostics' does not document what happens if the file is not found, unreadable, or unsupported.
Pagination/result limits not documented. Tools like 'search_symbols_fuzzy', 'bm25_symbol_search', 'get_ranked_context', and 'search' accept 'max_results' but no guidance on default limits, maximum allowed values, or pagination cursors. Large result sets risk context window exhaustion.
Tool definitions inferred from integration_tests and protocol_tools_list.rs rather than visible in implementation code. Tools like 'start_analysis_job', 'search', 'review', 'insert_after_symbol', 'write_memory', 'audit_log_query', 'get_callers', 'review_architecture', and 'semantic_search' are listed in test/test-discovery files but actual handler code is not visible. Cannot verify real behavior, schema validation, or error handling.