Skip to main content
Glama

Quantum Expectations

by com.quantum-expectations
OverviewDiscussionsAdmin

Hardware Gate-Cycle Timings

list_hardware_timings
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
itemsYesBest-case gate and readout times per platform.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput 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"
+}
  2. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observed

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.

All Quantum Expectations toolsInspect
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