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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds that the result includes availability, queue lengths, qubits, and gates, which is useful context, but it does not disclose pagination, refresh behavior, or rate-limit constraints.

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?

A single front-loaded sentence listing the resource and its key attributes. There is no filler or repetition, and the important scoping phrase ('for an instance') is placed at the end without obscuring the main action.

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?

An output schema exists and rich annotations cover the safety profile, so those do not need repeating. However, with two optional parameters at 0% schema description coverage, the description does not fully equip an agent to use the min_num_qubits filter or understand the instance parameter.

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 0%, so the description must explain both parameters. It mentions 'instance' but does not clarify whether it is optional, what a valid instance identifier looks like, or that min_num_qubits filters the returned backends. The parameter meaning is therefore largely left to inference.

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?

States a specific verb ('List') and resource ('accessible QPUs'), and enumerates the returned attributes. It does not explicitly differentiate itself from sibling tools such as quantum_instances, but the purpose is clear.

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 phrase 'for an instance' implies scoping but gives no explicit guidance about when to use this tool versus quantum_instances, quantum_configuration, or other siblings. There are no exclusions or alternative-routing instructions.

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 the destructive, idempotent, open-world, and non-read-only nature of the tool. The description adds meaningful cost context beyond annotations by warning that already consumed QPU time remains consumed.

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 action and followed by an important caveat. There is no wasted wording.

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 annotations and output schema cover much of the safety and return-value context, and the description adds a useful QPU cost warning. Still, it does not document the optional instance parameter or explain cancellation semantics such as whether the request is asynchronous.

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 0%, so the description must explain the parameters. It only refers vaguely to a 'specified unfinished IBM job' and does not explain the required job_id or the optional instance parameter.

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 a specific action and target: cancellation of an unfinished IBM job. This distinguishes it from sibling job listing, detail, simulation, and run tools, though it does not explicitly name an alternative.

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 word 'unfinished' implies the tool applies only to active jobs, giving some usage context. However, there is no explicit when-to-use guidance, no when-not guidance, and no reference to sibling 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 the operation as read-only, idempotent, non-destructive, and closed-world. The description adds meaningful security context beyond annotations: it confirms that credential presence is reported without reading or returning the API key, which is important for choosing this tool safely.

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 front-loaded sentence with no redundant or filler content. Every phrase contributes to clarifying scope or security behavior.

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 zero parameters, an output schema, and rich annotations, the description is complete enough for an agent to invoke the tool correctly. It explains the purpose and the key security constraint without needing to describe return structure.

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 fully described, so the baseline is 4. The description does not need to explain parameter semantics in this case.

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 names a specific verb ('Show') and concrete resources ('credential presence' and 'configured limits'), making the tool's purpose immediately clear. It does not explicitly distinguish itself from any sibling, but its configuration/credential focus is naturally distinct from the job, backend, and instance 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?

Usage is implied by the description: an agent can infer this is the tool to call when it needs to check whether credentials exist or what limits are configured. There are no explicit when-to-use or when-not-to-use instructions, and no alternatives are named.

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, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds useful context: it performs IBM authentication and returns CRNs/names/plans without submitting compute, which the 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?

A single front-loaded sentence with the authentication action and the return content stated up front, then the side-effect boundary. No wasted words.

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 discovery tool with an output schema and full annotation coverage, the description covers what it does, what it returns, and that it has no compute side effects. Nothing an agent needs is missing.

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 takes zero parameters, so the baseline is 4. The description adds nothing to explain about inputs because there are none, and 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?

States a specific verb (list) and resource (accessible instance CRNs, names, plans) plus the authentication step. The clause 'no compute is submitted' cleanly separates it from the run_* and simulate siblings.

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?

'no compute is submitted' signals this is the discovery/auth step rather than an execution tool, implying when to use it. It stops short of naming an explicit alternative or sequencing guidance (e.g., call before quantum_jobs/quantum_backends).

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 readOnly, idempotent and non-destructive, and the description adds genuinely new behavior: the call is non-blocking by default and large result sets are explicitly flagged as truncated with a 20-PUB cap. It could still say what happens if the job is still queued (empty vs partial result).

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 short sentences, front-loaded with purpose then default behavior then result shape. No filler; the truncation note could arguably move earlier but nothing is wasted.

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?

An output schema exists so return-shape detail is not required, and the description adequately covers blocking behavior and truncation. The main residual gap is the meaning of 'instance' and how it selects a target, which neither schema nor description explains.

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 0%, so the description must compensate. It clarifies the default non-waiting behavior (wait_seconds) and the result-size limit (max_counts/PUB cap, include_results), but leaves 'instance' and the exact relationship between max_counts and the 20-PUB truncation unexplained.

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?

States a specific verb and resource: read a job's status and results. It implicitly contrasts with quantum_jobs (listing) and quantum_cancel_job, though it never names a sibling explicitly and the single-job-by-id scope is only implied by the required job_id.

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?

"Default does not wait for queued work" hints that wait_seconds is opt-in for polling, but it never states when to use this versus quantum_jobs, quantum_preview, or a retry pattern. Guidance is implied rather than explicit, and no exclusions are given.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the duplicate-checking rationale, which is genuinely useful context, but it omits ordering guarantees ("recent" implies newest-first without saying so) and says nothing about what the pending filter changes in the result set.

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 short sentences, front-loaded with the core action, then paging, then the usage trigger. No filler or restatement of the tool name.

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?

An output schema exists, so return values need no explanation, and the paging story is at least gestured at. But for a four-parameter read tool with zero schema descriptions, leaving the pending filter and the limit cap unexplained is a real gap an agent could trip on.

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 0%, so all four parameters depend on the description. It explains skip-based paging and implies instance, but limit and especially pending (a nullable boolean filter with no stated meaning) are left entirely undocumented.

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?

