WAI Quantum job service

Convert a program between formats

convert_program

Read-only

Carry a program between OpenQASM 3, QIR (LLVM text, read under its base and adaptive profiles, written as QIR 2.0) and jeff (its Cap'n Proto message, as base64). The answer is the program written, the program as OpenQASM 3 (what every other tool takes), each note with its code (a rotation at an arbitrary angle, a custom gate read by its name, what a format leaves out), what was read and written, and the check: the output read back and held to the program by the equivalence ladder. A construct a reader cannot hold exactly is refused with its code (Q700 to Q721) and its place: quote the code, and never guess around it. A conversion larger than the service takes is refused with the command that runs it locally.

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": {
      "to": "<to>"
    },
    "name": "convert_program"
  }
}

Input Schema

Name	Required	Description
`to`	Yes	The format to write.
`from`	No	Its format; found from its bytes when not given.
`check`	No	false: write it without the check.
`profile`	No	QIR's profile to write: by default base when the program's measurements all come at the end, else adaptive.
`program`	No	The program's text: OpenQASM or QIR.
`program_base64`	No	The program's bytes as base64: jeff.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond readOnlyHint=true, the description discloses the output bundle, embedded equivalence check, note codes, refusal behavior for unsupported constructs with Q700-Q721 codes, and the refusal path for oversized conversions. This is rich behavioral context that goes well past what the annotations provide.

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 conversion purpose and then adds output, check, and refusal details. It is slightly dense and run-on in places, but for a complex conversion tool most sentences carry useful information.

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 the output schema exists, the description does not need to enumerate return fields, yet it still explains the returned program, QASM representation, notes, check results, and refusal modes. Combined with full schema coverage and read-only annotations, it is complete enough for correct invocation.

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 documents all six parameters, including enums and defaults. The description adds useful format-level context, especially around QIR profiles and jeff base64 representation, but the parameter-level burden is largely handled by the schema.

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 description states a specific verb and resource: carry a program between OpenQASM 3, QIR, and jeff. It names the formats precisely, making the tool's role clear, but it does not explicitly contrast itself with siblings such as compile_qasm or check_equivalent.

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

Usage Guidelines3/5

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

Usage is implied by the conversion framing and by the note that OpenQASM 3 is what every other tool takes. However, there is no explicit when-to-use vs when-not-to-use guidance or named alternatives, so an agent must infer the correct context.

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

All WAI Quantum job service tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?