Verify SCITT receipt

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

Annotations already cover readOnly/idempotent/openWorld/destructive, so the bar is lower, yet the description still adds real behavior: fail-closed semantics with error code -32082 when no hook is configured, and the guarantee that a missing verifier cannot read as a pass. That is exactly the kind of failure-mode context annotations cannot express.

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 tight sentences, front-loaded with the purpose and the sibling contrast, followed by the failure behavior and read-only guarantee. No sentence is redundant or restates the schema.

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 verification tool with no output schema, the description covers purpose, sibling distinction, and the failure path thoroughly. It could still say what a successful verification yields (e.g. a boolean verdict vs a receipt echo), so it is nearly but not fully 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 description coverage is 100%, so the schema documents workspace, from, and the nested receipt object itself; the description adds only the semantic framing that the receipt comes from an external service. Baseline 3 applies since the structured schema carries the parameter 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?

States a specific verb (Check) and resource (a receipt returned by an external SCITT transparency service), with the outcome spelled out ('confirming that service logged the statement'). It explicitly names the sibling it is not — chap.audit.verify_chain — and draws the boundary between them.

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 routes the agent between this tool and chap.audit.verify_chain ('the two answer different questions'), which is strong when-to-use guidance. It stops short of naming the precondition that produces the input (a receipt from chap.audit.submit_to_scitt) or an explicit when-not clause, so it's clear context rather than full routing.

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