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

Beyond the annotations (openWorldHint, idempotentHint), the description discloses billing ('included, no new payment'), a retry budget (up to 3 capture attempts), the refund consequence, idempotency semantics ('same immutable evidence'), and an explicit negative scope (no ranking, indexing, JS rendering, or functionality certification). This is unusually rich operational context for a single call.

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 action is front-loaded and the following sentences each carry distinct information (billing, retries, refund, idempotency, report contents, exclusions). Slight redundancy between 'included, no new payment' and the refund clause, but overall dense and purposeful.

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 return burden and does so by enumerating what the report covers (unexpected changes, missed values, noindex, missing canonical/title, broken JSON-LD) and what it explicitly does not certify. The main omission is any explanation of the order_id input.

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% for the single order_id parameter, and the description never mentions it or explains how it identifies the purchased baseline. With one undocumented parameter, the description fails to compensate 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?

The description states a specific verb and resource: capture the same page and compare it against the purchased baseline, triggered after the client publishes. This differentiates it from siblings like inspect_page and start_publication_check, though the exact boundary with start_publication_check is left implicit.

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 gives a clear trigger ('After the client publishes') and a prerequisite (an existing purchased baseline), which implies when to call it. However, it never names an alternative tool or states an explicit when-not-to-use condition relative to kanonyr_inspect_page or kanonyr_start_publication_check.

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