Loading ToolBench
Code Explorer for HLASM with hypothesis-driven code analysis using Neo4j and MCP tools
Inductor exhibits severe quality gaps across naming, descriptions, schemas, and composition. Of 10 tools, 3 have cryptic/nonsensical names ('crcrcrcrcrc', 'breakdown_hypothesis', 'create_evidence_strategy'), most lack meaningful parameter documentation, and none document output schemas. Tool stubs return bare lists without error handling or field documentation. The server appears to be early-stage or incomplete, many tools read as scaffolding (e.g., crcrcrcrcrc and breakdown_hypothesis are identity functions that do nothing). Even production-ready tools like create_hypothesis have deprecated 'confidence' parameters alongside undefined 'belief' internals. Composition is weak: overlapping CRUD operations on hypotheses lack clear distinguishing factors. Schemas are present in JSON form but descriptions are missing from many parameters. This server would not pass production code review.
Breaks down hypotheses into component parts
Processes evidence components (purpose unclear from stub implementation)
Creates an evidence strategy from evidence components
Create a new Hypothesis in Neo4j.
Create a new Hypothesis in Neo4j with detailed subject and object properties.
Delete a hypothesis by its ID.
Find hypotheses matching the given criteria.
Cryptic/nonsensical tool names: 'crcrcrcrcrc' is not a verb_noun pattern and provides zero semantic meaning. LLMs cannot infer intent from this name.
Identity function stubs: Tools like 'crcrcrcrcrc', 'breakdown_hypothesis', and 'create_evidence_strategy' simply return their input unchanged with no actual logic or side effects. These appear to be incomplete scaffolding and provide no value to agents.
Missing parameter descriptions on custom types: Parameters like 'evidence_components: list[Evidence]' and 'hypotheses: list[Hypothesis]' lack explanations of what Evidence and Hypothesis contain, how to construct them, or when to use each. LLMs cannot reason about opaque custom types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Get a hypothesis by its ID.
Simple greeting tool that responds with a personalized hello message.
Update a hypothesis by its ID.
No output schemas documented: All 10 tools lack explicit documentation of what fields they return and their types. Source code snippet shows create_hypothesis returns dict[str, Any] with 'success', 'hypothesis_id', and 'message' fields, but this is not formally documented in the tool definition. Agents must infer response structure.
Deprecated 'confidence' parameter still in use: create_hypothesis and create_hypothesis_with_objects accept a deprecated 'confidence' parameter marked with 'use belief instead', but belief is not exposed as a parameter. The internal implementation uses 'equally_likely()' with no way for an agent to control belief. Ambiguous API design.
Overlapping CRUD operations without clear naming distinction: create_hypothesis vs create_hypothesis_with_objects both create hypotheses but differ in how they accept parameters. Tool names do not make the distinction obvious. An agent must read full descriptions to understand when to use each.
Incomplete source code excerpt: The create_hypothesis_with_objects function snippet cuts off mid-implementation ('objec' at the end). Cannot verify full logic, return type, or error handling. Caps confidence in schema score.
No error guidance or recovery hints: Error handling in create_hypothesis returns {'success': False, 'error': str(e)}, but provides no guidance on what the agent should do next (retry, call a different tool, ask the user). Per the pattern, errors must be actionable.
Ambiguous tool purpose: 'find_hypotheses' accepts many optional filters (subject, relation, object_, min_alpha, max_alpha, etc.) but description does not explain search semantics: Is it AND or OR logic? What happens when no filters match? Does it paginate? Are results sorted?
No pagination support: find_hypotheses can theoretically return unbounded results. No limit, offset, page, or cursor parameters. Large result sets will exhaust context windows and violate result limit baselines (20-50 items recommended).
Parameter type ambiguity on IDs: get_hypothesis, update_hypothesis, and delete_hypothesis accept 'hypothesis_id' as string but provide no format hint (UUID, numeric, etc.). If agents must construct or guess IDs, they lack clarity.