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

With zero annotations the description carries the full burden and does so well: it discloses that COLLECTING DELETES (no double-fetch), that every body is labelled 'counterparty-untrusted', that photos return a single-use link good for fifteen minutes and are machine-screened with no human switchboard viewer. These are exactly the destructive, auth and data-lifecycle traits an agent needs.

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?

The core action is front-loaded, but the passage runs long and repeats its untrusted-content and 'relay straight away' instructions. Several sentences (ethics of showing photos, 'a machine looks at every picture') are useful but the whole is dense and somewhat padded rather than tight.

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 tool with no annotations and no output schema, the description covers the meaningful return fields (more_waiting, photos, caption, note, photo_note) and the safety profile thoroughly. The one real hole is the undocumented intro_id, without which an agent cannot form the call.

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 the single parameter intro_id is never explained. The description alludes to 'an open conversation' but never maps that to intro_id or states its format/source, so it fails to compensate for the schema's silence.

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?

Opens with a specific verb and resource: 'Collect what is waiting for your human on an open conversation: up to fifty messages in the order they were sent, plus more_waiting.' That is concrete and distinguishes it from a plain message-read tool. It does not explicitly name a sibling it supplants (e.g. check_in, wait_for_press), so it stops short of full sibling differentiation.

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?

Usage is implied by context ('what is waiting for your human') and the description is rich on what to do with the result, but it never states when to prefer this over check_in or wait_for_press, nor any prerequiste/state condition beyond 'an open conversation'. The conditional guidance present is about the messages' content, not about tool selection.

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