Skip to main content
Glama

WAI Quantum job service

Run a quantum circuit

run_quantum_circuit
Idempotent

Run an OpenQASM program and return measurement counts, Pauli expectation values and/or amplitudes. The service chooses the method (bit-exact or double-precision state vector up to 32 qubits, single precision on a GPU to 33, stabilizer tableau for Clifford circuits up to 32768 qubits, matrix product states up to 4096, sparse Pauli dynamics for expectation values up to 1024 with an error bound, an exact density matrix or trajectories for noise), reports why and how accurate, and signs the result. Give intent (an exact distribution, or a reference program it must equal or whose state it must prepare) and the engine checks it with the run. Every answer carries verdict: the level the engine checked to (proof, evidence, executed, parsed, refused), whether the intent holds and a plain statement, sealed in the receipt. Waits up to 50 s; a longer job answers with status running and an id for get_quantum_job.

Input Schema

NameRequiredDescriptionDefault
qasmYesThe program, OpenQASM 3 (or 2), read as the whole language: registers, aliases and slices; the standard gates, `U` and `gphase`; user `gate` definitions and `def` subroutines, inlined; every modifier (`ctrl @`, `negctrl @`, `inv @`, `pow(k) @`) on any gate, lowered exactly; classical types (int, uint, float, angle, complex, bool, bit, arrays), their arithmetic and built-in functions, computed on reading; `for`, `while`, `switch`, `break`, `continue`; measurement and `reset` anywhere; classical control on measured bits (`if (c[0]) x q[1];`, `if (c >= 2) { … } else { … }`, `&&`, `||`); a `while` on measured bits takes `@wai.max_iterations N` before it. `output` declarations come back in the result; `delay`, `box` and `stretch` are carried and labelled as not applied; `defcal` and `cal` are kept, not run. A program that measures in the middle or acts on what it measured runs on statevector or stabilizer: counts split their shots at each measurement; expectation values are exact, of the state before the final measurements. What the reader refuses comes back with a code, as `[Q103]`; qasm_diagnostics says what each code means.
seedNoSampling seed (default 1); the same job and seed give the same counts.
noiseNoOptional noise, each a probability: depolarizing_1q, depolarizing_2q, amplitude_damping, dephasing (after each gate on its qubits), readout (each measured bit).
shotsNoMeasurement shots. Default 1024 when no observables or amplitudes are asked for.
intentNoWhat the program must do, checked by the engine with the run: the result's `verdict` states how far it checked (proof, evidence, executed, parsed, refused) and whether the intent holds, sealed by the receipt.
methodNoLeave as auto unless you need a particular method.
repairNoRepair the program first, on the lines its diagnostics flag alone (as repair_qasm does): true, or the choices {"max_iterations": N, "dyadic_bits": K, "sizes": {"q": 3}}. The result's `repaired` holds the program that ran and each repair.
targetNoA device target: a built-in target's name (list_targets) or a target document (wai.quantum.target/1). The program is then compiled to its gates, placed where it is most likely to succeed and simulated under its noise, its hash in the receipt; not with noise or amplitudes. The service reads the document given and fetches nothing.
compileNoCompile the program first (as compile_qasm does) and run the compiled circuit: with basis clifford_t it runs bit-exact, and the result's `compiled` states its distance from the program.
optionsNoAdvanced, per method: max_bond (mps), threshold and max_terms (pauli), fusion (statevector), trajectories.
mitigateNoMitigate the job's expectation values (or, for readout, its counts) under its own noise: zne (the whole program folded U(U†U)^k and extrapolated), pea (the noise learned as a sparse Pauli–Lindblad model and amplified), pec (the learned channels inverted and sampled), cdr (a line fitted over near-Clifford training circuits), vd (two copies), readout (the counts' flips inverted). Needs noise and observables (shots for readout), at most 8 qubits. The result's `mitigation` gives raw and mitigated values with standard errors, the ideal value (known because this is a simulation), the method's bias and variance assumptions and its cost. A method's name, or an object.
amplitudesNoBasis states to give amplitudes of: one character per qubit, qubit n-1 first, e.g. "0011".
observablesNoPauli strings to take expectation values of, e.g. ["Z0", "Z0 Z1", "X2 Y3"]. Qubits count from 0.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are minimal (readOnly=false, idempotent=true, openWorld=false), and the description carries the real burden: it discloses automatic method selection with qubit ceilings per engine, error bounds for sparse Pauli dynamics, receipt signing, the meaning of `verdict` levels (proof/evidence/executed/parsed/refused), the 50 s timeout behavior, the 8-qubit limit for mitigation, and that `target` runs under device noise but not with amplitudes. That is exactly the beyond-annotations context this dimension rewards.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The most important facts (what it runs, what comes back, the timeout escape hatch) are front-loaded in the first and last sentences. The middle is information-dense but written as very long run-on clauses separated by commas, which costs readability for a 13-parameter tool; little of the content is padding, though.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description still volunteers the parts an agent needs to interpret results that the schema alone would not convey — verdict levels, the receipt, and the repair/compile/mitigation sub-results. For a tool this complex, nothing an agent needs in order to call it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics the schema does not: what `intent` means operationally (engine checks it with the run, sealed in the receipt), why `method` should stay auto, and how `repair`/`compile`/`mitigate`/`target` alter the job. It stops short of explaining parameter interactions (e.g. noise + target exclusivity is stated only inside the schema for `target`).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb+resource and enumerates the three return kinds (counts, Pauli expectation values, amplitudes). It goes on to name sibling tools it hands off to (get_quantum_job for long jobs, qasm_diagnostics for codes, repair_qasm/compile_qasm for its repair/compile modes), so an agent can place it in the toolset without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes clearly on several conditions: the 50 s wait then `status: running` plus an id for get_quantum_job, use repair_qasm-style repair via the `repair` flag, use compile_qasm via `compile`, and 'leave as auto unless you need a particular method.' What is missing is explicit guidance against siblings that overlap, notably run_on_target (since `target` here already compiles to a device) and run_quantum_set / dry_run_quantum_job.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources