Skip to main content
Glama

WAI Quantum job service

Plan a quantum job or set without running it

dry_run_quantum_job
Read-only

What the service would do with a job or a set, running nothing: the method and why, the memory, the estimated time and energy (each with its basis: this service's own timings and readings where it has them, otherwise the planner's nominal rate, and no energy figure without readings), the bounds that apply, where you stand against your limits, and whether the service would take it now, or the refusal it would give, with its code. Takes what run_quantum_circuit or run_quantum_set takes. It counts as one submission.

Input Schema

NameRequiredDescriptionDefault
qasmNoThe 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.
sweepNoEach input of qasm and its values: every combination runs, the names in sorted order, the first varying slowest; an integer input's values are whole numbers.
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.
programsNoThe set's programs: each a program's text, or a job ({"qasm", …}) whose own fields win over the set's.
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?

Consistent with readOnlyHint=true and goes far beyond it: 'It counts as one submission' is a quota consequence an agent must know, plus disclosure of what figures are reported, when energy is omitted, and that refusals come back with a code. Ancillary siblings (qasm_diagnostics, list_targets) are named for follow-up.

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?

Front-loaded with the key property ('running nothing') and then the payoff list. It is one dense block rather than a long paragraph of filler, and every clause carries content, though the nested enumerated list strains readability slightly.

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?

Output schema exists, so return values need not be explained, yet the description still summarizes them. It covers cost, scope, and the failure mode (refusal with code). It leaves the mitigate/compile interplay to the schema, which is reasonable given how richly documented the schema is.

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 per-parameter meaning. The description adds only the cross-tool equivalence ('takes what run_quantum_circuit or run_quantum_set takes'), which is useful orientation but not parameter-level detail. Baseline 3.

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?

States a specific verb and resource: what the service *would* do with a job or set, 'running nothing'. Explicitly ties its input shape to run_quantum_circuit and run_quantum_set, making it distinguishable from the siblings that actually run.

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 enumerated outputs (method, memory, estimated time/energy, bounds, limit standing, acceptance or refusal) make the use case clear: previewing feasibility before committing. It stops short of an explicit 'use this instead of run_quantum_circuit when...' exclusion, so a small inference remains.

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