F
licenseNot graded
qualityA
maintenanceQECTOR Quantum Error Correction: High-performance, mathematically verified local QEC engineering environment for Claude Code and Claude Desktop.
1
-
Quantum Expectations
Server Details
Quantum error-correction feasibility: success probability, qubit overhead, records, trends.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 75 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.4/5.0
Scored across 13 tools
Disambiguation4/5
The compute tools are explicitly cross-referenced (compute_expectation ↔ compute_required_error_rate forward/inverse, compare_hardware_scenarios as the batch wrapper, fit_historic_series vs get_historic_series fetch/fit split), so an agent can pick confidently. The one soft overlap is that compute_expectation also reports surface-code/qLDPC overhead while compute_fault_tolerant_resources specializes in the same footprint, and the four list_* tools differ mainly by data table rather than action.
Naming Consistency5/5
Every tool is snake_case verb_noun (compute_*, list_*, get_*, fit_*, compare_*), with verbs that accurately reflect the operation. No camelCase, no vague standalone verbs, and the verb choice distinguishes retrieval (list_/get_) from calculation (compute_/fit_/compare_).
Tool Count5/5
13 tools sits squarely in the well-scoped range for a modelling-plus-data server. Each tool occupies a distinct slot (forward model, inverse model, FT resources, QV rate, trend fit, and five data catalogs) with no obvious filler.
Completeness4/5
The domain — predicting hardware/error-correction capability — is covered end-to-end: forward, inverse, fault-tolerant footprint, QV throughput, historic extrapolation, and the reference tables (devices, codes, timings, QUOPS, algorithms). Minor gaps: no composed 'run algorithm X on device Y' runtime/shot estimate, and no feasibility join between list_example_algorithms and the hardware tables, forcing the agent to stitch that together manually.
Available Tools
13 toolscompare_hardware_scenariosCompare Hardware ScenariosARead-onlyIdempotentInspect
Run the same circuit against multiple current SOTA hardware entries in one call so an agent can rank platforms without N sequential compute_expectation calls. Defaults to every entry in list_current_quantum_computers when hardwareIds is omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| compDepth | Yes | ||
| numQubits | Yes | ||
| hardwareIds | No | Subset of QUANTUM_COMPUTERS ids to compare. Omit to compare every entry. | |
| 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. "surface-code" is accepted as an alias for "surface". |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| scenario | Yes | |
| unresolvedHardwareIds | Yes | Requested hardwareIds that match no current-hardware entry. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuine context beyond that: batch semantics and the implicit fan-out to every entry in list_current_quantum_computers when hardwareIds is absent. It does not mention cost/latency of comparing many entries or how error-correction flags affect the run, which keeps it below a 5.
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?
Two sentences, front-loaded with the batch-vs-sequential rationale, zero filler. Every clause carries information an agent needs to choose and configure the call.
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?
An output schema exists, so return values need no explanation, and the schema covers the error-correction parameters. For a 6-parameter batch comparison tool with annotations present, the description is nearly complete; only the two bare numeric parameters and any cost implications for large hardware sets are unaddressed.
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 50%, and the schema itself already documents hardwareIds, distanceSurfaceCode, and errorCorrectionCode in detail. The description only re-states the hardwareIds default, adding little; numQubits and compDepth remain undocumented in both places. Baseline 3 is appropriate given the schema does the heavy lifting.
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 gives a specific verb and resource ('run the same circuit against multiple current SOTA hardware entries') and states the scope distinction from the sibling it replaces ('without N sequential compute_expectation calls'). An agent can immediately tell this apart from compute_expectation.
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 explicitly names the alternative (compute_expectation) and the condition that selects this tool (ranking multiple platforms in one call), plus the default behavior when hardwareIds is omitted. Both the when-to-use and the fallback path are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_expectationCompute Quantum ExpectationARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. Use this, not a generic qubitErrorRate, whenever the question names a platform without stating its own error rate (superconducting, trapped-ion, neutral-atom). 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". |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | |
| caveats | No | |
| examples | No | |
| formulas | No | Verbose only: formula specs keyed by name. |
| glossary | No | |
| scenario | Yes | |
| assumptions | No | |
| methodology | No | |
| modelVersion | Yes | Noise-model version; bumps when a formula or constant changes. |
| exampleProblems | No | |
| hardwareContext | No | Verbose only: current hardware, record series, timings, measured QUOPS scores. |
| exampleProblemProvenance | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, deterministic computation, so the description adds genuine context: the no-error-correction path charges 2d-lattice connectivity as a routing multiplier on depth (surfaced as result.routingOverheadFactor), hardwareId auto-derives the connectivity class, and the response carries formulas, assumptions, caveats, glossary, and sourced historic series. It stops short of stating model accuracy limits or that results are deterministic closed-form estimates, which would have made it a 5.
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?
Three dense sentences, front-loaded with the computation and immediately followed by the sibling routing. The parenthetical inventory of self-describing response fields is slightly long but earns its place by telling the agent one call suffices.
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 and strong annotations, the description needn't explain return values, and it still signals the response is self-describing enough to reason from a single call. Minor gap: it doesn't characterize the physics model's scope or limitations, which matters for a modeling tool an agent may quote as authoritative.
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% and the schema documents most parameters, but the prose adds real meaning beyond it: what connectivity class does to the computation in the no-EC path, how hardwareId resolves and overrides connectivity defaults, and the p/n/d framing of the inputs. Uncovered Boolean/code parameters (useErrorCorrection, errorCorrectionCode) rely on schema descriptions, keeping this from a 5.
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 and resource set: compute effective error rate, success probability, and optional surface-code/qLDPC overhead from a circuit described by p, n, d, and connectivity class. It explicitly distinguishes itself from the inverse tool (compute_required_error_rate) and the multi-platform ranking sibling, so an agent can select without opening schemas.
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?
Explicitly names when to use alternatives: compute_required_error_rate for the inverse 'what hardware do I need?' question and compare_hardware_scenarios for ranking multiple platforms in one call. It also routes between hardwareId and qubitErrorRate, stating to use hardwareId whenever the question names a platform without an error rate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_fault_tolerant_resourcesCompute Fault-Tolerant ResourcesARead-onlyIdempotentInspect
Given an algorithm stated as (numLogicalQubits, tCount) and a physical error rate (or hardwareId), derive the full surface-code + magic-state-distillation footprint from the general laws of the Litinski lattice-surgery cost model (no per-scenario constants): distillation factory choice, tile layout, required code distance, total physical qubits, and wall-clock time. Results are reported under TWO published logical-error fits (conservative + optimistic) because they disagree by 13-268x (d=7 to d=25) - always state both. Returns an explicit infeasible block when no cataloged factory or code distance can satisfy the error budget. Computes numbers only: comparing against classical alternatives and concluding "should this run on a quantum computer" stays with you, the calling agent (state the caveats when you do).
| Name | Required | Description | Default |
|---|---|---|---|
| tCount | Yes | Total number of T gates (magic states consumed). Convention: state Toffoli-counted algorithms in T gates before calling (1 Toffoli ≈ 4–7 T depending on decomposition). | |
| dataBlock | No | Data-block layout (Litinski §2): compact = fewest qubits, fast = shortest time per T gate. | compact |
| hardwareId | No | Alias for qubitErrorRate: resolves to the 2-qubit error rate of the given SOTA hardware entry from list_current_quantum_computers. Use this, not a generic qubitErrorRate such as 0.001, whenever the question names a platform without stating its own error rate (superconducting, trapped-ion, neutral-atom). Supply exactly one of qubitErrorRate or hardwareId. | |
| qubitErrorRate | No | Physical 2-qubit error rate p in (0, 0.1]. Supply exactly one of qubitErrorRate or hardwareId. | |
| cycleTimeSeconds | No | Surface-code cycle time in seconds. Default 1 µs (Litinski convention; Google 2024 measured 1.1 µs on superconducting hardware). Trapped-ion/neutral-atom cycles are orders of magnitude slower. | |
| numLogicalQubits | Yes | Number of logical data qubits the algorithm needs. | |
| targetSuccessProbability | No | Target end-to-end success probability. The failure budget (1 − target) is split evenly between T-state error and logical (memory/surgery) error, matching Litinski §4. |
Output Schema
| Name | Required | Description |
|---|---|---|
| layout | Yes | |
| caveats | Yes | |
| factory | Yes | |
| results | Yes | Both fits bracket the model uncertainty; report both. |
| sources | Yes | |
| formulas | Yes | |
| scenario | Yes | |
| infeasible | Yes | Non-null when the scenario is infeasible as modeled: no cataloged factory meets the T-error budget (factory and layout are then null) or no distance up to the cap meets it under either fit (per-fit distance, qubits and wall clock are then null). |
| assumptions | Yes | |
| totalTimeSteps | Yes | |
| effectiveStepsPerTGate | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/idempotent safety profile; the description adds substantive behavior the agent could not otherwise know: results are reported under two logical-error fits that disagree by 13-268x, an explicit `infeasible` block is returned when the error budget cannot be met, and the model uses no per-scenario constants. It also states plainly that no judgment about quantum vs classical is included.
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 verb, inputs, and outputs in the first sentence, then adds the dual-fit caveat and the infeasible case. It is dense but nearly every clause carries information; the closing scope-boundary sentence is slightly parenthetical yet still useful for correct use.
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?
With an output schema present and full parameter documentation, the description supplies exactly the missing pieces: which error fits are reported and how much they diverge, the existence of an infeasible result, and the division of labor between the tool and the calling agent. Nothing needed to invoke or interpret it correctly is absent.
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% and every parameter carries a substantive description (including the hardwareId-vs-qubitErrorRate exclusivity and the Toffoli-to-T convention), so the schema does the heavy lifting. The description restates the input shape as a tuple but adds no syntax or semantics beyond what the schema already provides, so the baseline of 3 applies.
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 action verb ('derive the full surface-code + magic-state-distillation footprint') plus the exact input form (numLogicalQubits, tCount, error rate/hardwareId) and enumerates the outputs (factory choice, tile layout, distance, physical qubits, wall-clock time). This clearly separates it from siblings like compare_hardware_scenarios or compute_required_error_rate, which do not produce a full resource footprint.
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?
Gives explicit parameter-selection guidance ('Use this, not a generic qubitErrorRate such as 0.001, whenever the question names a platform'), a reporting mandate ('always state both' fits), and a scope boundary ('comparing against classical alternatives... stays with you'). It stops short of naming sibling tools or stating when a different compute_* tool is the better call, so it is clear context without full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compute_quantum_volume_rateCompute Quantum Volume RateARead-onlyIdempotentInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
|---|---|---|
| unit | Yes | |
| inputs | Yes | |
| caveats | Yes | |
| formula | Yes | |
| assumptions | Yes | |
| qvrPerSecond | Yes |
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.
compute_required_error_rateCompute Required Error Rate (Inverse)ARead-onlyIdempotentInspect
Inverse of compute_expectation. Given a circuit (numQubits, compDepth) and an acceptable effective error rate, return the required per-gate logical error rate (requiredLogicalErrorRatePerGate: a number, or null only when the target is genuinely unreachable; never 0) and, for every EC option (no-EC, surface-code per distance, every qLDPC code), the required physical error rate plus the subset of current SOTA hardware that already qualifies. An option whose inverse lands above the code threshold is capped at min(MAX_P, threshold) and carries a note (any sub-threshold p satisfies it); unreachableReason is reserved for genuinely unreachable options. Answers "what hardware do I need to run this algorithm?".
| Name | Required | Description | Default |
|---|---|---|---|
| compDepth | Yes | Circuit depth d (sequential 2-qubit gate layers). Accepts values up to 1e13. | |
| numQubits | Yes | Number of logical qubits n in the circuit. | |
| acceptableErrorRatePercent | Yes | Upper bound on the effective error rate, as a percent. Default website convention is 33 (i.e. ≤33% effective error is "acceptable"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| noEC | Yes | |
| caveats | Yes | |
| formulas | Yes | |
| scenario | Yes | |
| qldpcCodes | Yes | One option per cataloged qLDPC code. |
| assumptions | Yes | |
| surfaceCode | Yes | One option per odd surface-code distance. |
| requiredLogicalErrorRatePerGate | Yes | Per-gate logical error rate every option must deliver; null only when the target is unreachable, never 0. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses key output behavior: null only for genuinely unreachable targets, never 0, threshold capping at min(MAX_P, threshold), explanatory notes for capped options, and unreachableReason reserved for true failures. These are material behavioral details an agent needs.
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 dense but front-loaded: it starts with the inverse relationship and the core question, then explains output caveats. Some return-value detail is lengthy, but most sentences add useful edge-case semantics.
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 and annotations, the description is complete enough for an agent to understand the tool's purpose, inputs, output shape, and edge cases. It also supplies the motivating question and inverse relationship.
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 three inputs are already documented in the schema. The description maps them conceptually to circuit size and acceptable error rate, but adds little format or constraint detail beyond what the schema provides.
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 inverse computation: given circuit size and acceptable effective error rate, return the required per-gate logical error rate and per-EC physical error rates. It explicitly distinguishes itself as the inverse of compute_expectation, making its role clear relative to siblings.
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 clearly frames the use case as answering 'what hardware do I need to run this algorithm?' and names compute_expectation as the forward counterpart. It does not explicitly state when not to use it, but the inverse relationship gives strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fit_historic_seriesFit Historic Series (log-linear)ARead-onlyIdempotentInspect
Fit a log-linear trend (ln(value) = slope * year + intercept) to one historic series — fidelity or qubit-count — for one hardware type. Atomic primitive: compose with list_current_quantum_computers, compute_required_error_rate, or your own modelling to answer "when might hardware reach X?". residualStdDev is the BIASED (maximum-likelihood) RMS — divides by n, not (n - 2); on small series (n ≈ 3–5) inflate by √(n / (n - 2)) before building confidence intervals.
| Name | Required | Description | Default |
|---|---|---|---|
| seriesType | Yes | Which historic series to fit: "fidelity" (2-qubit gate error rate) or "qubit-count" (physical qubits). | |
| targetValue | No | Optional. When supplied, the response includes yearAtTargetValue — the extrapolated year the fit crosses this value (error rate for fidelity series, qubit count for qubit-count series). Null if slope is flat. | |
| hardwareType | Yes | Hardware platform as used by get_historic_series. |
Output Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| slope | Yes | |
| formula | Yes | |
| nPoints | Yes | |
| intercept | Yes | |
| yearRange | Yes | |
| seriesType | Yes | |
| hardwareType | Yes | |
| residualStdDev | Yes | Biased (divide-by-n) RMS of the ln residuals. |
| yearAtTargetValue | No | Present only when targetValue was supplied. |
| halvingPeriodYears | Yes | Non-null iff slope < 0. |
| doublingPeriodYears | Yes | Non-null iff slope > 0. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations with a substantive statistical caveat: residualStdDev is biased (divides by n, not n-2) and should be inflated by √(n/(n-2)) on small series before building confidence intervals. This is exactly the kind of usage-affecting behavior an agent cannot infer from structured fields.
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 model definition and scope in the first sentence, then the residualStdDev caveat. Dense but every clause carries information; only minor cost is the second sentence's parenthetical density.
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?
Output schema exists, so return values like yearAtTargetValue needn't be explained, yet the description still adds the crucial biased-residual note that the schema likely omits. For a read-only fit primitive, nothing an agent needs to call or interpret it correctly is missing.
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 seriesType, hardwareType, and targetValue are already fully documented in the schema. The description restates the two series types but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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 and resource with the exact model form (ln(value) = slope * year + intercept) and the two series it covers. An agent can immediately tell this is a curve-fit primitive for one historic series, distinct from siblings like get_historic_series (raw data) or compute_required_error_rate.
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 frames the tool as an 'atomic primitive' and names composition partners (list_current_quantum_computers, compute_required_error_rate) plus the motivating question ('when might hardware reach X?'). It does not explicitly say when NOT to use it or contrast directly with get_historic_series as the data source, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_briefAgent BriefARead-onlyIdempotentInspect
Return the plain-text site brief describing scope, assumptions, the honesty clause, and the API contract. Mirrors the /agent.txt document served by the website.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds the fact that it 'mirrors /agent.txt served by the website' and lists content categories, which is useful context beyond annotations. No contradictions.
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 two sentences with no filler. First sentence states the action and content, second adds provenance. Perfectly front-loaded and efficient.
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 tool with no parameters and no output schema, the description fully specifies what it returns and its source. It is complete for the agent to understand usage and expected output.
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?
The tool has zero parameters, so the schema is trivially 100% covered. With 0 params, the baseline is 4. The description adds no parameter details since none exist, but it doesn't need to – it accurately describes a no-input tool.
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 clearly states the tool's function: 'Return the plain-text site brief describing scope, assumptions, the honesty clause, and the API contract.' It specifies both the action (return) and the resource (site brief), and it is distinct from siblings which are computational/list tools.
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?
While the description doesn't explicitly state 'use when you need the brief' or mention alternatives, the context makes its usage obvious. No sibling tool provides agent briefs, so the intended usage is implicit. It lacks explicit exclusions but is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_historic_seriesHistoric Hardware Series (Fidelity or Qubit Count)ARead-onlyIdempotentInspect
Return the full historic time series — either two-qubit gate error rates ("fidelity") or physical qubit counts ("qubit-count") — broken down by hardware type. Each datapoint carries a source URL. Use this to extrapolate trends — "when might hardware reach X?" — or pair with fit_historic_series for a log-linear fit on one hardware type.
| Name | Required | Description | Default |
|---|---|---|---|
| seriesType | Yes | "fidelity" → 2-qubit gate error rates; "qubit-count" → physical qubit counts. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | One series per hardware type. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare that this is a safe, read-only, idempotent operation, so the bar is lower. The description adds useful behavioral context: the series is broken down by hardware type and each datapoint includes a source URL, which is not captured by annotations.
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?
Three concise sentences with the main purpose front-loaded. The examples and sibling pairing are compact and earn their place without repetition.
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?
The tool is simple, annotations cover its safety profile, the schema fully documents the only parameter, and an output schema exists. The description supplies enough context about data shape and provenance for an agent to call it correctly.
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%, and the single parameter is an enum with its own description. The description restates the enum meanings but does not add syntax, format, or selection guidance beyond what the schema already provides, so the baseline of 3 is appropriate.
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 and resource: returns the full historic time series, with the two supported series types and hardware-type breakdown. It also distinguishes the tool from fit_historic_series by clarifying that this returns raw series data while fitting is handled by the sibling.
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?
Gives clear usage contexts — extrapolating trends and pairing with fit_historic_series for a log-linear fit. It does not explicitly state when not to use the tool, but the intended use cases are concrete enough for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_current_quantum_computersCurrent Quantum ComputersARead-onlyIdempotentInspect
Return the representative-entry table of current SOTA quantum computers (id, hardware type, physical qubit count, 2-qubit error rate, connectivity class with a note on the coupling graph, source URL). Same data that powers the website's "Current Quantum Computers" table. For the model's capability prediction per entry in QUOPS units, read hardwareContext.currentQuantumComputers[].modelCapability from compute_expectation; for measured scores, list_quops_scores.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | One representative entry per hardware type. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds useful context beyond that: it is the same dataset behind the website table and it identifies the exact entry representation (representative entry per computer).
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?
Three sentences, front-loaded with the return payload, then provenance, then sibling routing. The first sentence is dense but every clause (columns, coupling-graph note, source URL) earns its place; no filler.
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?
An output schema exists, so the return-value enumeration in the description is somewhat redundant, but the sibling routing and the 'representative entry' semantics fill the gaps an agent actually needs. Nothing required to invoke it correctly is 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?
Zero parameters, so the baseline is 4. The description introduces no parameter ambiguity; there is nothing to call incorrectly.
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 (Return) plus a precisely scoped resource (representative-entry table of current SOTA quantum computers) and enumerates the columns returned. An agent can distinguish this from compare_hardware_scenarios or list_hardware_timings without opening the schema.
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 routes adjacent needs to siblings: modelCapability predictions come from compute_expectation, measured scores from list_quops_scores. It doesn't spell out when NOT to use this list (e.g. for historic data), but the alternative routing is clear enough to select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_example_algorithmsExample Quantum AlgorithmsARead-onlyIdempotentInspect
Return the curated list of example quantum algorithms with published resource estimates (qubit count, depth/gate count, source paper URL). Useful for comparing what algorithms need vs. what hardware can deliver. Each entry carries a provenance field: 'published-circuit' means the figure is reproducible from the source, 'attested-estimate' means the source withholds the circuit and the figure rests on the authors' attestation, with a provenanceNote giving the specifics. Carry that caveat whenever you quote an attested figure; do not present it as equivalently sourced.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Curated algorithms with published resource estimates. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds important provenance semantics: 'published-circuit' vs 'attested-estimate', plus a caveat that attested figures should not be presented as equivalently sourced. That is meaningful behavioral context beyond the annotations.
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?
Front-loads the purpose, then gives a usage scenario, then explains the provenance caveat. Every sentence adds relevant information, and the structure is easy for an agent to parse.
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?
Complete for a zero-parameter, read-only list tool with an output schema and rich annotations. The description covers returned content, usage context, and provenance caveats without omitting anything an agent needs to call it correctly.
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?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter usage, and the schema is empty.
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 and resource: 'Return the curated list of example quantum algorithms with published resource estimates.' It also names the returned fields (qubit count, depth/gate count, source paper URL), making the tool's purpose concrete and distinguishable from sibling compute/list tools.
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?
Gives a clear usage context: 'Useful for comparing what algorithms need vs. what hardware can deliver.' It does not explicitly say when not to use it or name sibling alternatives, but the intended scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_hardware_timingsHardware Gate-Cycle TimingsARead-onlyIdempotentInspect
Return per-platform gate-cycle timings (2Q gate time, readout time, in SI seconds) plus the testbed they were measured on (representativeDevice) and the native 2Q gate name, with source URLs. Joins list_current_quantum_computers via hardwareType, but the numbers are BEST-CASE DEMONSTRATIONS from small testbeds, not measurements on the joined devices, which run their gates and array readout orders of magnitude slower. Use for ratio analysis or as optimistic lower-bound inputs to runtime estimates and compute_quantum_volume_rate, and say so when you quote a runtime.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Best-case gate and readout times per platform. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/closed-world safety profile, so the description's job is to add semantics — and it does: the numbers are BEST-CASE DEMONSTRATIONS from small testbeds, not the joined devices, which run orders of magnitude slower. It even prescribes disclosure behavior ('say so when you quote a runtime'), which materially changes how an agent should present results.
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?
Two sentences, front-loaded with what is returned before the caveat and the call-to-action. The middle caveat clause is long and packs several qualifiers ('small testbeds', 'orders of magnitude slower'), which is defensible given the stakes but slightly heavier than needed.
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?
An output schema exists, so return shape needn't be explained, yet the description still marks the units and key fields that matter for interpretation. Combined with the join semantics and the accuracy caveat, an agent has everything needed to call and correctly frame the result.
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?
The tool takes no parameters, so the baseline is 4; the description correctly adds no spurious parameter talk. It does clarify output field semantics (SI seconds, representativeDevice, source URLs) rather than leaving units implicit.
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?
Specific verb and resource ('return per-platform gate-cycle timings') followed by an enumeration of the payload (2Q gate time, readout time, SI seconds, representativeDevice, native gate name, source URLs). It is clearly distinguished from list_current_quantum_computers, which it joins via hardwareType, and from compute_quantum_volume_rate, which consumes it.
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 names the intended uses ('ratio analysis', 'optimistic lower-bound inputs to runtime estimates and compute_quantum_volume_rate') and warns against treating the numbers as measurement on the joined devices. There is no named alternative tool for real device timings, so the guidance stops just short of a full when/when-not/alternative matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_qldpc_codesqLDPC Code Catalog (Quantum Low-Density Parity-Check)ARead-onlyIdempotentInspect
Return the catalog of supported qLDPC (quantum low-density parity-check) error-correction codes (id, label, family, n, k, d, circuitLevelDistance, ancilla counts, roundsPerLogicalOp, threshold, fitCoefficients {c0, c1, c2}, logicalErrorExponent [alpha = d_circ/2], source URLs, provenance, caveats). The per-block, per-syndrome-cycle logical error rate is p^alpha * exp(c0 + c1p + c2p^2) for p <= threshold (the source paper's own fitting form; c1 = c2 = 0 means a plain power law). provenance names the table or section each constant was read from. caveats is an array of source-level qualifications on the entry's constants (loose distance bounds, values a source marks as assumed, numbers that differ between sources); empty when the sources carry none. Read it before quoting a code's logical error rate as firm. Use a code's id as the errorCorrectionCode input to compute_expectation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Supported qLDPC codes. |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, read-only, idempotent, closed-world operation. The description adds substantial behavioral context beyond annotations: the logical error-rate formula, the meaning of `provenance`, and the `caveats` array semantics, including that it is empty when sources carry no qualifications.
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 tool's purpose and then supplies dense but useful detail about fields, the formula, and caveats. It is somewhat long and lists output fields despite an output schema, but the information is relevant and structured.
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 having no parameters, the tool has complex semantics that the description handles well, including the formula, caveat/provenance interpretation, and downstream use of `id`. With an output schema present, the description need not explain raw return values, and its added semantic coverage is sufficient.
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?
The tool has zero parameters, which is the baseline case for a score of 4. Parameter semantics are therefore not a concern, and the description appropriately focuses on the catalog contents and downstream `id` usage.
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 gives a specific verb and resource: returning the catalog of supported qLDPC codes, and it names the key fields returned. It is clearly distinct in subject matter from sibling list_* tools, though it does not explicitly contrast itself with them.
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 usage guidance: read the catalog before quoting a code's logical error rate as firm, and use a code's `id` as the `errorCorrectionCode` input to `compute_expectation`. It does not state when not to use it, but the context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_quops_scoresMeasured QUOPS Capability ScoresARead-onlyIdempotentInspect
Return the measured QUOPS (quantum universal operation performance system, a cross-platform capability benchmark) scores (arXiv:2609.12146): per device, the largest random universal circuit size executed at polarization >= 1/sqrt(e) inside the cone w^2 <= s <= w^3, with width, QUOPS rate, architecture (physical, physical-postselected, logical) and source URL, plus the utility-scale targets in the same unit (RSA-2048 and FeMoco). These are measurements, the yardstick the site's own model is checked against: compare them with modelCapability.quopsEquivalent on the compute_expectation hardware context. Vendor and device names appear here because this table is agent-facing only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| scores | Yes | |
| targets | Yes | |
| definition | Yes | |
| admissibleCone | Yes | |
| polarizationThreshold | Yes |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds useful context beyond that: this is a static measurement table, returns include architecture tier and source URL, and vendor/device names appear because the table is agent-facing only. It does not mention caching or refresh cadence, but with annotations doing the heavy lifting this is solid.
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 purpose and the acronym expansion, then the definition, then the comparison target. Every clause carries information, but the paragraph is dense with nested parentheticals, inline math, and the arXiv id packed into one block, which slightly hurts scannability.
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?
An output schema exists, so return-field enumeration is not required, yet the description still names the key fields (width, QUOPS rate, architecture tiers, source URL) and the reference targets in the same unit. Combined with annotations covering safety, an agent has everything needed to call it correctly.
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?
The tool takes zero parameters, so parameter semantics are moot and the baseline of 4 applies. The description correctly describes what is returned rather than implying any filtering inputs.
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 ('Return') and a precisely defined resource (measured QUOPS scores, with the acronym expanded and an arXiv citation), and explicitly contrasts measurements with the site's own model, distinguishing it from model-based siblings. An agent can tell this is the ground-truth benchmark table, not a computation.
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?
Gives explicit usage direction: compare with modelCapability.quopsEquivalent in the compute_expectation hardware context. That routes the agent to the right sibling for the downstream comparison. It stops short of stating when-not to use it or naming alternative data sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
compute_expectation1 field changed- changed
Input schema / properties / hardwareId / descriptionPrevious value: -"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."New value: +"Alias for qubitErrorRate: resolves to the 2-qubit error rate of the given SOTA hardware entry from list_current_quantum_computers. Use this, not a generic qubitErrorRate, whenever the question names a platform without stating its own error rate (superconducting, trapped-ion, neutral-atom). Supply exactly one of qubitErrorRate or hardwareId."
- Changed
compute_fault_tolerant_resources1 field changed- changed
Input schema / properties / hardwareId / descriptionPrevious value: -"Alias for qubitErrorRate: resolves to the error rate of a SOTA hardware entry."New value: +"Alias for qubitErrorRate: resolves to the 2-qubit error rate of the given SOTA hardware entry from list_current_quantum_computers. Use this, not a generic qubitErrorRate such as 0.001, whenever the question names a platform without stating its own error rate (superconducting, trapped-ion, neutral-atom). Supply exactly one of qubitErrorRate or hardwareId."
12 tool updates
- Changed
compare_hardware_scenarios1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "results": { + "items": { + "additionalProperties": {}, + "properties": { + "hardware": { + "additionalProperties": {}, + "properties": { + "connectivity": { + "enum": [ + "all-to-all", + "reconfigurable", + "2d-lattice" + ], + "type": "string" + }, + "errorRate": { + "type": "number" + }, + "errorRateDisplay": { + "type": "string" + }, + "hardwareType": { + "type": "string" + }, + "id": { + "type": "string" + }, + "physicalQubits": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "id", + "hardwareType", + "physicalQubits", + "errorRate", + "errorRateDisplay", + "connectivity" + ], + "type": "object" + }, + "qubitErrorRateUsed": { + "type": "number" + }, + "result": { + "additionalProperties": {}, + "properties": { + "effectiveErrorRate": { + "description": "Probability that at least one gate fails over the (routed) circuit.", + "type": "number" + }, + "logicalErrorRatePerCycle": { + "description": "Per-syndrome-cycle logical error rate as the calibration source reports it; null without error correction.", + "type": [ + "number", + "null" + ] + }, + "logicalErrorRatePerGate": { + "description": "Per-logical-qubit, per-logical-operation error rate; null without error correction.", + "type": [ + "number", + "null" + ] + }, + "minimumClockRuntimeSeconds": { + "description": "Lower bound on wall-clock runtime; present only when hardwareId was supplied.", + "type": "number" + }, + "physicalQubitsPerLogicalQubit": { + "type": [ + "number", + "null" + ] + }, + "routedDepth": { + "description": "compDepth after routing: the depth the effective-error formula consumed.", + "type": "number" + }, + "routingOverheadFactor": { + "description": "Multiplier the connectivity class applied to compDepth (1 for all-to-all and reconfigurable).", + "type": "number" + }, + "successProbability": { + "description": "1 - effectiveErrorRate.", + "type": "number" + }, + "totalPhysicalQubits": { + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "effectiveErrorRate", + "successProbability", + "routingOverheadFactor", + "routedDepth", + "logicalErrorRatePerGate", + "logicalErrorRatePerCycle", + "physicalQubitsPerLogicalQubit", + "totalPhysicalQubits" + ], + "type": "object" + } + }, + "required": [ + "hardware", + "qubitErrorRateUsed", + "result" + ], + "type": "object" + }, + "type": "array" + }, + "scenario": { + "additionalProperties": {}, + "properties": { + "compDepth": { + "type": "number" + }, + "distanceSurfaceCode": { + "type": [ + "number", + "null" + ] + }, + "errorCorrectionCode": { + "type": [ + "string", + "null" + ] + }, + "numQubits": { + "type": "number" + }, + "useErrorCorrection": { + "type": "boolean" + } + }, + "required": [ + "numQubits", + "compDepth", + "useErrorCorrection", + "distanceSurfaceCode", + "errorCorrectionCode" + ], + "type": "object" + }, + "unresolvedHardwareIds": { + "description": "Requested hardwareIds that match no current-hardware entry.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "scenario", + "results", + "unresolvedHardwareIds" + ], + "type": "object" +}
- Changed
compute_expectation1 field changed- changed
Output 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" + }, + "exampleProblemProvenance": {}, + "exampleProblems": { + "items": {}, + "type": "array" + }, + "examples": { + "items": {}, + "type": "array" + }, + "formulas": { + "additionalProperties": {}, + "description": "Verbose only: formula specs keyed by name.", + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "glossary": {}, + "hardwareContext": { + "additionalProperties": {}, + "description": "Verbose only: current hardware, record series, timings, measured QUOPS scores.", + "properties": {}, + "type": "object" + }, + "methodology": {}, + "modelVersion": { + "description": "Noise-model version; bumps when a formula or constant changes.", + "type": "string" + }, + "result": { + "additionalProperties": {}, + "properties": { + "effectiveErrorRate": { + "description": "Probability that at least one gate fails over the (routed) circuit.", + "type": "number" + }, + "logicalErrorRatePerCycle": { + "description": "Per-syndrome-cycle logical error rate as the calibration source reports it; null without error correction.", + "type": [ + "number", + "null" + ] + }, + "logicalErrorRatePerGate": { + "description": "Per-logical-qubit, per-logical-operation error rate; null without error correction.", + "type": [ + "number", + "null" + ] + }, + "minimumClockRuntimeSeconds": { + "description": "Lower bound on wall-clock runtime; present only when hardwareId was supplied.", + "type": "number" + }, + "physicalQubitsPerLogicalQubit": { + "type": [ + "number", + "null" + ] + }, + "routedDepth": { + "description": "compDepth after routing: the depth the effective-error formula consumed.", + "type": "number" + }, + "routingOverheadFactor": { + "description": "Multiplier the connectivity class applied to compDepth (1 for all-to-all and reconfigurable).", + "type": "number" + }, + "successProbability": { + "description": "1 - effectiveErrorRate.", + "type": "number" + }, + "totalPhysicalQubits": { + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "effectiveErrorRate", + "successProbability", + "routingOverheadFactor", + "routedDepth", + "logicalErrorRatePerGate", + "logicalErrorRatePerCycle", + "physicalQubitsPerLogicalQubit", + "totalPhysicalQubits" + ], + "type": "object" + }, + "scenario": { + "additionalProperties": {}, + "properties": { + "compDepth": { + "type": "number" + }, + "connectivity": { + "enum": [ + "all-to-all", + "reconfigurable", + "2d-lattice" + ], + "type": "string" + }, + "distanceSurfaceCode": { + "type": [ + "number", + "null" + ] + }, + "errorCorrectionCode": { + "type": [ + "string", + "null" + ] + }, + "hardwareId": { + "description": "Non-null when qubitErrorRate was resolved from a current-hardware entry.", + "type": [ + "string", + "null" + ] + }, + "numQubits": { + "type": "number" + }, + "qubitErrorRate": { + "type": "number" + }, + "useErrorCorrection": { + "type": "boolean" + } + }, + "required": [ + "qubitErrorRate", + "hardwareId", + "connectivity", + "numQubits", + "compDepth", + "useErrorCorrection", + "distanceSurfaceCode", + "errorCorrectionCode" + ], + "type": "object" + } + }, + "required": [ + "modelVersion", + "scenario", + "result" + ], + "type": "object" +}
- Changed
compute_fault_tolerant_resources1 field changed- changed
Output 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" + }, + "effectiveStepsPerTGate": { + "type": [ + "number", + "null" + ] + }, + "factory": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "id": { + "type": "string" + }, + "outputErrorRate": { + "type": "number" + }, + "stepsPerOutputState": { + "type": "number" + }, + "successProbability": { + "type": "number" + }, + "tiles": { + "type": "number" + } + }, + "required": [ + "id", + "tiles", + "outputErrorRate", + "successProbability", + "stepsPerOutputState" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "formulas": { + "additionalProperties": { + "type": "string" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "infeasible": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "reason": { + "type": "string" + } + }, + "required": [ + "reason" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Non-null when the scenario is infeasible as modeled: no cataloged factory meets the T-error budget (factory and layout are then null) or no distance up to the cap meets it under either fit (per-fit distance, qubits and wall clock are then null)." + }, + "layout": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "dataBlockTiles": { + "type": "number" + }, + "factoryTiles": { + "type": "number" + }, + "storageTiles": { + "type": "number" + }, + "totalTiles": { + "type": "number" + } + }, + "required": [ + "dataBlockTiles", + "factoryTiles", + "storageTiles", + "totalTiles" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "results": { + "anyOf": [ + { + "additionalProperties": {}, + "properties": { + "conservative": { + "additionalProperties": {}, + "description": "Litinski logical-error fit.", + "properties": { + "distance": { + "description": "Required surface-code distance (odd); null when no cataloged distance suffices.", + "type": [ + "number", + "null" + ] + }, + "errorBudget": { + "additionalProperties": {}, + "properties": { + "logicalContribution": { + "type": [ + "number", + "null" + ] + }, + "tStateContribution": { + "type": "number" + }, + "totalFailureUpperBound": { + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "logicalContribution", + "tStateContribution", + "totalFailureUpperBound" + ], + "type": "object" + }, + "fit": { + "enum": [ + "litinski", + "repo" + ], + "type": "string" + }, + "physicalQubits": { + "type": [ + "number", + "null" + ] + }, + "unreachableReason": { + "type": "string" + }, + "wallClockSeconds": { + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "fit", + "distance", + "physicalQubits", + "wallClockSeconds", + "errorBudget" + ], + "type": "object" + }, + "optimistic": { + "additionalProperties": {}, + "description": "Willow-2024-calibrated fit.", + "properties": { + "distance": { + "description": "Required surface-code distance (odd); null when no cataloged distance suffices.", + "type": [ + "number", + "null" + ] + }, + "errorBudget": { + "additionalProperties": {}, + "properties": { + "logicalContribution": { + "type": [ + "number", + "null" + ] + }, + "tStateContribution": { + "type": "number" + }, + "totalFailureUpperBound": { + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "logicalContribution", + "tStateContribution", + "totalFailureUpperBound" + ], + "type": "object" + }, + "fit": { + "enum": [ + "litinski", + "repo" + ], + "type": "string" + }, + "physicalQubits": { + "type": [ + "number", + "null" + ] + }, + "unreachableReason": { + "type": "string" + }, + "wallClockSeconds": { + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "fit", + "distance", + "physicalQubits", + "wallClockSeconds", + "errorBudget" + ], + "type": "object" + } + }, + "required": [ + "conservative", + "optimistic" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "description": "Both fits bracket the model uncertainty; report both." + }, + "scenario": { + "additionalProperties": {}, + "properties": { + "cycleTimeSeconds": { + "type": "number" + }, + "dataBlock": { + "enum": [ + "compact", + "intermediate", + "fast" + ], + "type": "string" + }, + "hardwareId": { + "type": [ + "string", + "null" + ] + }, + "numLogicalQubits": { + "type": "number" + }, + "qubitErrorRate": { + "type": "number" + }, + "tCount": { + "type": "number" + }, + "targetSuccessProbability": { + "type": "number" + } + }, + "required": [ + "numLogicalQubits", + "tCount", + "qubitErrorRate", + "hardwareId", + "targetSuccessProbability", + "dataBlock", + "cycleTimeSeconds" + ], + "type": "object" + }, + "sources": { + "items": { + "type": "string" + }, + "type": "array" + }, + "totalTimeSteps": { + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "scenario", + "infeasible", + "factory", + "layout", + "effectiveStepsPerTGate", + "totalTimeSteps", + "results", + "formulas", + "assumptions", + "caveats", + "sources" + ], + "type": "object" +}
- Changed
compute_quantum_volume_rate1 field changed- changed
Output 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" +}
- Changed
compute_required_error_rate1 field changed- changed
Output 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" + }, + "formulas": { + "additionalProperties": {}, + "properties": { + "inverseEffectiveError": { + "type": "string" + }, + "inverseQLDPC": { + "type": "string" + }, + "inverseSurfaceCode": { + "type": "string" + } + }, + "required": [ + "inverseEffectiveError", + "inverseSurfaceCode", + "inverseQLDPC" + ], + "type": "object" + }, + "noEC": { + "additionalProperties": {}, + "properties": { + "label": { + "type": "string" + }, + "note": { + "description": "Present when requiredPhysicalErrorRate is a threshold cap rather than an exact inversion.", + "type": "string" + }, + "optionId": { + "description": "\"no-ec\", \"surface-d<odd distance>\", or a qLDPC code id.", + "type": "string" + }, + "physicalQubitsPerLogicalQubit": { + "type": [ + "number", + "null" + ] + }, + "qualifyingHardware": { + "description": "Current-hardware entries whose errorRate already meets requiredPhysicalErrorRate.", + "items": { + "additionalProperties": {}, + "properties": { + "errorRate": { + "type": "number" + }, + "hardwareType": { + "type": "string" + }, + "id": { + "type": "string" + }, + "physicalQubits": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "id", + "hardwareType", + "errorRate", + "physicalQubits" + ], + "type": "object" + }, + "type": "array" + }, + "requiredPhysicalErrorRate": { + "description": "Physical per-gate error rate the hardware must reach; null when the option can never satisfy the target.", + "type": [ + "number", + "null" + ] + }, + "totalPhysicalQubits": { + "type": [ + "number", + "null" + ] + }, + "unreachableReason": { + "type": "string" + } + }, + "required": [ + "optionId", + "label", + "requiredPhysicalErrorRate", + "physicalQubitsPerLogicalQubit", + "totalPhysicalQubits", + "qualifyingHardware" + ], + "type": "object" + }, + "qldpcCodes": { + "description": "One option per cataloged qLDPC code.", + "items": { + "additionalProperties": {}, + "properties": { + "label": { + "type": "string" + }, + "note": { + "description": "Present when requiredPhysicalErrorRate is a threshold cap rather than an exact inversion.", + "type": "string" + }, + "optionId": { + "description": "\"no-ec\", \"surface-d<odd distance>\", or a qLDPC code id.", + "type": "string" + }, + "physicalQubitsPerLogicalQubit": { + "type": [ + "number", + "null" + ] + }, + "qualifyingHardware": { + "description": "Current-hardware entries whose errorRate already meets requiredPhysicalErrorRate.", + "items": { + "additionalProperties": {}, + "properties": { + "errorRate": { + "type": "number" + }, + "hardwareType": { + "type": "string" + }, + "id": { + "type": "string" + }, + "physicalQubits": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "id", + "hardwareType", + "errorRate", + "physicalQubits" + ], + "type": "object" + }, + "type": "array" + }, + "requiredPhysicalErrorRate": { + "description": "Physical per-gate error rate the hardware must reach; null when the option can never satisfy the target.", + "type": [ + "number", + "null" + ] + }, + "totalPhysicalQubits": { + "type": [ + "number", + "null" + ] + }, + "unreachableReason": { + "type": "string" + } + }, + "required": [ + "optionId", + "label", + "requiredPhysicalErrorRate", + "physicalQubitsPerLogicalQubit", + "totalPhysicalQubits", + "qualifyingHardware" + ], + "type": "object" + }, + "type": "array" + }, + "requiredLogicalErrorRatePerGate": { + "description": "Per-gate logical error rate every option must deliver; null only when the target is unreachable, never 0.", + "type": [ + "number", + "null" + ] + }, + "scenario": { + "additionalProperties": {}, + "properties": { + "acceptableErrorRatePercent": { + "type": "number" + }, + "compDepth": { + "type": "number" + }, + "numQubits": { + "type": "number" + } + }, + "required": [ + "numQubits", + "compDepth", + "acceptableErrorRatePercent" + ], + "type": "object" + }, + "surfaceCode": { + "description": "One option per odd surface-code distance.", + "items": { + "additionalProperties": {}, + "properties": { + "label": { + "type": "string" + }, + "note": { + "description": "Present when requiredPhysicalErrorRate is a threshold cap rather than an exact inversion.", + "type": "string" + }, + "optionId": { + "description": "\"no-ec\", \"surface-d<odd distance>\", or a qLDPC code id.", + "type": "string" + }, + "physicalQubitsPerLogicalQubit": { + "type": [ + "number", + "null" + ] + }, + "qualifyingHardware": { + "description": "Current-hardware entries whose errorRate already meets requiredPhysicalErrorRate.", + "items": { + "additionalProperties": {}, + "properties": { + "errorRate": { + "type": "number" + }, + "hardwareType": { + "type": "string" + }, + "id": { + "type": "string" + }, + "physicalQubits": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + } + }, + "required": [ + "id", + "hardwareType", + "errorRate", + "physicalQubits" + ], + "type": "object" + }, + "type": "array" + }, + "requiredPhysicalErrorRate": { + "description": "Physical per-gate error rate the hardware must reach; null when the option can never satisfy the target.", + "type": [ + "number", + "null" + ] + }, + "totalPhysicalQubits": { + "type": [ + "number", + "null" + ] + }, + "unreachableReason": { + "type": "string" + } + }, + "required": [ + "optionId", + "label", + "requiredPhysicalErrorRate", + "physicalQubitsPerLogicalQubit", + "totalPhysicalQubits", + "qualifyingHardware" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "scenario", + "requiredLogicalErrorRatePerGate", + "noEC", + "surfaceCode", + "qldpcCodes", + "formulas", + "assumptions", + "caveats" + ], + "type": "object" +}
- Changed
fit_historic_series1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "doublingPeriodYears": { + "description": "Non-null iff slope > 0.", + "type": [ + "number", + "null" + ] + }, + "formula": { + "const": "ln(value) = slope * year + intercept", + "type": "string" + }, + "halvingPeriodYears": { + "description": "Non-null iff slope < 0.", + "type": [ + "number", + "null" + ] + }, + "hardwareType": { + "type": "string" + }, + "intercept": { + "type": "number" + }, + "model": { + "const": "log-linear", + "type": "string" + }, + "nPoints": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "residualStdDev": { + "description": "Biased (divide-by-n) RMS of the ln residuals.", + "type": "number" + }, + "seriesType": { + "enum": [ + "fidelity", + "qubit-count" + ], + "type": "string" + }, + "slope": { + "type": "number" + }, + "yearAtTargetValue": { + "description": "Present only when targetValue was supplied.", + "type": [ + "number", + "null" + ] + }, + "yearRange": { + "items": false, + "maxItems": 2, + "minItems": 2, + "prefixItems": [ + { + "type": "number" + }, + { + "type": "number" + } + ], + "type": "array" + } + }, + "required": [ + "seriesType", + "hardwareType", + "model", + "formula", + "slope", + "intercept", + "nPoints", + "residualStdDev", + "yearRange", + "halvingPeriodYears", + "doublingPeriodYears" + ], + "type": "object" +}
- Changed
get_historic_series1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "items": { + "description": "One series per hardware type.", + "items": { + "additionalProperties": {}, + "properties": { + "data": { + "items": { + "additionalProperties": {}, + "properties": { + "infidelity": { + "description": "Fidelity series only: 2-qubit gate infidelity.", + "type": "number" + }, + "label": { + "type": "string" + }, + "qubitCount": { + "description": "Qubit-count series only.", + "type": "number" + }, + "source": { + "format": "uri", + "type": "string" + }, + "year": { + "type": "number" + } + }, + "required": [ + "year", + "source" + ], + "type": "object" + }, + "type": "array" + }, + "name": { + "description": "Hardware type.", + "type": "string" + }, + "note": { + "type": "string" + } + }, + "required": [ + "name", + "data" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "items" + ], + "type": "object" +}
- Changed
list_current_quantum_computers1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "items": { + "description": "One representative entry per hardware type.", + "items": { + "additionalProperties": {}, + "properties": { + "connectivity": { + "enum": [ + "all-to-all", + "reconfigurable", + "2d-lattice" + ], + "type": "string" + }, + "connectivityNote": { + "type": "string" + }, + "errorRate": { + "description": "2-qubit gate error rate as a probability.", + "type": "number" + }, + "errorRateDisplay": { + "type": "string" + }, + "hardwareType": { + "type": "string" + }, + "id": { + "description": "Stable alias accepted as hardwareId by the compute tools.", + "type": "string" + }, + "physicalQubits": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "source": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "id", + "physicalQubits", + "errorRate", + "errorRateDisplay", + "hardwareType", + "connectivity", + "connectivityNote", + "source" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "items" + ], + "type": "object" +}
- Changed
list_example_algorithms1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "items": { + "description": "Curated algorithms with published resource estimates.", + "items": { + "additionalProperties": {}, + "properties": { + "compDepth": { + "type": "number" + }, + "compDepthDisplay": { + "type": "string" + }, + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "numQubits": { + "type": "number" + }, + "provenance": { + "enum": [ + "published-circuit", + "attested-estimate" + ], + "type": "string" + }, + "provenanceNote": { + "type": [ + "string", + "null" + ] + }, + "source": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "id", + "name", + "numQubits", + "compDepth", + "compDepthDisplay", + "source", + "provenance", + "provenanceNote" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "items" + ], + "type": "object" +}
- Changed
list_hardware_timings1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "items": { + "description": "Best-case gate and readout times per platform.", + "items": { + "additionalProperties": {}, + "properties": { + "hardwareType": { + "description": "Join key to list_current_quantum_computers.", + "type": "string" + }, + "native2QGate": { + "type": "string" + }, + "notes": { + "type": "string" + }, + "representativeDevice": { + "description": "The testbed measured, not the joined current-hardware device.", + "type": "string" + }, + "t2QGateTime": { + "additionalProperties": {}, + "properties": { + "seconds": { + "description": "SI seconds.", + "type": "number" + }, + "source": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "seconds", + "source" + ], + "type": "object" + }, + "tMeasurement": { + "additionalProperties": {}, + "properties": { + "seconds": { + "description": "SI seconds.", + "type": "number" + }, + "source": { + "format": "uri", + "type": "string" + } + }, + "required": [ + "seconds", + "source" + ], + "type": "object" + } + }, + "required": [ + "hardwareType", + "representativeDevice", + "native2QGate", + "t2QGateTime", + "tMeasurement" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "items" + ], + "type": "object" +}
- Changed
list_qldpc_codes1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "items": { + "description": "Supported qLDPC codes.", + "items": { + "additionalProperties": {}, + "properties": { + "caveats": { + "items": { + "type": "string" + }, + "type": "array" + }, + "checkAncillasPerBlock": { + "type": "number" + }, + "circuitLevelDistance": { + "type": "number" + }, + "d": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "family": { + "type": "string" + }, + "fitCoefficients": { + "additionalProperties": {}, + "properties": { + "c0": { + "type": "number" + }, + "c1": { + "type": "number" + }, + "c2": { + "type": "number" + } + }, + "required": [ + "c0", + "c1", + "c2" + ], + "type": "object" + }, + "id": { + "description": "Accepted as errorCorrectionCode by compute_expectation.", + "type": "string" + }, + "k": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "label": { + "type": "string" + }, + "logicAncillasPerBlock": { + "type": "number" + }, + "logicalErrorExponent": { + "type": "number" + }, + "n": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "provenance": { + "additionalProperties": { + "type": "string" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + "roundsPerLogicalOp": { + "type": "number" + }, + "source": { + "format": "uri", + "type": "string" + }, + "threshold": { + "type": "number" + } + }, + "required": [ + "id", + "label", + "family", + "n", + "k", + "d", + "circuitLevelDistance", + "checkAncillasPerBlock", + "logicAncillasPerBlock", + "roundsPerLogicalOp", + "threshold", + "fitCoefficients", + "logicalErrorExponent", + "provenance", + "source", + "caveats" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "items" + ], + "type": "object" +}
- Changed
list_quops_scores1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": {}, + "properties": { + "admissibleCone": {}, + "definition": { + "type": "string" + }, + "polarizationThreshold": { + "type": "number" + }, + "scores": { + "items": { + "additionalProperties": {}, + "properties": { + "architecture": { + "enum": [ + "physical", + "physical-postselected", + "logical" + ], + "type": "string" + }, + "code": { + "type": [ + "string", + "null" + ] + }, + "device": { + "type": "string" + }, + "discardFraction": { + "type": [ + "number", + "null" + ] + }, + "hardwareType": { + "type": "string" + }, + "id": { + "type": "string" + }, + "physicalQubits": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "quopsRatePerSecond": { + "type": "number" + }, + "quopsScore": { + "type": "number" + }, + "source": { + "format": "uri", + "type": "string" + }, + "vendor": { + "type": "string" + }, + "width": { + "type": "number" + }, + "year": { + "type": "number" + } + }, + "required": [ + "id", + "device", + "vendor", + "hardwareType", + "physicalQubits", + "architecture", + "code", + "quopsScore", + "width", + "quopsRatePerSecond", + "discardFraction", + "year", + "source" + ], + "type": "object" + }, + "type": "array" + }, + "targets": { + "items": { + "additionalProperties": {}, + "properties": { + "id": { + "type": "string" + }, + "logicalQubits": { + "type": "number" + }, + "note": { + "type": [ + "string", + "null" + ] + }, + "problem": { + "type": "string" + }, + "quopsRateTargetPerSecond": { + "type": "number" + }, + "quopsTarget": { + "type": "number" + }, + "resourceEstimateSource": { + "format": "uri", + "type": "string" + }, + "source": { + "format": "uri", + "type": "string" + }, + "timeBudget": { + "type": "string" + }, + "toffoliCount": { + "type": "number" + } + }, + "required": [ + "id", + "problem", + "logicalQubits", + "toffoliCount", + "quopsTarget", + "quopsRateTargetPerSecond", + "timeBudget", + "resourceEstimateSource", + "source", + "note" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "definition", + "polarizationThreshold", + "admissibleCone", + "scores", + "targets" + ], + "type": "object" +}
2 tool updates
- Changed
compute_expectation1 field changed- added
Input schema / properties / connectivityAdded 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" +}
- Added
list_quops_scores
1 tool update
- Changed
compare_hardware_scenarios1 field changed- changed
Input schema / properties / errorCorrectionCode / enumPrevious value: -[ - "surface", - "bb-144-12-12", - "surface-code" -]New value: +[ + "surface", + "bb-144-12-12", + "bb-288-12-18", + "surface-code" +]
2 tool updates
- Changed
compare_hardware_scenarios4 fields changed- changed
Input schema / properties / distanceSurfaceCode / descriptionPrevious value: -"Required when useErrorCorrection=true and errorCorrectionCode=\"surface\" (odd integer)."New 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." - removed
Input schema / properties / distanceSurfaceCode / maximumRemoved value: -31 - removed
Input schema / properties / distanceSurfaceCode / minimumRemoved value: -3 - changed
Input schema / properties / distanceSurfaceCode / typePrevious value: -"integer"New value: +"number"
- Changed
compute_expectation4 fields changed- added
Input schema / properties / distanceSurfaceCode / descriptionAdded 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." - removed
Input schema / properties / distanceSurfaceCode / maximumRemoved value: -31 - removed
Input schema / properties / distanceSurfaceCode / minimumRemoved value: -3 - changed
Input schema / properties / distanceSurfaceCode / typePrevious value: -"integer"New value: +"number"
12 tool updates
- Changed
compare_hardware_scenarios1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
compute_expectation1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
compute_fault_tolerant_resources1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
compute_quantum_volume_rate1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
compute_required_error_rate1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
fit_historic_series1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_agent_brief1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
get_historic_series1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_current_quantum_computers1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_example_algorithms1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_hardware_timings1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list_qldpc_codes1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
1 tool update
- Added
compute_fault_tolerant_resources
2 tool updates
- Changed
compare_hardware_scenarios2 fields changed- changed
Input schema / properties / errorCorrectionCode / descriptionPrevious value: -"Either \"surface\" (default when useErrorCorrection=true) or a qLDPC code id."New value: +"Either \"surface\" (default when useErrorCorrection=true) or a qLDPC code id. \"surface-code\" is accepted as an alias for \"surface\"." - changed
Input schema / properties / errorCorrectionCode / enumPrevious value: -[ - "surface", - "bb-144-12-12" -]New value: +[ + "surface", + "bb-144-12-12", + "surface-code" +]
- Changed
compute_expectation1 field changed- added
Input schema / properties / errorCorrectionCode / descriptionAdded 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\"."
11 tool updates
- First observed
compare_hardware_scenarios - First observed
compute_expectation - First observed
compute_quantum_volume_rate - First observed
compute_required_error_rate - First observed
fit_historic_series - First observed
get_agent_brief - First observed
get_historic_series - First observed
list_current_quantum_computers - First observed
list_example_algorithms - First observed
list_hardware_timings - First observed
list_qldpc_codes
Related MCP Connectors
Quantum computing jobs, arXiv papers & researcher profiles from qubitsok.com
Quantum on IonQ/IBM/Braket: spending mandates, signed benchmarks, paid PQC CBOM, advantage receipts.
QuantumOracle — 18 post-quantum crypto tools: Kyber, Dilithium, hybrid schemes, migration.
Verifiable random decisions, audit sampling, fair selection, and proof verification using QnEvt.
Related MCP Servers
- AlicenseAqualityDmaintenanceTeaching LLMs that Math.random() is so last century79 npm2MIT
- FlicenseNot gradedqualityCmaintenanceA gravitational-wave detection pipeline combining lightweight signal-processing with an LLM triage layer, featuring a pre-registered evaluation harness that measures performance against synthetic injections in real detector noise.-
- FlicenseNot gradedqualityBmaintenanceAuditable AGI-2027 evidence: eight graded Situational Awareness predictions with pre-registered flip conditions, a 0-100 Thesis Tracker with full score history, and a public market-call ledger where misses stay published. Free, no auth, CC BY 4.0.-
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.