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

Annotations already declare this is a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower; the description still adds real value by disclosing the returned metrics (sent count, unread, read share, unsubscribe mechanism), the 'Suggested' heuristic, and that status defaults to active. It stops short of disclosing paging limits, total counts, or ordering defaults for 'recent'.

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?

Front-loads the resource and row shape before the filter semantics, so an agent gets the essentials in the first clause. It is somewhat run-on as a single long sentence and the sort enumeration is packed densely, but each clause conveys a distinct fact.

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?

There is no output schema, so the description must describe return values — and it does, enumerating the per-row fields. With 7 optional parameters and no schema descriptions, the missing coverage of limit and address keeps it from being fully complete.

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 0%, so the description must carry the load, and it defines most enums with meaning (read = 'least read first', unsubscribed/kept/active) and explains query and offset. However two of seven parameters — limit and address (a length-constrained sender filter) — are left undocumented anywhere.

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+resource and scope ('the newsletters and mailing lists the mailbox receives'), and immediately defines the row shape ('one row per sender and the address it writes to'). This clearly separates it from siblings such as listUnsubscribes, listSuppressions, and listSubscriptionDomains.

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?

Explains the discriminative semantics of the filters — 'Suggested' means an active sender that is rarely read and still writing, and 'suggested: true lists only those' — plus what each status value selects. It gives clear usage context but never names sibling alternatives (keepSubscriptions, unsubscribeSubscriptions, moveSubscriptions) or when-not to use it.

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