Giving Claude Direct Access to Quantum Hardware

One of the most powerful ideas in the AI-for-science movement is closing the feedback loop — giving AI agents direct access to experimental tools so they can design, execute, and analyze experiments without human intermediation. We just took a concrete step toward this for quantum computing.

We built two MCP servers (Model Context Protocol) that give Claude Code — the AI coding agent — direct access to quantum resources:

1. QRNG MCP Server — True quantum random numbers from the ANU Quantum Random Number Generator
2. QI Circuit MCP Server — Submit cQASM 3.0 circuits to Quantum Inspire hardware and emulators

Together with Claude Code itself acting as a quantum research assistant, this creates a pipeline where an AI agent can design a quantum experiment, execute it on real hardware, and analyze the results — all within a single conversation.

What is MCP?

The Model Context Protocol (MCP) is an open standard from Anthropic that lets AI assistants use external tools. Think of it as a USB port for AI — a standardized way to plug in capabilities. An MCP server exposes "tools" (functions with typed inputs and outputs) that the AI can call during a conversation.

For quantum computing, this means we can give Claude the ability to:

• List available quantum backends and their qubit counts
• Submit circuits to real quantum processors
• Check job status and retrieve measurement results
• Run circuits locally on an emulator for rapid iteration
• Generate true quantum random numbers

The AI doesn't just write code that calls these APIs — it calls them directly as tools, getting structured results back in real time.

Server 1: Quantum Random Numbers (with Tuna-9 Fallback)

Our QRNG MCP server provides true quantum random numbers with automatic fallback across three quantum sources:

1. ANU QRNG (primary) — Measures vacuum fluctuations of the electromagnetic field at the Australian National University. Optical quantum source, ~200ms latency.
2. QI Tuna-9 (fallback) — Applies Hadamard gates to superconducting transmon qubits on real quantum hardware at TU Delft, then measures. Each measurement collapses a superposition into a truly random bit. ~3 second latency.
3. qxelarator (last resort) — Local quantum circuit emulator. Instant but pseudorandom.

When the ANU API is unavailable (which happens — we observed intermittent 500 errors during testing), the server automatically submits an 8-qubit Hadamard circuit to Tuna-9. Each shot produces one random byte from real superconducting qubit measurements in a Dutch lab. This is a textbook quantum random number generator, just running on actual hardware instead of a classroom whiteboard.

The server exposes five tools:

Tool	Description
quantum_random_int	Get quantum random integers (uint8 or uint16)
quantum_coin_flip	Flip quantum coins (each derived from true quantum measurement)
quantum_random_hex	Generate quantum random hex strings (for tokens, UUIDs)
quantum_dice_roll	Roll quantum dice with any number of sides
quantum_random_float	Get quantum random floats between 0 and 1

Every response includes a source field so you always know which quantum system generated your random numbers. In our testing, we compared all three sources on identical requests — the distributions are uniform across the board, but the Tuna-9 numbers come from actual superconducting transmon measurements rather than photon detection.

Why two quantum sources?

The ANU QRNG and Tuna-9 use fundamentally different quantum phenomena: optical vacuum fluctuations vs. superconducting transmon superposition. Having both available means the QRNG server is resilient to outages on either platform, and researchers can compare randomness from different physical sources — which matters for foundations-of-physics experiments.

Server 2: Quantum Inspire Circuit Execution

The second server is more ambitious. It connects to Quantum Inspire — the quantum computing platform operated by QuTech at TU Delft — and exposes five tools for circuit execution:

Tool	Description
qi_list_backends	List available QI backends with qubit counts and status
qi_submit_circuit	Submit a cQASM 3.0 circuit to remote hardware (returns job_id)
qi_check_job	Check job status (PLANNED / RUNNING / COMPLETED / FAILED)
qi_get_results	Get measurement results for a completed job
qi_run_local	Run a circuit on the local qxelarator emulator (instant, no queue)

This is a Python server (the QI SDK is Python-only) built with the MCP Python SDK's FastMCP framework. It reuses the existing Quantum Inspire authentication from qi login.

The workflow

A typical interaction looks like this:

1. Design: Claude writes a cQASM 3.0 circuit based on the research question
2. Test locally: qi_run_local runs it instantly on the emulator — Claude checks the results make sense
3. Submit to hardware: qi_submit_circuit sends it to a real quantum processor (e.g., Tuna-9 with 9 superconducting qubits)
4. Monitor: qi_check_job polls for completion
5. Analyze: qi_get_results retrieves the measurement histogram, Claude analyzes noise, fidelity, and whether the results match theory

