Loading ToolBench
Wave-analysis, ingest and ontology classification for the coding knowledge graph (semantic CLI + MCP transports)
This MCP server has significant quality gaps across naming, descriptions, and schemas. Of 3 tools, only 1 has a minimally adequate schema. Two tools (heartbeat, test_connection) are utility/diagnostic tools with empty parameter objects and generic descriptions. The third tool (determine_insights) has a structured schema but vague descriptions lacking context on WHEN to use it, WHAT it returns, or HOW to handle errors. None of the tools include output schema documentation, error handling guidance, or actionable recovery hints. The server also uses STDIO transport, which is a hard cap of 50 on protocol readiness. Overall, this server would not pass code review for production use.
Determine insights from analysis results using LLM providers
Send a heartbeat to keep the connection alive (call every 30 seconds)
Test the connection to the semantic analysis server
Tool 'heartbeat' has a generic description ('Send a heartbeat to keep the connection alive') that does not explain WHY this tool exists or WHEN an LLM should call it. According to the tool-description pattern, descriptions must state WHAT the tool does, WHEN to use it, and any prerequisites. This description lacks context.
Tool 'test_connection' description (18 chars) is below the 20-character minimum and lacks actionable detail. This tool does not guide the LLM on WHEN to invoke it (e.g., 'Call if you suspect the semantic analysis server is unreachable'). It reads as a diagnostic tool with no clear user-facing value.
Tool 'determine_insights' has a vague description ('Determine insights from analysis results using LLM providers') that does not document: (1) what 'insights' means in this domain, (2) what analysis_type values are valid or when to use each, (3) what the output structure is, (4) error conditions or recovery steps. The description reads like a stub placeholder.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 20 | - | v1 |
No tool includes output schema documentation. Per the pattern, 100% of A+ tools document return types with fields, types, and structure. Users cannot infer what fields determine_insights returns, whether errors are exceptions or error objects, or how to chain downstream calls. This violates the schemas-output pattern.
Parameter descriptions for 'determine_insights' are minimal. 'analysis_type' says 'Type of analysis to perform (general, code, patterns, architecture)' but does not explain: (1) the difference between 'general' and 'patterns', (2) when to choose each, (3) what output changes per type. Per pattern, descriptions must be actionable.
No error handling guidance. Tools do not document what errors can occur, which are retryable, how to recover, or what the LLM should do next. 'test_connection' might fail (network down, server unavailable) but the tool offers no recovery hint. Per the recovery-guide pattern, errors must be actionable.
Tool naming ambiguity: 'heartbeat' and 'test_connection' appear to be infrastructure/diagnostics tools, not user-facing semantic analysis tools. They dilute the tool roster and suggest this server is solving infrastructure plumbing instead of the stated domain (semantic analysis). Per the pattern, each tool should represent a clear user intent.
Input schema for 'determine_insights' lacks enum constraints for the 'analysis_type' parameter. It allows any string, inviting hallucinated values like 'behavioral' or 'statistical' that are not valid. Per constrained-input pattern, known-set parameters MUST be enums.