Skip to main content
Glama

WAI Quantum job service

Run a set of quantum programs, or one over a grid

run_quantum_set
Idempotent

Run several OpenQASM programs as one set (programs: each a program's text or a job), or one program over a grid of its inputs (qasm with sweep, as {"theta": [0.1, 0.2], "n": [2, 3]}: every combination; integer inputs written out, float and angle inputs bound to the double given). The set's other fields (shots, observables, seed, intent, …) apply to every item. Each item gets its own result and receipt, each stating its verdict, and one receipt over the set binds every item through a Merkle root; verify_quantum_receipt checks it whole. At most 100 items, run one after another in one job. Waits up to 50 s; a longer set answers with status running and an id for get_quantum_job.

Input Schema

NameRequiredDescriptionDefault
qasmNoWith sweep: the program, which declares the inputs the sweep gives values (`input uint n;`, `input float theta;`, `input angle phi;`).
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

A3.9/5.0
Behavior4/5

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

Annotations only say non-read-only, closed-world and idempotent, while the description adds substantial behaviour: items run sequentially in one job, capped at 100, each with its own result and receipt, all bound by a Merkle root checkable with verify_quantum_receipt, and a timeout that returns status `running` plus a job id. The main remaining gap is what partial output a timed-out call returns.

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?

It is dense but efficient: the two modes are front-loaded and each following sentence adds a distinct operational fact (field propagation, receipts, cap, timeout fallback). Some clauses are heavily parenthetical, but nothing is wasted.

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?

With an output schema present, the description needn't explain return shapes, yet it still covers the important cross-cutting behaviour: item limit, sequential execution, per-item verdicts, Merkle-root aggregation and the running/id handoff for long sets. Adequate for a 15-parameter batch tool; minor gaps are partial-result handling and error semantics.

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 coverage is 100%, so the schema already documents all 15 parameters, including the sweep ordering and program-vs-job field precedence. The description adds only a small amount beyond this (the float/angle binding to a double and the set-field propagation), so the baseline 3 applies.

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

Purpose4/5

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

The opening sentence names a specific verb and resource and separates the two modes (a set of `programs` vs. one `qasm` over a `sweep` grid) with a concrete sweep example. It is clearly distinguished from single-circuit siblings by scope, though it never explicitly names run_quantum_circuit as the single-program alternative.

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 description gives clear context for choosing between the two modes and states the set-level fields apply to every item, plus the 100-item cap and the 50 s wait behaviour. It stops short of explicit when-not guidance or naming the sibling to use for a lone program without a sweep.

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