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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new behavior — that results can come back as waiting/complete/incomplete and that wait_seconds (max 25) blocks for results. It still doesn't say whether results are stable, cacheable, or how costly polling is.

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 compact sentences with no filler. It is front-loaded with return contents and closes with the actionable wait_seconds hint, though leading with the tool's action rather than its output would be marginally stronger.

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 and 4 parameters, the description carries the return-value burden well by naming each result field and its possible states, plus the wait behavior. The only notable gaps are check_id semantics and what to do on an 'incomplete'/'waiting' result.

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 50%: token and api_key are documented in-schema, the description covers wait_seconds including its 25-second cap and its blocking purpose. check_id, however, is undocumented in both places, so the description only partially compensates for the coverage 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 enumerates exactly what a call returns (status, label, caller name, flagged, screenshot link), which makes the retrieval behavior clear even though the opening phrase is a noun phrase rather than an explicit verb+resource. It does not name a sibling tool to differentiate from, e.g. get_coverage, but the returned fields are distinctive enough for selection.

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 implies the step after start_check by saying the token comes 'from start_check,' and it tells the agent to set wait_seconds to wait for results. However, it never states when this tool should be preferred over get_coverage or what to do if the status is 'waiting' (retry? call again?), leaving timing guidance partially inferred.

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