ScienceShot data-centre intelligence and physics reference

Qubit performance ledger

device_ledger_query

Read-onlyIdempotent

Query the ScienceShot QEP device ledger: published measurements of qubit coherence (T1, T2), single- and two-qubit gate fidelity, readout fidelity and gate time on superconducting, trapped-ion, neutral-atom, semiconductor-spin, defect-spin and photonic devices, one cited row per result. Filter by platform, metric, statistic and since_year. With a metric, rows come best first and comparable rows before the rest. Each row gives value, unit, SI value, date, source type, reference, link and the figure or table where the number was read; the answer adds the ledger release and the page to cite. Best, median, mean and single-device values are separate rows; Pauli-error and photonic rows are flagged not comparable.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "device_ledger_query"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Rows to return, 1 to 50 (default 10).
`metric`	No	Metric, e.g. f2q (two-qubit gate fidelity), t1, t2_echo, readout_fidelity.
`platform`	No	Qubit platform.
`statistic`	No	How the figure was summarised in the source.
`since_year`	No	Only results published in this year or later.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), the description discloses substantive behavior: one cited row per result, ordering that changes when a metric is supplied, separate rows for best/median/mean/single, and that Pauli-error and photonic rows are flagged not comparable. It also states the row payload and that the answer carries a ledger release and page to cite. This is exactly the kind of context annotations cannot convey.

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?

Content is front-loaded: what the ledger is, then filters, then ordering, then return shape. Long but dense — nearly every clause (comparability flags, separate statistic rows, citation page) carries information an agent needs. The platform enumeration slightly duplicates the schema but reads as scope-setting rather than padding.

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?

There is no output schema, so the description must describe returns, and it does thoroughly: value, unit, SI value, date, source type, reference, link, figure/table location, plus release and citation page. For a five-parameter read-only lookup with full schema coverage, nothing an agent needs to call or interpret results 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?

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning: supplying 'metric' changes result ordering and comparability, and 'statistic' values are distinct rows rather than aggregations of each other. That is behavioral semantics the enum lists alone do not convey. Minor duplication of the platform/metric enumerations keeps it from a 5.

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?

Specific verb ('Query') plus a named resource ('ScienceShot QEP device ledger') and an explicit enumeration of what the ledger contains (T1/T2, gate fidelity, readout fidelity, gate time) across six platforms. An agent can tell this is a citation-backed measurement lookup rather than a calculator. It does not, however, distinguish itself from the sibling 'qubit_coherence', which likely computes rather than cites values.

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

Usage Guidelines3/5

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

It states the available filters and one ordering rule ('With a metric, rows come best first and comparable rows before the rest'), which implies how to use the tool for ranked lookups. But it never says when to prefer this over 'qubit_coherence' or 'search_scienceshot', and gives no exclusions or prerequisites. Usage is implied rather than directed.

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

All ScienceShot data-centre intelligence and physics reference tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?