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

The description discloses behavior the annotations do not: result ordering (oldest first for messages, newest first for notes_changed), the fact that reading does not consume messages, that a notes cursor advances per-role, and that the cursor has consequences for later calls. This is exactly the kind of side-effect context the readOnly/idempotent hints do not convey; note the cursor advance sits in mild tension with idempotentHint, but the description is accurate and does not mislead.

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 sentences with no filler: primary behavior first, then the persistence guarantee, then the two auxiliary result sets with their orderings and the escape hatch (get_note). Every clause carries information an agent needs.

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 six parameters, 100% schema coverage, and no output schema, the description carries the return-shape burden itself and does so by naming all three response components and their sort orders. An agent can call this correctly and interpret the result without further documentation.

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%, so the baseline is 3; the description earns a bump by explaining the rationale behind the unread_only default ('a check-in that stops halfway loses nothing') and the consequence of the notes cursor that underlies peek. It does not discuss limit, after_id, or project_id, but those are fully documented in the schema.

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 concrete verb+resource (a role's mailbox, oldest first) and enumerates all three things it returns — messages, notes_changed, always_notes — so an agent knows this is a compound read, not just an inbox. It differentiates from get_note and mark_messages_read by naming them, but never addresses the obvious overlapping sibling list_agent_messages, leaving that boundary to inference.

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 operating context: default is unread-only, messages persist as unread until mark_messages_read, and get_note should be used to fetch note bodies. That is strong guidance for the check-in workflow, but there is no explicit when-not-to-use or alternative selection rule (e.g., versus list_agent_messages or when to pass peek instead).

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