Quantum Expectations

Compute Quantum Volume Rate

compute_quantum_volume_rate

Read-onlyIdempotent

Compute the Quantum Volume Rate (QV/second): QVR = V_Q / (log2(V_Q) * t_2Q + t_meas). First-order estimate of how fast a device prepares one QV-sized square circuit (one native 2Q gate per QV layer + one end-of-circuit measurement). OVERSTATES achievable rate: real compilation inflates the 2Q-gate count per layer; omits reset/SPAM, mid-circuit measurement, and classical-control latency. For a production throughput metric, see IBM's CLOPS (arXiv:2110.14108).

Input Schema

Name	Required	Description
`t2QSeconds`	Yes	Native 2-qubit gate time in seconds (e.g. 60e-9 for a 60 ns CZ).
`quantumVolume`	Yes	Quantum volume V_Q (integer ≥ 2, e.g. 64 for a depth-log2=6 square circuit).
`tMeasurementSeconds`	Yes	End-of-circuit measurement/readout time in seconds (e.g. 5e-3 for 5 ms).

Output Schema

Name	Required	Description	Default
`unit`	Yes
`inputs`	Yes
`caveats`	Yes
`formula`	Yes
`assumptions`	Yes
`qvrPerSecond`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "assumptions": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "caveats": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "formula": {
+      "type": "string"
+    },
+    "inputs": {
+      "additionalProperties": {},
+      "properties": {
+        "quantumVolume": {
+          "type": "number"
+        },
+        "t2QSeconds": {
+          "type": "number"
+        },
+        "tMeasurementSeconds": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "quantumVolume",
+        "t2QSeconds",
+        "tMeasurementSeconds"
+      ],
+      "type": "object"
+    },
+    "qvrPerSecond": {
+      "type": "number"
+    },
+    "unit": {
+      "const": "QV/s",
+      "type": "string"
+    }
+  },
+  "required": [
+    "qvrPerSecond",
+    "unit",
+    "formula",
+    "inputs",
+    "assumptions",
+    "caveats"
+  ],
+  "type": "object"
+}

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"

First observedJul 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantive model limitations: it 'OVERSTATES achievable rate', compilation inflates 2Q-gate count per layer, and it omits reset/SPAM, mid-circuit measurement, and classical-control latency. That is exactly the kind of accuracy caveat an agent needs before presenting the number as authoritative.

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-loads the formula and definition, then the caveats in descending importance, with zero filler sentences. The caveat block is dense but each clause (compilation inflation, omitted latencies, CLOPS pointer) carries distinct decision-relevant information; slightly tighter phrasing could improve skimming.

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?

For a pure-math computation with a full output schema, 100% parameter documentation, and rich annotations, the description supplies everything an agent needs: the formula, the physical interpretation, the accuracy direction of the error, and an escalation path for production metrics.

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 would be 3, but the formula adds genuine meaning: it shows how quantumVolume, t2QSeconds, and tMeasurementSeconds combine, including that log2(V_Q) sets the layer count. Units and example magnitudes live in the schema rather than the description, which is acceptable given full coverage.

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 (compute) plus a precisely named metric and gives the exact formula QVR = V_Q / (log2(V_Q) * t_2Q + t_meas), so an agent knows exactly what is produced. The parenthetical defining 'one QV-sized square circuit (one native 2Q gate per QV layer + one end-of-circuit measurement)' removes ambiguity about what is being estimated.

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?

Explicitly scopes the tool as a 'first-order estimate' and redirects agents wanting a production throughput metric to IBM's CLOPS with a citation. It does not name any of the sibling MCP tools (e.g. compare_hardware_scenarios, compute_expectation) as alternatives, so routing among in-server tools is left to inference.

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?