Loading ToolBench
Convert quantum circuits to ZX-diagrams using categorical quantum mechanics. Provides circuit analysis, optimization strategy selection, ZX-diagram conversion, and educational visualization.
Server has 11 tools with consistent naming (verb_noun pattern: list_, get_, parse_, analyze_, convert_, recommend_, generate_), but descriptions are generic and parameter schemas lack depth. Most tools are read-only information retrieval with minimal input validation. Tool descriptions average ~80-120 characters, below the 194-char baseline for A+ tools. Input schemas present but minimal: most parameters are single strings with generic descriptions like 'OpenQASM 2.0 circuit code' repeated across 6 different tools. No output schemas documented. No error handling guidance (tools return bare JSON errors). Parameter descriptions lack constraints, format hints, or dependency information. Tool #10 (explain_zx_diagram_transformation) explicitly claims 'Layer 4 tool that can accept Claude synthesis' but no formal composition pattern or multi-round-trip request support visible.
Analyze circuit properties and optimization potential.
Get detailed gate composition breakdown.
Convert quantum circuit to ZX-diagram representation.
Generate explanation of transformation between two circuits. This is a Layer 4 tool that can accept Claude synthesis.
Generate markdown documentation of ZX-diagram with visualization instructions.
Get the ZX-diagram representation of a quantum gate.
Get quantum measurement basis definition.
Identical parameter schema repeated across 6 tools with no differentiation. Tools 3-7 all accept 'qasm_code: string' with identical description 'OpenQASM 2.0 circuit code', making it impossible for LLMs to distinguish when to call parse vs analyze vs convert vs recommend. This violates the 'clear tool distinction' principle.
No output schemas documented anywhere. Tools return JSON strings (json.dumps()) but callers have no machine-readable schema of what fields to expect. Violates 'document output schema' rule from pattern:tool. LLMs must parse unstructured JSON from returned strings.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Get reference guide for ZX-calculus rewrite rules.
List all supported quantum gates with their properties.
Parse an OpenQASM 2.0 quantum circuit.
Recommend ZX-calculus optimization strategy based on circuit.
Parameter descriptions are under 20 chars or generic. 'Name of the gate (e.g., h, cx, t)' for get_gate_zx_representation; 'OpenQASM 2.0 circuit code' repeated 6 times across similar tools. These fail to explain WHEN to use each tool or what distinguishes their outputs.
No error handling or recovery guidance. All tools return raw JSON errors like '{"error": "Failed to parse circuit"}' or '{"error": "Gate 'x' not found"}'. Per pattern:recovery-guide, errors must tell the LLM what to do next. Should return 'Gate 'h' not found. Call list_quantum_gates() to see available gates.'
No input validation or constraint documentation. recommend_optimization_strategy accepts 'desired_outcome' parameter but does not validate enum values ['balanced', 'clifford_simplification', 't_count_reduction', 'measurement_based', 'educational']. If LLM passes 'foo', tool silently defaults to 'balanced' with no error. Per pattern:constrained-input, enum constraints must be explicit.
Tool composition not supported. Tool #10 (explain_zx_diagram_transformation) claims 'Layer 4 tool that can accept Claude synthesis' but no multi-round-trip request (result 'input_required') mechanism visible in code. No MRTR support to ask user for intermediate input or clarification.
Parameter type suffixes missing. 'gate_name' is ambiguous, could be 'h' or 'hadamard' or a numeric ID. Per naming baseline 'user_id' vs 'user_name', this tool should expose both 'gate_name' and 'gate_symbol' to match how users refer to gates. Currently assumes one naming convention.