Skip to main content
Glama

WAI Quantum job service

Write a quantum program for a task

write_circuit

Have the service's own model write an OpenQASM 3 program for a task, the engine checking each attempt against what the task asks exactly as it checks a lesson's answer, and what went wrong going back to the model for another attempt, up to rounds repairs. The task is an exercise in the course's form (wai.quantum.exercise/1): a title and task in words, an optional starter program, and what the program must do, as an intent (an exact distribution, a reference program it must equal or whose state it must prepare) or cases that each have one, with optional constraints (gates allowed, counts, T count, smells), at most 16 cases and 8 intents in one place, its canonical form at most 64 KiB. The answer is a job whose result is the transcript (wai.quantum.write/1): the model by name, licence and the digest of its files, every byte checked, and the arithmetic it ran in, the prompt, each attempt's program and the engine's check, and whether one passed and at what level, signed (verify_quantum_receipt checks it with the job's request). Decoding is greedy, so the same task gives the same transcript in the same arithmetic (architecture, operating system, maths library, matmul kernel). Writes take minutes and run one at a time; a client holds one queued or running write. Call it as a task, or it waits 50 s and answers with status running and an id for get_quantum_job. A service without a model refuses it (J080); quantum_service_info says under write whether this one has one. Each call is a new write unless it gives idempotency_key.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task": "<task>"
    },
    "name": "write_circuit"
  }
}

Input Schema

NameRequiredDescriptionDefault
taskYesThe exercise: {"title", "task", "starter", "intent" or "cases", "constraints", "job"}, as the course's exercises (wai.quantum.exercise/1); title and task may be plain strings. It must give an intent, or cases that each have one (J081).
roundsNoRepairs after the first attempt, each with the engine's account of the last (J082 outside 0 to 4).
max_newNoThe most tokens one reply may take, its thinking included.
idempotency_keyNoA key of your making that names this run, so that a call sent again is not a second job: the same key with the same arguments answers with the job it names, for as long as the job is kept, rather than running another; the same key with other arguments is refused (J034). Make it unguessable (a UUID). A job the service interrupted is run again under its key. Without a key, every call is a new job.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Far beyond the annotations: it discloses runtime ('takes minutes'), concurrency limits (one queued or running write per client), the synchronous timeout-then-job-id fallback, the J080 refusal condition, and greedy-decoding determinism keyed to the arithmetic. It also explains the returned transcript and that verify_quantum_receipt checks the signature, which is exactly the behavioral context a write tool needs.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is a stack of very long compound sentences with tangled syntax ('and what went wrong going back to the model for another attempt'). Nearly all content is substantive, yet the density makes it harder to scan than it needs to be.

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?

Given a nested task object, an output schema for the transcript, and a genuinely complex asynchronous write flow, the description covers timing, failure modes, determinism, verification and concurrency. Nothing an agent needs in order to call this correctly appears to be missing.

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 prose adds limits the schema does not carry: at most 16 cases and 8 intents, 64 KiB canonical form, and the repair semantics of `rounds`. It also explains the idempotency_key retry contract (same key + same args returns the existing job, different args refused with J034) in more operational detail than the schema.

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 clause states a specific verb, resource and producer: 'Have the service's own model write an OpenQASM 3 program for a task', and immediately adds that the engine checks it against the task. That distinguishes it from siblings like critique_qasm or repair_qasm, which operate on programs the caller already has.

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 gives clear operating context: call it as a task, expect a 50 s wait that returns status running plus a job id for get_quantum_job, and check quantum_service_info under `write` because a model-less service refuses with J080. It does not explicitly contrast when to use this versus improving or critiquing an existing program, so the alternative guidance is implicit rather than stated.

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