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

It discloses the verification ladder in detail — Clifford tableaus, all-basis-state checks to 8 qubits, rewrite-based proofs, random product states to 22 as evidence rather than proof, and unchecked results with reasons — plus refusal behavior and the local-command fallback. This is far beyond the readOnlyHint annotation and consistent with it.

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 purpose is front-loaded and every sentence carries substantive information about verification levels, outputs, and refusals. The prose is dense and could be broken up, and the aside 'as every tool's verdict states it' is tangential, but there is little waste.

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 high-complexity, read-only equivalence checker with an output schema, the description covers the decision procedure, the confidence tiers, and refusal behavior well. The main omission is the expected input format for the two program parameters, which is not recoverable from the schema.

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 parameters, but it only says 'two programs' and never specifies whether `a` and `b` are QASM strings, file paths, or job identifiers. The mapping to the two required parameters is inferable, but the format an agent must supply is not.

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 specific decision — whether two quantum programs are the same circuit up to global phase — and distinguishes itself from diagnostic siblings like qasm_diagnostics or critique_qasm by naming the exact question it answers. An agent can tell this is an equivalence checker, not a compiler or repair 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?

Usage is implied by the purpose (compare two programs for equivalence) and the escape hatch ('a check that would take long here is refused with the command that runs it locally') is a useful operational cue. However, it never names an alternative sibling or an explicit when-not-to-use case, leaving the agent to infer routing.

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