Quantum Expectations

Compute Quantum Expectation

compute_expectation

Read-onlyIdempotent

Given a quantum circuit (2-qubit error rate p, qubit count n, depth d, optional connectivity class), compute the effective error rate, success probability, and optional surface-code or qLDPC overhead. Without error correction a 2d-lattice connectivity is charged as a routing multiplier on depth (result.routingOverheadFactor); hardwareId supplies the device's class automatically. The response is self-describing (formulas, assumptions, caveats, glossary, SOTA hardware, historic series with source URLs) so an agent can reason from one call. For the inverse ("what hardware do I need?") use compute_required_error_rate; to rank multiple platforms in one call use compare_hardware_scenarios.

Input Schema

TableJSON Schema

Name	Required	Description
`verbose`	No	When false, omits hardwareContext, formulas, assumptions, caveats, glossary, examples, and exampleProblems from the response — leaving only modelVersion, scenario, and result. Use for parameter sweeps where that context would repeat unchanged.
`compDepth`	Yes
`numQubits`	Yes
`hardwareId`	No	Alias for qubitErrorRate: resolves to the 2-qubit error rate of the given SOTA hardware entry from list_current_quantum_computers. Supply exactly one of qubitErrorRate or hardwareId.
`connectivity`	No	Two-qubit connectivity of the device: "all-to-all" (ion transport), "reconfigurable" (atom shuttling, treated as all-to-all) or "2d-lattice" (fixed nearest-neighbour couplers, charged as a routing multiplier on depth in the no-EC path). Defaults to the hardware entry's class when hardwareId is supplied, else to all-to-all.
`qubitErrorRate`	No	Per-gate 2-qubit error rate p, in (0, 0.1]. Supply exactly one of qubitErrorRate or hardwareId.
`useErrorCorrection`	No
`distanceSurfaceCode`	No	Surface code distance: odd integer in [3, 31]. Required when useErrorCorrection=true and the surface code is selected; ignored when a qLDPC code is selected.
`errorCorrectionCode`	No	Either "surface" (default when useErrorCorrection=true) or a qLDPC code id from list_qldpc_codes. "surface-code" is accepted as an alias for "surface".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 16, 2026

addedInput schema / properties / connectivity

Added value: +{
+  "description": "Two-qubit connectivity of the device: \"all-to-all\" (ion transport), \"reconfigurable\" (atom shuttling, treated as all-to-all) or \"2d-lattice\" (fixed nearest-neighbour couplers, charged as a routing multiplier on depth in the no-EC path). Defaults to the hardware entry's class when hardwareId is supplied, else to all-to-all.",
+  "enum": [
+    "all-to-all",
+    "reconfigurable",
+    "2d-lattice"
+  ],
+  "type": "string"
+}

Changed4 schema fields changedSep 2, 2026
- addedInput schema / properties / distanceSurfaceCode / description
```
Added value: +"Surface code distance: odd integer in [3, 31]. Required when useErrorCorrection=true and the surface code is selected; ignored when a qLDPC code is selected."
```
- removedInput schema / properties / distanceSurfaceCode / maximum
```
Removed value: -31
```
- removedInput schema / properties / distanceSurfaceCode / minimum
```
Removed value: -3
```
- changedInput schema / properties / distanceSurfaceCode / type
```
Previous value: -"integer"New value: +"number"
```

Changed1 schema field changedAug 20, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedJul 2, 2026

addedInput schema / properties / errorCorrectionCode / description

Added value: +"Either \"surface\" (default when useErrorCorrection=true) or a qLDPC code id from list_qldpc_codes. \"surface-code\" is accepted as an alias for \"surface\"."

First observedJul 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds valuable behavioral context: the response is self-describing (formulas, assumptions, caveats, glossary, SOTA hardware, historic series with URLs), and it discloses the routingOverheadFactor for 2d-lattice connectivity in the no-EC path. This goes beyond annotations to inform the agent about output richness and calculation specifics.

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

Conciseness5/5

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

The description is a single well-structured paragraph that front-loads the core purpose, then adds essential behavioral details and sibling pointers. Every sentence earns its place: no fluff, no redundancy. It is concise given the tool's complexity.

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?

Despite no output schema, the description explicitly states what the response contains (effective error rate, success probability, overhead, self-describing context). It covers input relationships, error correction optionality, and routing behavior. For a 9-parameter tool with 2 required and enums, this is remarkably complete.

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 67% (some params have descriptions, but numQubits and compDepth lack them). The description compensates by naming them as 'qubit count n, depth d', and clarifies the relationship between hardwareId and qubitErrorRate (exactly one supplied), connectivity defaults, and the routing multiplier effect. It adds meaning beyond the schema for key parameters, though it doesn't detail every param individually.

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 ('compute') and resource ('effective error rate, success probability, and optional overhead') for a quantum circuit. It explicitly differentiates from siblings by naming compute_required_error_rate for the inverse and compare_hardware_scenarios for ranking, leaving no ambiguity about scope.

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

Usage Guidelines5/5

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

It clearly explains when to use this tool: given a circuit with error rate, qubit count, depth, and connectivity. It also gives explicit alternatives: use compute_required_error_rate for the inverse question and compare_hardware_scenarios to rank platforms. The routing overhead behavior and hardwareId default are stated, giving agents a full usage picture.

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

All Quantum Expectations 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?