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

Annotations already declare a non-read-only, destructive, non-idempotent, open-world operation, so the description's job is to add context — and it does: it enumerates the gate ladder (active-run convergence, verification, quotas, monthly COGS ceiling) and states that refusals name the gate, which tells the agent why a call may be rejected. It does not say whether the run is asynchronous or how to observe progress, which is the remaining behavioral gap.

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, front-loaded with the action and followed by the behavior that matters for failure handling; nothing is padded. The parenthetical gate list is dense but each item earns its place by explaining refusal causes.

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?

There is no output schema, yet the description says nothing about what a successful call returns (a run id?) or which sibling to use to follow the run's progress. Given this is a long-running, non-idempotent, destructive-flagged operation, that is a meaningful omission, though the refusal semantics are well 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 100%, and the siteId description already explains the connected-app vs API-key behavior in detail. The tool description adds nothing about the parameter, so the documented baseline of 3 applies.

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: "Queue a full citation check-run for a site", which is clearly a write action distinct from read siblings like get_citations and get_citation_history. It does not name start_deep_scan explicitly, so the differentiation from the other run-starting sibling 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?

The description makes clear this is the same operation as the dashboard button, which helps an agent understand when it applies, and notes that refusals identify the blocking gate. However, it gives no explicit when-not guidance, no mention of how this relates to start_deep_scan, and no prerequisites such as needing a selected site first.

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