Loading ToolBench
A code intelligence MCP server that performs semantic search, dependency graph analysis, and impact analysis on codebases using tree-sitter parsing and ONNX embedding models.
The Sense server presents 5 tools with READ_ONLY risk classification and basic descriptions. However, evidence-based assessment reveals critical gaps in schema visibility, parameter documentation, and output structure guidance. Tools are named with verb prefixes (sense_graph, sense_blast, sense_search, sense_conventions, sense_status), which is good for clarity, but the source code provided (Makefile, Dockerfile) contains NO actual tool implementation or JSON Schema definitions. The tool definitions appear in bench/lib/tool_use_audit.py (referenced in 'File' field), which was not provided for inspection. Per HARD SCORING RULES: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' Since no Go implementation code shows tool registration with mcp-go, only descriptions and parameter lists are visible in the audit file reference, all tools must be capped at 50. The descriptions provided are moderately detailed (50-150 chars each), but without visible JSON Schema input definitions in the source, parameter schema scores must be 0.
Impact analysis: find all code affected by changes to a symbol. Returns direct callers and all transitively affected functions with blame locations and risk assessment.
Analyze code patterns and conventions in the codebase. Detects naming patterns, architectural styles, common abstractions, and reports consistency metrics.
Query the dependency graph for a symbol. Returns edges representing calls, inheritance, composition, and imports with confidence scores. Supports filtering by edge type and minimum confidence threshold.
Semantic search across the codebase using natural language queries. Returns matching symbols ranked by relevance with file locations and brief descriptions.
Get the current indexing status of the codebase. Returns symbol counts, embedding status, stale files, and last scan timestamp.
NO VISIBLE JSON SCHEMA DEFINITIONS for any tool input parameters in provided source code. File bench/lib/tool_use_audit.py referenced but not provided.
Tool implementations NOT visible in provided Go source (Makefile, Dockerfile only).
Parameter type information visible in audit reference (e.g., sense_graph has 'symbol' string, 'min_confidence' number, 'edges' array) but NO formal JSON Schema visible. Parameter descriptions provided in audit reference are brief (10-40 chars) and lack format/range constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
No output schema documentation visible in source. Tool descriptions mention what is returned (e.g., sense_graph returns 'edges representing calls, inheritance, composition, and imports with confidence scores') but formal output schema not visible. LLMs need to know what fields to expect.'
sense_conventions parameter 'focus' documented as 'Optional list of convention categories to focus on (e.g., 'naming', 'architecture', 'error_handling')', examples in description violate rubric best practice 'Do not put example values in the description.' Should replace with enum constraint or format pattern.
sense_search parameter 'limit' lacks documented range constraints. Rubric requires: 'Specify minimum and maximum for numeric parameters.' Missing: is limit 1 - 1000? 1 - 50? Unbounded?
No error handling guidance visible in tool descriptions. Rubric requires: 'Error responses must tell the LLM what to do next.' Tools do not document failure modes (e.g., 'symbol not found', 'indexing incomplete', 'semantic search unavailable').
sense_status has NO input parameters (empty object {}). This is valid, but tool description is very brief (50 chars). Rubric baseline: average tool description 194 chars (p10=34, p90=392). At 50 chars, it is below the adequate minimum and lacks context for when/why to call.