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

Annotations declare readOnlyHint=false and idempotentHint=true; the description explains exactly why a read-shaped tool mutates state by disclosing the e-mail side effect ('sends the full report by e-mail if it has not gone yet') and makes the idempotency comprehensible via 'if it has not gone yet'. It also adds the 2-day scan ID expiry, a hard behavioral constraint not present in the schema or annotations.

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 compact clauses: what it returns, the e-mail side effect, the expiry rule. Purpose leads and nothing is padded, though the opening noun phrase ('Result of a scan started with ... that was still running') is slightly tangled and would read better as an imperative.

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-value burden and does so by naming the payload ('same grade and problem list') and the e-mail delivery. It omits what happens if the scan is still incomplete or what an expired/invalid scan_id produces, which are the remaining gaps for a 1-parameter retrieval 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 coverage is 100% (type, pattern, and 'the scan_id returned by the scan tool'), so the baseline is 3. The description earns one more point by adding the parameter's lifetime semantics — scan IDs are invalid after 2 days — which tells the agent when the value it holds will stop working.

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 retrieval action (get the result of a previously started scan) and explicitly names the three sibling tools that produce those scans (scan_analytics, scan_ai_visibility, scan_google_visibility), so an agent can immediately distinguish 'start a scan' from 'fetch a scan's result'. It also pins the scope: results for scans that were still running when the scan tool returned.

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 clear context for when this tool applies — after one of the three named scan tools returned a still-running scan. It does not state what to do if the scan is not yet finished, nor whether to poll, wait, or how often to call, so the guidance stops short of full when/when-not coverage.

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