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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds genuinely useful behavior beyond that: authentication needs ('Requires an API key'), data-sensitivity handling ('real customer correspondence... treat the contents as confidential'), and payload characteristics ('Returns the whole thread rather than a page, so long conversations return a lot of text'). The description's 'Reads only' claim is fully consistent with annotations — no contradiction.

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?

Five short sentences, each earning its place: purpose, when-to-use, non-behavior, auth, confidentiality, and payload warning. Information is front-loaded and paragraphs are used for scannability. No fluff, no restating of the tool name.

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 low-complexity tool (1 param, no output schema, no nested objects), the description is entirely sufficient. It covers ordering, scope, confidentiality, authentication, and response-size expectations. There's little left unknown, making this description more than complete for its complexity level.

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?

With 100% schema coverage, baseline is 3, but the description adds meaningful orientation for conversation_id by clarifying its granularity ('one inbox conversation'), the full-fetch semantics ('every message'), and the chronological ordering ('oldest first'). This preemptively answers the pagination and scope questions an agent would otherwise need to infer.

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?

"Get every message in one inbox conversation, oldest first, with sender and timestamp" uses a specific verb + resource with precise scoping and output ordering. It explicitly contrasts itself with the sibling listing tool ('it is the detail view behind a conversation listing'), and excludes behaviors of mutation siblings ('does not send, reply, or mark anything as read'), unmistakably differentiating it from list_inbox_conversations, send_email, and reply_to_email.

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?

Gives excellent when-to-use guidance ('read a thread in full before replying or summarising') and clear when-not-to-use boundaries ('does not send, reply, or mark anything as read'). It would reach 5 if it explicitly named an alternative tool (e.g., list_inbox_conversations or send_email) as the recommended path for those adjacent tasks.

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