# Quantum Expectations (remote · www.quantum-expectations.com)

Quantum error-correction feasibility: success probability, qubit overhead, records, trends.

- Trust score: 77/100 (medium)
- Change this week: +7
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `www.quantum-expectations.com`: 77/100 (this document), [markdown](https://verifymcp.io/servers/com-quantum-expectations-quantum-expectations/api-mcp.md), [page](https://verifymcp.io/servers/com-quantum-expectations-quantum-expectations/api-mcp)

## Channel facts

- Endpoint: `https://www.quantum-expectations.com/api/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.3.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 80/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 82/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 2231 tokens (~117/item across 19 items; 12 tools + 7 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 92/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 77% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-quantum-expectations-quantum-expectations https://www.quantum-expectations.com/api/mcp
```

### Codex

```toml
[mcp_servers.com-quantum-expectations-quantum-expectations]
url = "https://www.quantum-expectations.com/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-quantum-expectations-quantum-expectations": {
      "type": "remote",
      "url": "https://www.quantum-expectations.com/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-quantum-expectations-quantum-expectations --url https://www.quantum-expectations.com/api/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-quantum-expectations-quantum-expectations:
    url: "https://www.quantum-expectations.com/api/mcp"
```

### Other

```json
{
  "mcpServers": {
    "com-quantum-expectations-quantum-expectations": {
      "type": "http",
      "url": "https://www.quantum-expectations.com/api/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 77, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 76, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 75, +3)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 72, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-28 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 70, +1)

- [functional improvement] Stability: unverified → 0.03
- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 69)

First indexed and scored.

## MCP tools (12)

### `compute_expectation` (~345 tokens)

Compute Quantum Expectation

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.

Input parameters:

- `compDepth` (integer, required)
- `distanceSurfaceCode` (integer)
- `errorCorrectionCode` (string): Either "surface" (default when useErrorCorrection=true) or a qLDPC code id from list_qldpc_codes. "surface-code" is accepted as an alias for "surface".
- `hardwareId` (string): 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.
- `numQubits` (integer, required)
- `qubitErrorRate` (number): Per-gate 2-qubit error rate p, in (0, 0.1]. Supply exactly one of qubitErrorRate or hardwareId.
- `useErrorCorrection` (boolean)
- `verbose` (boolean): When false, omits hardwareContext, formulas, assumptions, caveats, glossary, examples, and exampleProblems from the response — leaving only modelVersion, scenario, and result. Use for parameter sweep…

### `compute_required_error_rate` (~186 tokens)

Compute Required Error Rate (Inverse)

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?".

Input parameters:

- `acceptableErrorRatePercent` (number, required): Upper bound on the effective error rate, as a percent. Default website convention is 33 (i.e. ≤33% effective error is "acceptable").
- `compDepth` (integer, required): Circuit depth d (sequential 2-qubit gate layers). Accepts values up to 1e13.
- `numQubits` (integer, required): Number of logical qubits n in the circuit.

### `compute_fault_tolerant_resources` (~448 tokens)

Compute Fault-Tolerant Resources

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).

Input parameters:

- `cycleTimeSeconds` (number): 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.
- `dataBlock` (string): Data-block layout (Litinski §2): compact = fewest qubits, fast = shortest time per T gate.
- `hardwareId` (string): Alias for qubitErrorRate: resolves to the error rate of a SOTA hardware entry.
- `numLogicalQubits` (integer, required): Number of logical data qubits the algorithm needs.
- `qubitErrorRate` (number): Physical 2-qubit error rate p in (0, 0.1]. Supply exactly one of qubitErrorRate or hardwareId.
- `tCount` (integer, required): 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).
- `targetSuccessProbability` (number): 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.

### `compare_hardware_scenarios` (~178 tokens)

Compare Hardware Scenarios

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.

Input parameters:

- `compDepth` (integer, required)
- `distanceSurfaceCode` (integer): Required when useErrorCorrection=true and errorCorrectionCode="surface" (odd integer).
- `errorCorrectionCode` (string): Either "surface" (default when useErrorCorrection=true) or a qLDPC code id. "surface-code" is accepted as an alias for "surface".
- `hardwareIds` (array): Subset of QUANTUM_COMPUTERS ids to compare. Omit to compare every entry.
- `numQubits` (integer, required)
- `useErrorCorrection` (boolean)

### `list_current_quantum_computers` (~56 tokens)

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_hardware_timings` (~89 tokens)

Hardware Gate-Cycle 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.

### `compute_quantum_volume_rate` (~233 tokens)

Compute Quantum Volume Rate

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

Input parameters:

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

### `fit_historic_series` (~234 tokens)

Fit Historic Series (log-linear)

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.

Input parameters:

- `hardwareType` (string, required): Hardware platform as used by get_historic_series.
- `seriesType` (string, required): Which historic series to fit: "fidelity" (2-qubit gate error rate) or "qubit-count" (physical qubits).
- `targetValue` (number): 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…

### `list_example_algorithms` (~49 tokens)

Example Quantum 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_qldpc_codes` (~92 tokens)

qLDPC Code Catalog

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`.

### `get_historic_series` (~118 tokens)

Historic Hardware Series (Fidelity or Qubit Count)

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.

Input parameters:

- `seriesType` (string, required): "fidelity" → 2-qubit gate error rates; "qubit-count" → physical qubit counts.

### `get_agent_brief` (~41 tokens)

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.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-quantum-expectations-quantum-expectations/api-mcp#diagnostics

## Score history

- 2026-08-03: 77
- 2026-08-02: 76
- 2026-08-01: 76
- 2026-07-31: 75
- 2026-07-30: 72
- 2026-07-29: 71
- 2026-07-28: 71
- 2026-07-27: 70
- 2026-07-26: 69

## Links

- Remote endpoint: https://www.quantum-expectations.com/api/mcp
- Website: https://www.quantum-expectations.com/
- Changelog RSS feed: https://verifymcp.io/servers/com-quantum-expectations-quantum-expectations/api-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-quantum-expectations-quantum-expectations/api-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/com-quantum-expectations-quantum-expectations/api-mcp