Quantum Expectations

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

Annotations already declare read/write and idempotency hints. The description adds valuable behavioral context: it aggregates multiple hardware runs into one call and defaults to all entries in list_current_quantum_computers. This goes beyond the annotations and helps the agent understand the tool's scope and default behavior.

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 with no filler. It front-loads the main purpose and then provides the key default behavior, making it efficient and easy to scan.

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 sufficient for the core use case but lacks details about return values (no output schema) and the error correction parameters' conditional relationships. Given the tool's complexity, a mention of what the comparison output looks like or how error correction works would make it more 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?

The description adds meaning for hardwareIds by explaining its omission default, but it doesn't clarify the required circuit parameters (numQubits, compDepth) or useErrorCorrection. Schema descriptions cover three parameters, and the remaining are self-explanatory by name, but the description could have compensated more for the 50% schema coverage.

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 runs the same circuit against multiple hardware entries in one call to rank platforms. It uses a specific verb ('Run') and identifies the resource ('multiple current SOTA hardware entries'), and it distinguishes itself from the sibling compute_expectation by noting it avoids N sequential calls.

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 contrasts with compute_expectation ('without N sequential compute_expectation calls'), providing clear when-to-use guidance. It also states the default behavior when hardwareIds is omitted, but it doesn't explicitly mention situations where compute_expectation would be preferred (e.g., single hardware comparison).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only operation. The description adds useful behavioral context beyond annotations: the response is self-describing (formulas, assumptions, caveats, glossary, SOTA hardware, historic series with source URLs) and that verbose=false omits these sections. This adds value without repeating annotation data.

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 that front-load the main purpose, then provide a compact note on response richness and verbosity control, then give alternatives. No wasted words; 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 the tool has 8 parameters and no output schema, the description is remarkably complete. It states what is computed, that the response is self-describing (mitigating missing output schema), and when to use siblings. It also covers the main inputs (p, n, d) and optional error-correction choices. This is sufficient for an agent to invoke 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 description coverage is 50%, and the description adds meaning for the core inputs by naming '2-qubit error rate p, qubit count n, depth d' and 'optional surface-code or qLDPC overhead.' However, it does not elaborate on the exact semantics of distanceSurfaceCode, useErrorCorrection, or the exclusivity between qubitErrorRate and hardwareId beyond what the schema already states. The description partially compensates for the coverage gap but not fully.

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 uses a specific verb 'compute' and identifies the resource: 'effective error rate, success probability, and optional surface-code or qLDPC overhead' from a quantum circuit. It distinguishes from siblings by explicitly naming compute_required_error_rate (inverse) and compare_hardware_scenarios (ranking).

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?

Explicit guidance is given: 'For the inverse... use compute_required_error_rate; to rank multiple platforms in one call use compare_hardware_scenarios.' It also advises when verbose=false is appropriate ('Use for parameter sweeps'), providing clear context on when to use this tool vs alternatives.

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

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

Annotations already mark the tool as read-only and idempotent, and the description aligns: 'computes numbers only'. It adds valuable behavioral context: reports under two logical-error fits, returns an 'infeasible' block when no solution exists, and instructs the agent to state caveats. No contradictions with 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 dense but front-loaded with the core purpose, then adds critical caveats. Every sentence contributes functional information; slight verbosity in the caveat sentence, but no wasted words. Still, it could be tightened slightly without losing 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?

Despite no output schema, the description names all key outputs (factory choice, tile layout, code distance, total qubits, wall-clock time), covers the infeasible edge case, and explicitly states what it does not do (classical comparison). This is complete for a complex 7-parameter tool without hidden expectations.

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 description coverage is 100%, and each parameter is already well-documented (e.g., tCount convention, cycleTimeSeconds references). The description's mention of the input tuple '(numLogicalQubits, tCount)' and 'physical error rate (or hardwareId)' adds framing but not new per-parameter semantics beyond the schema. 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?

The description states a precise action ('derive the full surface-code + magic-state-distillation footprint') with a specific resource and input. It clearly distinguishes itself from siblings by noting 'computes numbers only' and leaving classical comparison to the agent, which is absent in other 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?

Explicitly tells when not to use it for classical comparisons ('comparing against classical alternatives and concluding ... stays with you') and gives usage instructions like 'always state both' fit results. It doesn't explicitly name alternative tools, so slightly less direct than naming siblings, but the guidance is clear.

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

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

Beyond the read-only and idempotent annotations, the description openly discloses that the metric overstates real-world performance and specifies omitted factors (reset/SPAM, mid-circuit measurement, classical latency). This gives the agent critical caveats for interpreting results.

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 tightly packed sentences: definition+formula, assumptions and caveats, alternative guidance. No filler, all information is unique and necessary.

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?

