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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the agent knows this is safe and repeatable. The description adds meaningful behavioral context beyond annotations: the polling requirement, the 404 for non-own checks, and the warning that client_id must never be passed. It does not describe the report shape, but with no output schema and a read-only poll operation, the core behavior is well covered.

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 short, information-dense sentences. Every sentence earns its place: what it does, how it behaves (poll), when to use it, and what not to do. Front-loaded with the HTTP method and resource path; no filler.

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 simple one-parameter read-only poll tool with rich annotations, the description covers the essential context: purpose, polling behavior, ownership restriction, and usage sequence. The only notable gap is that it doesn't describe what the returned 'dirt report' contains, but since there is no output schema and the tool is read-only/idempotent, that is a minor omission rather than a critical gap.

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% and there is only one parameter (id). The description does not explicitly re-document the id parameter, but it indirectly clarifies that the id is the identifier of the check/report obtained from kyt_check and that client_id must not be included. For a single required integer id, this provides enough operational context, though explicit naming would have made it flawless.

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 identifies a specific resource (KYT check report) and the action (poll until ready), with the nuance of being read-only. It clearly differentiates the tool from its siblings: it is used after kyt_check and is distinct from kyt_checks, the list endpoint. However, the tool name and title already convey the core purpose, and a slightly stronger statement of the resource would push it to a 5.

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?

Excellent usage guidance: it explicitly states when to use this tool ('Use after kyt_check when a wallet was blocked'), tells the agent it must poll, and gives a critical exclusion ('Never pass client_id'). It also warns of the 404 behavior for non-own checks, which is valuable for an agent deciding whether this is the right call.

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