An MCP server that provides quantum circuit creation, manipulation, execution, and visualization tools powered by Qiskit.
The server has 6 well-named tools with explicit descriptions and input schemas, but critical gaps prevent a higher score. All tools are registered via @mcp.tool() decorator with names, descriptions, and input schemas visible in main.py. However: (1) Output schemas are NOT documented, none of the tool docstrings specify what fields the returned JSON contains, forcing LLMs to infer structure; (2) several parameter descriptions are generic or incomplete (e.g., 'gates' parameter says 'List of gate operations, each with type and qubits keys' but doesn't specify which gate types, constraints, or what classical_bit means); (3) no error handling guidance, functions return bare error strings like 'Circuit not found' without actionable recovery instructions; (4) parameter descriptions lack detail on ranges, constraints, or formats (e.g., 'shots' has no guidance on min/max values, though typical values are 1 - 4096); (5) no documentation of which tools support pagination or limits. The naming is solid (verb-noun pattern), and core schemas are present, but incomplete parameter descriptions and missing output schemas prevent higher scores.
Add quantum gates to a circuit. Args: circuit_name: Name of the circuit to modify gates: List of gate operations, each with 'type' and 'qubits' keys Supported gates: 'h', 'x', 'y', 'z', 'cx', 'measure', 'measure_all' Returns: Success message with applied gates
Create a new quantum circuit with auto-generated unique name. Args: num_qubits: Number of quantum bits (must be an integer) num_classical_bits: Number of classical bits (must be an integer, defaults to num_qubits if not provided) name: Optional custom name for the circuit (auto-generated if not provided) Returns: Success message with circuit details and generated name
Get information about a quantum circuit. Args: circuit_name: Name of the circuit Returns: JSON string with circuit information
Run a quantum circuit on the simulator. Args: circuit_name: Name of the circuit to run shots: Number of measurement shots Returns: JSON string with measurement results
Get a text visualization of the quantum circuit. Args: circuit_name: Name of the circuit to visualize Returns: Text representation of the circuit
Output schemas are completely undocumented. None of the 6 tools describe what fields or types they return. LLMs cannot plan downstream tool calls or extract required data from responses.
Parameter descriptions lack actionable constraints. 'shots' (run_circuit) has no min/max guidance; 'gates' (add_gates) doesn't specify valid enum values for 'type' or qubit cardinality; 'num_qubits' and 'num_classical_bits' don't reject negative values or document upper bounds.
Error handling provides no recovery guidance. Error responses are bare strings ('Circuit not found', 'Unsupported gate type') without actionable next steps or available alternatives. LLMs have nothing to retry or fix.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 16 | - | v1 |
Generate a Mermaid flowchart diagram of the quantum circuit. Args: circuit_name: Name of the circuit to visualize Returns: Mermaid flowchart syntax representing the quantum circuit
The 'gates' parameter in add_gates uses an array of objects with untyped properties. The schema shows 'type' and 'qubits' as properties but doesn't enforce enum values for 'type' (should enumerate: h, x, y, z, cx, measure, measure_all) or constrain 'qubits' cardinality (single-qubit gates need 1 qubit; cx needs 2).
No tool composition guidance. Tools return success strings that don't include circuit_name or other chaining IDs needed by subsequent tools. For example, create_quantum_circuit returns a success message, but if the LLM needs to pass the circuit name to add_gates, it must parse the message or remember the name from context.
No distinction between read-only and destructive tools in descriptions or via tool annotations. All tools marked with static 'Risk' labels in metadata, but no idempotentHint, readOnlyHint, or destructiveHint annotations visible in the @mcp.tool() definitions.