For a simple computation tool with no output schema, the description fully covers definition, formula, assumptions, limitations, and alternatives. It is self-contained and leaves no significant gaps.

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 schema already provides full descriptions and examples for all three parameters (100% coverage). The description adds value by showing exactly how each parameter fits into the formula (V_Q, t_2Q, t_meas), which reinforces semantic understanding 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 defines the tool as computing Quantum Volume Rate with an explicit formula (QVR = V_Q / (log2(V_Q) * t_2Q + t_meas)). It identifies the resource (quantum device) and metric, and distinguishes from sibling compute tools by focusing specifically on throughput rate rather than expectation values or resource estimation.

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?

Provides explicit usage guidance: labels it as a 'first-order estimate', warns that it 'OVERSTATES achievable rate', and points to a production-grade alternative (IBM's CLOPS) with a citation. This tells the agent when to use this tool vs. alternatives.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable context beyond annotations: it returns a comprehensive output for every EC option (no-EC, surface-code, qLDPC) and filters current SOTA hardware, implying an integration with hardware data. This goes beyond just 'safe read' and enriches behavioral understanding.

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 three sentences, front-loading the key relationship ('Inverse of compute_expectation') and then listing the exact outputs and the question it answers. Every sentence is informative, with no wasted words or repetition.

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?

With no output schema, the description carries the burden of explaining return values, and it does so at a high level: required per-gate logical error rate, physical error rates per EC option, and qualifying hardware. It also situates the tool within the sibling set by naming the inverse relationship. Minor gaps include not specifying output format or units, but the description is complete enough for the tool's complexity.

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?

Input schema covers 100% of parameters with descriptions, so baseline is 3. The description mentions the parameters (numQubits, compDepth, acceptableErrorRatePercent) but does not add additional semantic detail beyond what the schema already provides. It merely restates them in context, so no extra value is added.

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's function: it is the inverse of compute_expectation, computing required per-gate logical error rate and physical error rates for each EC option, plus qualifying current SOTA hardware. This specific verb+resource ('return') and the concrete output list distinguish it from siblings, especially 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 positions the tool as the inverse of compute_expectation, which tells the agent when to use it (when needing required error rates given an acceptable error rate) and implicitly when to use the alternative (compute_expectation). It also answers a clear question, 'what hardware do I need to run this algorithm?', providing concrete usage context.

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

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 safe read-only behavior is known. The description adds valuable behavioral context beyond annotations: it discloses that residualStdDev is the BIASED maximum-likelihood RMS (divides by n, not n-2) and advises inflation for small series. This is a subtle statistical behavior that the schema/annotations do not convey.

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 with no wasted words. The first sentence defines the core operation and formula, immediately communicating what the tool does. The second sentence explains usage context and the statistical caveat. Every phrase earns its place, and the structure is front-loaded with the essential purpose.

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 mathematical nature of the tool, the description explains the fitting formula, the series types, and the composition use case. It also discloses the residualStdDev bias, which is critical for statistical inference. However, it does not enumerate all expected return values (e.g., slope, intercept, r-squared) beyond mentioning residualStdDev and yearAtTargetValue (in schema). Since there is no output schema, a bit more about the response shape would be helpful, but the current description is largely sufficient for a fit primitive.

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 description coverage is 100%, with detailed descriptions for seriesType, targetValue, and hardwareType. The tool description reinforces these concepts (fidelity/qubit-count, hardware type) but does not add new semantic details beyond what the schema already provides. The residualStdDev note is about an output, not a parameter. Baseline 3 applies because the schema carries the parameter documentation burden.

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 fits a log-linear trend (ln(value) = slope * year + intercept) to one historic series (fidelity or qubit-count) for one hardware type. It uses a specific verb (fit) and identifies the resource (historic series), and distinguishes itself as an 'atomic primitive' relative to sibling tools like list_current_quantum_computers and compute_required_error_rate.

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 clear usage context: it is meant to be composed with other tools to answer 'when might hardware reach X?'. It names specific siblings (list_current_quantum_computers, compute_required_error_rate) as composition partners, but does not explicitly state when not to use it or provide exclusions. This is clear context without full when-not guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds context beyond annotations by specifying the content of the brief and that it mirrors /agent.txt, which indicates a static, well-defined return value. No contradictions with 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 exactly two sentences, front-loaded with the action ('Return'), and every word adds value. It concisely states what the tool returns, the content included, and the source document.

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?

With no parameters and no output schema, the description provides sufficient information for an agent to understand what this tool does and what to expect. It fully explains the return value's purpose and source, making the tool self-contained.

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, and the schema is an empty object. Per the rubric, the baseline for 0 params is 4. The description appropriately adds no parameter information because none exist.

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 'Return the plain-text site brief' with specific content details (scope, assumptions, honesty clause, API contract). It distinguishes itself from the sibling tools, which are all about hardware/computation or data retrieval, by being a meta-document about the agent itself.

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 context: it returns the agent's brief for understanding scope and rules. No explicit alternatives or exclusions are mentioned, but the context is clear enough that an agent would know to call this when it needs the site brief. Sibling tools have no overlap, so lack of explicit exclusions is acceptable.

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

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

Annotations already declare read-only and non-destructive behavior. The description adds valuable context that each datapoint carries a source URL and that the series is broken down by hardware type, enriching the behavioral model without contradicting 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 sentences, front-loaded with the core purpose and then adding usage guidance. Every sentence earns its place with no unnecessary repetition or filler.

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 one fully-documented parameter, comprehensive annotations, and a description that covers output characteristics (source URL, breakdown) and companion tools, the description is complete for effective tool invocation.

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 for the sole parameter seriesType is 100% with a clear enum and description. The description reinforces these semantics but does not add new parameter-specific information beyond what the schema already provides.

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 itself from siblings by specifying 'full' and 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 states when to use: for extrapolating trends and pairing with fit_historic_series for a log-linear fit. This provides clear context on the tool's application and its relationship to alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds meaningful context by noting the table is 'representative-entry' and 'current SOTA', and that it matches the website's data. This clarifies the curated, live nature of the result beyond the structured hints.

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, each earning its place: the first defines the output, the second provides provenance. No redundant or vague text.

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?

For a zero-parameter, read-only list tool with no output schema, the description is complete: it specifies exact return columns and the data source. Annotations cover safety, and no further behavioral detail is necessary.

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 and schema coverage is 100%, so the baseline is 4 per the rubric. The description adds no parameter-specific info, but none is needed.

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 explicitly states the tool returns a representative-entry table of current SOTA quantum computers, enumerating specific columns (id, hardware type, physical qubit count, 2-qubit error rate). This is a clear verb+resource combination that distinguishes it from sibling list tools like list_example_algorithms.

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 clear context for when to use this tool: to obtain the current SOTA quantum computer data, noting it powers the website's table. While it doesn't explicitly state alternatives or exclusions, no direct sibling offers the same data, so the usage context is sufficient.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds value by revealing output structure: the list contains published resource estimates with specific fields (qubit count, depth/gate count, source URL). This helps set expectations beyond what annotations convey.

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, front-loaded with the primary action, and contains no redundant or filler content. Every phrase contributes meaning.

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 is simple (zero params, good annotations) and has no output schema, the description adequately communicates the return values and the purpose. It specifies the key fields included in the list, making it complete for an agent to select and invoke 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?

The tool has zero parameters, so the schema fully covers all inputs. Per the rubric, a zero-parameter tool gets a baseline of 4; there is nothing more to explain.

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 curated list of example quantum algorithms with resource estimates, specifying fields like qubit count, depth/gate count, and source paper URL. This distinguishes it from sibling list tools such as list_current_quantum_computers (hardware) and list_qldpc_codes (codes).

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 mentions a use case: 'Useful for comparing what algorithms need vs. what hardware can deliver.' It provides clear context but does not name alternatives or exclusions, such as when to use compare_hardware_scenarios instead.

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

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

Beyond the readOnly/idempotent annotations, the description explains the join behavior via hardwareType and the important caveat that values are representative current-generation numbers, not exact records. This adds meaningful context about data provenance and reliability.

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 concise, purposeful sentences: return value, usage context, and data caveat. No redundancy, with the core purpose front-loaded.

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?

With no output schema, the description fully covers the return content, units, source URLs, and the representative nature of the values. Combined with strong annotations, it is complete for the tool's simplicity.

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, so the schema provides no details to enrich. The description appropriately focuses on output semantics instead, meeting the baseline for parameterless tools.

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 with specific data fields (2Q gate time, readout time, representative device, gate name, source URLs). This distinguishes it from siblings like compute_* tools and list_current_quantum_computers.

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?

It explicitly says 'Use for runtime estimates, ratio analysis, or as inputs to compute_quantum_volume_rate.' This provides clear when-to-use guidance, and mentioning the join to list_current_quantum_computers implicitly indicates the relationship to that alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds meaningful context by explaining the semantics of 'prefactor' and 'logicalErrorExponent' and by linking to compute_expectation. It does not describe pagination or return envelope, but that is not critical for a catalog list.

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 a single, information-dense sentence followed by a short, actionable instruction. The front-loaded verb and resource ('Return the catalog') immediately identify the purpose. Every part of the description adds value: the field list, the explanation of derived values, and the cross-reference to compute_expectation.

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 that there is no output schema, the description compensates by listing all returned fields (id, label, family, n, k, d, etc.) and their semantics. It also gives a practical usage context. It might be improved by mentioning whether the list is exhaustive or ordered, but for a read-only catalog tool with no parameters, this is largely 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?

The tool has zero parameters, and the input schema is an empty object. Per guidelines, 0 params gets a baseline of 4. The description does not need to explain parameters, and it does not claim 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 uses a specific verb 'Return' and a specific resource 'catalog of supported qLDPC codes', listing the exact fields included. It clearly distinguishes this tool from sibling list tools (e.g., list_current_quantum_computers, list_example_algorithms) by scoping to qLDPC codes.

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 tells the user when to use this tool: to obtain the catalog of qLDPC code metadata. It also provides a direct downstream usage: 'Use a code's id as the errorCorrectionCode input to compute_expectation.' This gives clear context, though it does not explicitly mention alternatives or exclusion cases.

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