Skip to main content
Glama

WAI Quantum job service

Run a program as a device would

run_on_target
Idempotent

Run an OpenQASM program as it would run on a device target: compiled exactly to its gates, placed on its most reliable qubits and routes (the expected success given), checked against the circuit, and simulated under the noise its calibration gives, on the density matrix or by trajectories. Counts and expectation values with their distance from the ideal distribution, the noise derived, and a receipt that binds the target's hash. A model of the device, not a run on it. Every angle must be a dyadic multiple of 2π. Waits up to 50 s, as run_quantum_circuit does.

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.
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.
targetYesA 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.3/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that this is a simulation model of the device, not a hardware run; that it compiles, places, checks, and simulates under calibration noise; that results include counts, expectation values, noise, and a receipt bound to the target hash. It also adds practical constraints: every angle must be a dyadic multiple of 2π, and the call waits up to 50 seconds.

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 description is front-loaded with the core operation and the key distinction from a real device run. It is dense and somewhat long-sentenced, but nearly every clause adds useful behavioral or constraint information.

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

Completeness4/5

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

For a complex 12-parameter tool with an output schema and rich annotations, the description covers the core behavior, simulation model, noise, receipt, and key constraints. It is nearly complete, though explicit routing against run_quantum_circuit and other siblings is only implied.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already carries most parameter semantics. The description adds the important dyadic-angle constraint for qasm, but it does not add meaning for most of the 12 parameters such as intent, repair, compile, mitigate, options, or observables beyond what the schema provides.

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 description states a specific verb and resource: run an OpenQASM program as it would run on a device target, with compilation, placement, noise simulation, counts, expectation values, and a receipt. It distinguishes itself from a real hardware run and references run_quantum_circuit, so the agent can identify the tool without opening the 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?

The context is clear: use this when you want a simulated device-target run rather than a real run, and the target parameter points to list_targets for built-in targets. It does not explicitly say when to prefer run_quantum_circuit or another sibling, but the intended context is clear.

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