"List recent jobs for an instance" states a specific verb (list) and resource (jobs) with scope (per instance), which is enough to separate it from the singular quantum_job sibling. It never names that sibling explicitly, so differentiation is implied rather than stated.

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?

"Use after ambiguous submission errors to avoid duplicates" gives a concrete triggering scenario that an agent can act on. It offers no exclusions or named alternatives (e.g., quantum_job for a single job, quantum_cancel_job for stopping one), so the routing is clear in one direction only.

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, non-destructive, and open-world behavior, so the description only needs to add context. It usefully clarifies that no job is submitted and that the output is depth/gate-count reporting, though it does not mention backend access requirements or external-call 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 a single front-loaded sentence with no redundant or filler content. The key action and the no-job constraint appear immediately.

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?

Although an output schema exists and annotations cover safety, the description does not compensate for the 0% input-schema description coverage. It leaves the measured flag, instance parameter, and circuit structure unexplained, which matters for correct 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 description coverage is 0%, so the description must carry parameter meaning. It only indirectly covers backend_name and the circuit concept, and does not explain the circuit format, the optional instance parameter, or the measured flag.

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 and resource: transpile a circuit for an IBM backend and report depth/gate counts. The phrase 'without submitting a job' clearly distinguishes it from the job-submitting siblings such as quantum_run_sampler and quantum_run_estimator.

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 implies the tool should be used for previewing transpilation metrics before running a job, but it does not explicitly name alternatives or state when not to use it. The 'without submitting a job' clause gives useful context, but selection guidance remains implicit.

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 mark this as non-read-only and open-world, but the description adds genuinely new behavior: the default is a preview with no hardware submission, and a false dry_run submits real work. It also clarifies that shots are per measurement configuration, which affects cost/runtime expectations. It doesn't mention whether submission returns an async job needing polling (siblings include quantum_job and quantum_cancel_job), which would complete the picture.

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?

Four short sentences, each carrying distinct information, with the core purpose front-loaded and the safety-relevant dry_run note placed last. No 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?

With an output schema present, the description doesn't need to explain return values, and it covers the two most error-prone semantics (Pauli qubit ordering and per-configuration shots). Gaps remain around backend/instance selection and whether the call is synchronous or returns a job handle, which matter for a hardware-submitting tool.

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 0%, so the description carries the full burden. It usefully explains the observable encoding (rightmost Pauli character is qubit 0), shots semantics, and dry_run, but leaves four of seven parameters (backend_name, instance, max_execution_seconds, coefficient) entirely unexplained in both schema and description.

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?

States a specific verb and resource: 'Estimate one weighted Pauli-sum observable.' That cleanly separates it from the sampler/simulator siblings, which sample bitstrings rather than expectation values. It stops short of naming a sibling directly, but the estimator-vs-sampler distinction is clear from the wording.

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 through the dry_run sentence ('False submits hardware work; default previews only'), which tells the agent how to preview safely. It never states when to choose this over quantum_run_sampler or quantum_simulate, and gives no exclusion conditions or prerequisite 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 non-readonly, non-idempotent, open-world, non-destructive, so the safety profile is covered. The description adds real value on top: quota consumption, asynchronous return of a job ID rather than results, and that dry_run is a preview-only mode by default.

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 short sentences with zero waste, front-loading the action, then the safe default, then the consequence of overriding it. 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?

The highest-stakes decision (dry_run vs. submit) and the async job-ID return are covered, and an output schema exists so return values need no explanation. But for a 6-parameter quantum submission tool with no schema descriptions, missing shots/backend/max_execution_seconds semantics and no sibling differentiation leave notable 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?

Schema description coverage is 0%, so the description must carry the burden, and it only fully explains dry_run's semantics and default. Shots, backend_name, instance, max_execution_seconds, and the circuit structure receive no explanation anywhere, leaving cost and targeting behavior undocumented.

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?

States a specific verb and resource ("Sample a circuit") plus the measurement scope ("measuring all qubits"). It does not, however, differentiate itself from the closely named siblings quantum_simulate and quantum_preview, so an agent must infer the boundary.

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?

"Default dry_run previews only. False submits one quota-consuming job" gives a clear decision rule with a cost consequence, which is exactly the guidance an agent needs before invoking. It stops short of naming the alternatives (quantum_preview, quantum_simulate) or explaining when each is preferred.

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: a 20-qubit practical ceiling (tighter than the schema's 256 maximum) and that all qubits are measured at the end. It says nothing about shots/seed effects on results, but the key operational limits are disclosed.

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 short sentences with no filler; the capability bound and the auth/cost constraint come first, with the measurement behavior trailing. Nothing could be cut without losing information.

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?

An output schema exists, so return-value explanation is not needed, and the annotations cover the safety profile. The 20-qubit bound is the crucial missing piece the schema cannot express (its max is 256), and the description supplies it; only the seed/shots semantics remain lightly covered.

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 0%, so the description would need to carry parameter meaning. It does hint at num_qubits ("up to 20 qubits") and at the terminal measurement behavior, but neither seed nor shots is mentioned, and the circuit/gate structure is left entirely to the schema's enum and nested description.

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?

"Simulate up to 20 qubits locally" gives a specific verb and resource plus a hard capability bound, and "without IBM authentication or charges" implicitly separates it from the quantum_run_sampler / quantum_run_estimator siblings that presumably hit IBM backends. An agent can pick this tool without opening any sibling schema.

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 phrase "without IBM authentication or charges" establishes a clear selection context: use this when you want local, free, auth-free execution. It stops short of naming the alternative (quantum_run_sampler) and stating when that one is required, so the routing signal is strong but not explicit.

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