The key design decision: remote jobs are asynchronous. qi_submit_circuit returns a job ID immediately rather than blocking. Quantum hardware has queues — jobs can take seconds to hours. The async pattern lets Claude continue working while waiting, or batch multiple circuits and check them later.

Local emulation via qi_run_local is synchronous — results come back instantly. This enables a fast inner loop: iterate on circuit design locally, then submit the final version to hardware.

Example: Bell state on the emulator

Here's what Claude sees when it runs a Bell state circuit locally:

// Claude calls qi_run_local with:
circuit = """version 3.0
qubit[2] q
bit[2] b
H q[0]
CNOT q[0], q[1]
b = measure q"""

// Response:
{
  "results": {"00": 0.5, "11": 0.5},
  "shots_requested": 1024,
  "shots_done": 1024,
  "backend": "qxelarator (local emulator)"
}

Perfect Bell state — equal superposition of |00⟩ and |11⟩, no |01⟩ or |10⟩. On real hardware, you'd see noise: small counts in the "wrong" bitstrings, reflecting gate errors and decoherence.

Claude Code as a Quantum Research Skill

The MCP servers are tools. But the real power comes from Claude Code itself acting as a quantum research agent. In a single conversation, Claude can:

• Read papers and extract circuit designs, Hamiltonians, and experimental parameters
• Write circuits in cQASM 3.0 (or Qiskit/PennyLane for simulation)
• Test circuits on the local emulator via MCP
• Submit to hardware via MCP and analyze real measurement results
• Compare theory vs. experiment — calculate expected vs. observed fidelities
• Write up results with proper analysis and visualization

We've already demonstrated this capability: Claude replicated a QuTech VQE paper from a reference alone, writing 300 lines of simulation code. With the MCP servers, the next step is executing those circuits on actual quantum hardware — closing the loop from paper to hardware result.

How This Connects to the AI x Quantum Thesis

Our agent architecture is designed around a core insight: quantum computing experiments are inherently digital. Unlike chemistry or biology, there's no wet lab — you design a circuit, submit it through an API, and get measurement data back. This makes quantum computing uniquely suited to AI-driven research.

The MCP servers are the bridge between AI capability and quantum hardware access. They transform Claude from a code-writing assistant into a quantum experimentalist — one that can run experiments 24/7, systematically explore parameter spaces, and never forget a result.

The feedback loop looks like this:

1. Literature intelligence identifies an interesting experiment
2. AI agent designs the circuit and parameters
3. MCP tools execute on quantum hardware
4. AI agent analyzes results and decides what to try next
5. Repeat

This is the same pattern as self-driving laboratories in chemistry and biology — but quantum computing can move faster because the entire workflow is software.

Technical Details

Architecture

Both servers are Python using the MCP Python SDK's FastMCP framework, communicating via stdio transport (JSON-RPC over stdin/stdout). The QRNG server was originally Node.js but was rewritten in Python to share the QI SDK for Tuna-9 fallback. Configuration lives in .mcp.json at the project root:

{
  "mcpServers": {
    "qrng": {
      "command": "python",
      "args": ["mcp-servers/qrng/qrng_server.py"]
    },
    "qi-circuits": {
      "command": "python",
      "args": ["mcp-servers/qi-circuits/qi_server.py"]
    }
  }
}

Authentication

Both servers reuse the OAuth token from qi login (stored in ~/.quantuminspire/config.json) for Quantum Inspire access. The QRNG server's ANU endpoint needs no auth. The Tuna-9 fallback only initializes the QI backend on first use (lazy loading), so if you only have ANU access, the server works fine without QI credentials.

Error handling & fallback

All tools return structured JSON with error details on failure. The QRNG server's fallback chain (ANU → Tuna-9 → local emulator) is automatic — each source is tried in order, and the response always reports which source was used. Backend initialization is lazy, so startup is fast.

What's Next

The roadmap includes:

1. IBM Quantum MCP Server — Same pattern for IBM's quantum hardware (ibm_torino, ibm_fez, ibm_marrakesh). We already have IBM credentials configured.
2. Autonomous experiment loops — Claude designs, submits, analyzes, and iterates without human prompting. VQE parameter optimization is the first target.
3. Circuit optimization tool — An MCP tool that transpiles circuits for specific hardware topologies before submission.
4. Multi-backend comparison — Run the same logical circuit on QI and IBM hardware, compare noise profiles automatically.

The goal: a quantum research agent that can operate at the speed of the hardware itself, running experiments around the clock while maintaining rigorous experimental methodology.

All code is open source: github.com/JDerekLomas/quantuminspire/tree/main/mcp-servers