mcp server
Quantum Expectations
Quantum error-correction feasibility: success probability, qubit overhead, records, trends.
Description as published by the maintainer. Source
- version 0.3.0
- active
active — Registry entry last updated 2026-07-05.
What this server can do
12 functions, named and described by the server itself. Parameter names are shown because they say more about what a function does than its name usually does.
compare_hardware_scenarios(compDepth, numQubits, hardwareIds, useErrorCorrection, distanceSurfaceCode, errorCorrectionCode)- 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. Required: numQubits, compDepth.
compute_expectation(verbose, compDepth, numQubits, hardwareId, qubitErrorRate, useErrorCorrection, distanceSurfaceCode, errorCorrectionCode)- Given a quantum circuit (2-qubit error rate p, qubit count n, depth d), compute the effective error rate, success probability, and optional surface-code or qLDPC overhead. 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. Required: numQubits, compDepth.
compute_fault_tolerant_resources(tCount, dataBlock, hardwareId, qubitErrorRate, cycleTimeSeconds, numLogicalQubits, targetSuccessProbability)- 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). Required: numLogicalQubits, tCount.
compute_quantum_volume_rate(t2QSeconds, quantumVolume, tMeasurementSeconds)- 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). Required: quantumVolume, t2QSeconds, tMeasurementSeconds.
compute_required_error_rate(compDepth, numQubits, acceptableErrorRatePercent)- Inverse of compute_expectation. Given a circuit (numQubits, compDepth) and an acceptable effective error rate, return the required per-gate logical error rate 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. Answers "what hardware do I need to run this algorithm?". Required: numQubits, compDepth, acceptableErrorRatePercent.
fit_historic_series(seriesType, targetValue, hardwareType)- 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. Required: seriesType, hardwareType.
get_agent_brief- 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.
get_historic_series(seriesType)- 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. Required: seriesType.
list_current_quantum_computers- Return the representative-entry table of current SOTA quantum computers (id, hardware type, physical qubit count, 2-qubit error rate). Same data that powers the website's "Current Quantum Computers" table.
list_example_algorithms- 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.
list_hardware_timings- Return per-platform gate-cycle timings (2Q gate time, readout time, in SI seconds) plus the representative device and native 2Q gate name, with source URLs. Joins list_current_quantum_computers via `hardwareType`. Use for runtime estimates, ratio analysis, or as inputs to compute_quantum_volume_rate. Values are representative current-generation numbers, not records.
list_qldpc_codes- Return the catalog of supported qLDPC codes (id, label, family, n, k, d, circuitLevelDistance, ancilla counts, roundsPerLogicalOp, threshold, prefactor [per block per syndrome cycle], logicalErrorExponent [= d_circ/2], source URLs). Use a code's `id` as the `errorCorrectionCode` input to `compute_expectation`.
Last successful function declaration observed on . Source: https://www.quantum-expectations.com/api/mcp. We list what the server declared; we do not call any of these functions.
Endpoint status observed on . Source: https://www.quantum-expectations.com/api/mcp.
Signals
These are separate measurements of different things. They are deliberately not combined into one score, because a popularity number that mixes website traffic with saves and stars cannot be checked or acted on.
| Signal | Value | What it measures | Window | Observed | Source |
|---|---|---|---|---|---|
| Latest published version | 0.3.0 | Latest version string the maintainer published to the registry. | as of fetch | Model Context Protocol | |
| Registry record last updated | 2026-07-05 | When the registry record was last updated by its maintainer. | point in time | Model Context Protocol | |
| First listed in the MCP Registry | 2026-07-05 | Date this server was first published to the official MCP Registry. Not a usage or quality measure. | point in time | Model Context Protocol | |
| mcp tools declared | 12 tools | Number of functions the server itself declared when asked to list them. This is what the server offers an agent, not a measure of how well any of them work. | as of probe | www.quantum-expectations.com | |
| mcp endpoint status | ok | The server listed 12 functions when asked. | as of probe | www.quantum-expectations.com |
Where to get it
This record as data
Every field on this page, with its source and observation date, is in the catalog JSON. Fetch the whole kind at once instead of parsing this HTML.
GET /api/v1/entries/mcp_server.json