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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: results disclose per-provider tool gaps and confirm that every listed mailbox's mail is read/written via Multi Mail's tools. It does not discuss ordering, caching, or capability edge cases.

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 sentences of reasonable length, but the first is awkwardly constructed ('mailboxes that answer, each by the name a tool's mailbox input takes') and the second sentence partially restates the same idea about Multi Mail's tooling. Front-loading the core 'list connected mailboxes' action would help.

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 return values need not be spelled out, and annotations cover the safety profile. The description is nearly complete for a zero-param listing tool, with the only notable gap being explicit routing guidance versus sibling list tools.

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?

Zero parameters, so the baseline is 4. The description still earns its place by explaining that the returned mailbox names are exactly the identifiers other tools' mailbox inputs expect, which clarifies how this tool's output maps onto sibling tools' parameters.

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: list the connected mailboxes, and it goes further by noting the result includes each mailbox's canonical name and the tools its provider lacks. It is distinguishable from siblings like messages_list_all_mailboxes, though the phrase 'mailboxes that answer' is vague jargon that slightly muddies the core purpose.

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?

The description implies usage by saying mailbox names are 'the name a tool's mailbox input takes,' which tells the agent these values feed other tools' mailbox parameters. However, it never states when to call this versus alternatives, nor any prerequisites or exclusions.

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