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

No annotations are supplied, so the description carries the full burden, and it does disclose the essential behavior: this is a read-only poll, it reports a state machine of five statuses, and it returns supplemental detail ('when it goes out', 'when', 'why'). It does not mention whether the record disappears after completion, how long terminal states remain queryable, or any rate limit on polling, which are meaningful gaps for a polling tool.

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: the core action and the accepted id sources come first, then the status enumeration, then the polling trigger. Every clause carries information an agent needs, and the parenthetical detail is terse rather than bloated.

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 one-parameter, annotation-free tool, the description covers the essentials: input provenance, the status vocabulary, and the extra fields returned with scheduled/sent/failed states, which partly compensates for the absent output schema. It stops short of describing the full response shape or record lifecycle, so it is solid but not exhaustive.

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% and the single parameter's schema description already says 'The id send_message, react_to_message or delete_message returned.' The description restates that same provenance nearly verbatim, so it adds no new syntax, format, or constraint detail beyond the structured schema. Baseline 3 applies when the schema does the heavy lifting.

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 ('Check on') and a single resource ('one message, reaction or deletion you queued'), and enumerates the outcomes: scheduled, sending, sent, failed, canceled. It also names the sibling tools whose returned ids are accepted (send_message, react_to_message, delete_message), which separates it from list_outbox for others. An agent can identify both the action and the object without opening the schema.

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?

'Poll this after a send to know it went out' gives a clear trigger and a clear goal for using it. What is missing is guidance on when not to use it or what to use instead — for example, whether to use list_outbox for bulk status or cancel_message if the poll finds the message still scheduled — so it remains clear-but-not-exhaustive rather than full when/when-not routing.

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