Quantum Expectations
Server Details
Quantum error-correction feasibility: success probability, qubit overhead, records, trends.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 11 of 11 tools scored.
Each tool has a clearly distinct purpose, from listing hardware to computing expectations and fitting trends. The descriptions explicitly differentiate them, e.g., compare_hardware_scenarios vs compute_expectation vs compute_required_error_rate.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., compute_expectation, list_current_quantum_computers). No mixing of conventions or vague verbs.
11 tools is well within the optimal range for a specialized domain, covering all necessary operations without redundancy or insufficiency.
The tool set provides a complete workflow for quantum computing analysis: listing hardware, historic data, algorithms, codes; computing expectations and inverse; comparing scenarios; fitting trends. No obvious gaps for the stated purpose.
Available Tools
11 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 | Required when useErrorCorrection=true and errorCorrectionCode="surface" (odd integer). | |
| errorCorrectionCode | No | Either "surface" (default when useErrorCorrection=true) or a qLDPC code id. "surface-code" is accepted as an alias for "surface". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds valuable context about defaulting to all hardware entries when hardwareIds is omitted, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose and efficient wording. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple comparison tool, but it lacks information about the return value format or any output schema. With no output schema, the agent may not know what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with three parameters lacking descriptions (compDepth, numQubits, useErrorCorrection). The tool description does not add any parameter-specific details, so it doesn't compensate for the gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs the same circuit against multiple hardware entries in one call, distinguishing from sequential compute_expectation calls. Includes default behavior when hardwareIds is omitted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions this tool is for ranking platforms without N sequential calls, providing a clear alternative to compute_expectation. Does not explicitly state when not to use, but context is sufficient.
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), 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.
| 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. Supply exactly one of qubitErrorRate or hardwareId. | |
| qubitErrorRate | No | Per-gate 2-qubit error rate p, in (0, 0.1]. Supply exactly one of qubitErrorRate or hardwareId. | |
| useErrorCorrection | No | ||
| distanceSurfaceCode | No | ||
| 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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent. Description adds significant behavioral detail: response is self-describing with formulas, assumptions, caveats, glossary, SOTA hardware, historic series. Also explains verbose parameter behavior. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loads core purpose, then adds usage guidance. No fluff, but could be slightly more structured with bullet points. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description explains response structure (self-describing) and mentions optional context. also references alternative tools. Covers most agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (4 of 8 parameters documented). Description adds meaning by mentioning circuit parameters (error rate p, qubit count n, depth d) and optional error correction overhead, but does not fully detail all parameters. Adequate compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes effective error rate and success probability from circuit parameters (qubit count, depth, error rate). Distinguishes from sibling tools by mentioning the inverse tool and ranking tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs. compute_required_error_rate and compare_hardware_scenarios. Also implies use case for analyzing a specific circuit.
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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotent=true, but the description goes beyond by explaining the overestimation: 'OVERSTATES achievable rate: real compilation inflates the 2Q-gate count per layer; omits reset/SPAM, mid-circuit measurement, and classical-control latency.' This provides valuable behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: formula, limitation, alternative. No wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the formula, inputs, and limitations. It covers the purpose, how it works, and caveats. For a compute function with 3 required parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described with units and examples. The description references parameters in the formula but does not add new semantic information beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it computes Quantum Volume Rate (QV/second) with a specific formula. The verb 'Compute' and resource 'Quantum Volume Rate' are precise. It distinguishes itself from sibling tools by focusing on this specific metric, contrasting with tools like 'compute_required_error_rate' or 'compute_expectation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is a first-order estimate and overstates achievable rate. It also provides an alternative: 'For a production throughput metric, see IBM's CLOPS (arXiv:2110.14108)'. This clearly tells the agent when not to use this tool and what to use instead.
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 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?".
| 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"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read/computation tool. The description adds the specifics of what is computed (required error rates and qualifying hardware) but does not disclose additional behavioral traits like caching or side effects. With annotations covering safety, the description provides moderate added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no unnecessary words. It front-loads the inverse relationship and provides a concise, complete summary of the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three required parameters and no output schema, yet the description gives a comprehensive overview of the output: required logical error rate, per EC option physical error rate, and qualifying hardware. While it does not detail the return format, it covers the conceptual completeness for a complex tool with multiple EC options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the input schema (100% coverage), so the schema already explains their meaning. The description mentions the acceptable error rate is a percent and notes the default website convention of 33, which is redundant with the schema's description. The description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the inverse of compute_expectation and specifies its function: given a circuit and acceptable error rate, it returns required logical and physical error rates per EC option, and identifies qualifying hardware. This distinctive purpose sets it apart from sibling tools like compute_expectation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly answers the question 'what hardware do I need to run this algorithm?' and mentions being the inverse of another tool, providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tools provide such context indirectly.
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds critical behavioral details: residualStdDev is biased (divides by n, not n-2) and provides a correction formula for small series, plus explains the yearAtTargetValue behavior when targetValue is supplied. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by behavioral nuance. Every clause adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains the key output fields (residualStdDev, yearAtTargetValue) and their interpretation. It also covers accuracy considerations for small series, making it sufficiently complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: explains the bias in residualStdDev, how to adjust confidence intervals, and the effect of supplying targetValue. This goes well beyond the parameter descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it fits a log-linear trend to one historic series (fidelity or qubit-count) for one hardware type, and mentions composition with other tools. This clearly distinguishes it from siblings like get_historic_series (raw data) and compute_required_error_rate (error correction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Atomic primitive: compose with list_current_quantum_computers, compute_required_error_rate, or your own modelling to answer "when might hardware reach X?"'. Also specifies it works with one series and one hardware type, providing clear when-to-use guidance.
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns plain text and mirrors a specific web document, which provides additional behavioral context beyond the annotations. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that immediately convey the tool's purpose and key attributes. No redundant or extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description compensates by describing the return value as plain-text containing scope, assumptions, honesty clause, and API contract, and noting it mirrors the /agent.txt file. This is sufficient for the tool's simplicity, though it could explicitly mention that no input is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description does not need to add parameter information, and it correctly omits any. The schema coverage is 100% (empty schema), and the description adds no unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the plain-text site brief covering scope, assumptions, honesty clause, and API contract, and it explicitly mentions it mirrors the /agent.txt file. This is a specific verb+resource combination that distinguishes it from the sibling tools, which are all about quantum computing scenarios, expectations, and rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing what the tool returns, but it provides no explicit guidance on when to use this tool versus alternatives or when not to use it. Given the simplicity of the tool (no parameters, read-only), usage is straightforward but could still benefit from a brief contextual note.
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that each datapoint carries a source URL, which is additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, no wasted words. Front-loaded with the core functionality, then usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one param, no output schema, strong annotations), the description is sufficiently complete. It explains what it returns, parameter options, use cases, and sibling tool integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with enum, schema description coverage 100%. Description restates the enum values exactly as in schema, so no added meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full historic time series for either fidelity or qubit-count, broken down by hardware type. It distinguishes from siblings by mentioning pairing with fit_historic_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to extrapolate trends' and 'pair with fit_historic_series', providing clear usage context. Does not explicitly list when not to use, but guidance is sufficient.
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). Same data that powers the website's "Current Quantum Computers" table.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds context that the result mirrors the website table and includes specific fields, but does not detail ordering, number of entries, or pagination behavior. It provides moderate additional value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that directly state the purpose and data source. No redundant or unnecessary information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately explains the return structure (table with specific fields). However, it could mention the response format (e.g., list of objects) or any default order. Still, it is sufficiently complete for a straightforward list retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain them. Per guidelines, zero-parameter tools baseline at 4. The description adds no parameter information, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Return the representative-entry table') and the resource ('current SOTA quantum computers') with detailed columns (id, hardware type, physical qubit count, 2-qubit error rate). It distinguishes from sibling tools by focusing specifically on listing current quantum computers, unlike siblings such as list_example_algorithms or compare_hardware_scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving current quantum computer data but does not provide explicit guidance on when to use this tool versus alternatives like list_hardware_timings or compare_hardware_scenarios. No when-not conditions or prerequisites are mentioned.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read operations. The description adds behavioral context beyond annotations by specifying the exact content of the returned list (qubit count, depth/gate count, source paper URL). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence front-loads the purpose and content; the second adds the utility context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values (qubit count, depth/gate count, source paper URL) and the 'curated' nature. Missing details like output format (array/object) and whether the list is fixed or dynamic, but for a simple list tool, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters; the input schema is empty. With 100% schema coverage vacuously, the description fully compensates by explaining what the output contains (list of algorithms with resource estimates and paper URLs). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the curated list of example quantum algorithms with published resource estimates,' specifying the verb (return), resource (curated list), and key attributes (qubit count, depth/gate count, source paper URL). It distinguishes from sibling tools like 'list_qldpc_codes' by focusing on algorithm examples with estimates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Useful for comparing what algorithms need vs. what hardware can deliver.' This implies when to use (for comparison), but does not explicitly state when not to use or give alternatives. However, the name and purpose are sufficiently distinct from siblings.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: values are 'representative current-generation numbers, not records,' and includes source URLs, going 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence front-loads the core return fields and source URLs. The second sentence provides usage guidance and a caveat. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is remarkably complete. It specifies exactly what data is returned (including units), how it joins with another tool, and its intended use cases. The caveat about representative numbers adds crucial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is trivially 100%. With zero parameters, the baseline is 4. The description does not need to add parameter information, and it correctly does not mention any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns per-platform gate-cycle timings including specific fields (2Q gate time, readout time, SI seconds, representative device, native 2Q gate name, source URLs). It distinguishes from siblings by mentioning it joins list_current_quantum_computers and is used as input to compute_quantum_volume_rate, differentiating it from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is for runtime estimates, ratio analysis, or as inputs to compute_quantum_volume_rate. It provides clear context but does not explicitly exclude alternative uses or mention when not to use it, which would warrant a 5.
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 CatalogARead-onlyIdempotentInspect
Return the catalog of supported qLDPC codes (id, label, family, n, k, d, threshold, prefactor, logicalErrorExponent, source URL). Use a code's id as the errorCorrectionCode input to compute_expectation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe, read-only operation. The description adds that it returns a catalog with specific fields and a usage hint, but does not disclose additional behavioral traits (e.g., whether the catalog is cached, pagination, or rate limits). With strong annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first explains the output, the second gives a practical usage hint. No wasted words, and the most important information (return value and how to use it) is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters, strong annotations covering safety, and no output schema, the description is sufficiently complete. It explains what the tool returns and how to use the output. A minor gap is lack of mention about whether the catalog is static or changes, but for a simple listing tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params), so the baseline is 4. The description correctly does not discuss parameters, as none exist. It adds value by explaining what the output contains and how to use it, but this dimension focuses on parameter semantics, which is a non-issue here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a catalog of qLDPC codes and lists the fields included. It also distinguishes this listing tool from sibling computation tools by explicitly linking its output to `compute_expectation`. The verb 'Return' and resource 'catalog' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage hint: use a code's `id` as input to `compute_expectation`. It implies when to use this tool (to get code IDs), but does not explicitly state when not to use it or list alternative tools. However, the sibling context makes the purpose sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!