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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, so safety is covered. The description adds two useful behaviors beyond that: results are returned 'oldest first' and long recipient lists are truncated with an omittedRecipients count. The truncation sentence is garbled ('A message whose recipients one answer cannot carry names the first that fit'), which blunts its value.

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 first sentence is tight and front-loaded. The second sentence is nearly unparseable and reads like a mangled sentence about recipient truncation, so it costs more in confusion than it returns in information.

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?

An output schema exists, so the description need not explain return values, and the core behavior (read all messages in a thread, ordered oldest first) is present. However, it omits the view-mode choice entirely and the one piece of behavioral prose it does include is confusing rather than clarifying.

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 100%, and the schema fully documents id, mailbox, and the full/summary/headers view enum including what each mode omits. The description adds nothing about any of the three parameters, so the baseline 3 applies.

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 and resource: 'Read every message of one thread in a connected mailbox.' The scope ('every message of one thread') distinguishes it from messages_get and messages_list well enough for selection, though it never names those siblings explicitly.

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 only implied by the tool's narrow scope – read this when you want a whole thread rather than a single message. There is no explicit when-to-use, no mention of the alternative messages_get, and no note on prerequisites such as needing a threadId from a prior search.

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