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

Annotations already establish it as a safe read (readOnlyHint true, openWorldHint false), so the description's job is supplementary — and it delivers useful traits: the result is paginated, ordered newest first, and includes historical sends predating the contact record. It does not mention rate limits, behavior for an unknown contact_id, or an upper bound on total pages, so it is not fully complete.

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?

A single front-loaded sentence with the operation and ordering stated first and the event vocabulary in a compact parenthetical. Nothing is repeated from the title, and the pre-creation scope note earns its clause by clarifying result boundaries.

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 no output schema, the description does useful work by enumerating the event outcomes each record carries, which partially substitutes for a return schema. However, for a paginated three-parameter tool it omits the cursor contract, page-size behavior, and what happens for an unknown or erased contact, all of which an agent needs to drive it correctly.

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 0% across all three parameters, so the description must carry the burden and does not. Only "page through" hints at limit/cursor without explaining the default page size of 50, the 200 maximum, or that cursor is null on the first call. contact_id is never referenced, and "newest first" weakly implies sort but is not tied to the cursor contract.

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?

Names a specific verb and resource: paging through every email sent to a contact's address, with per-email event outcomes (delivered, opened, clicked, replied, bounced, unsubscribed) and newest-first ordering. It also carves out a scope detail ("includes sends from before the contact was created") that separates it from a naive per-contact timeline. It stops short of naming how it differs from the closest sibling, list_email_events.

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 use case (auditing what happened to mail sent to one contact) is implied clearly by the description but never stated as guidance, and no alternative is named. There is no when-not guidance, e.g., whether to use list_email_events for cross-contact or event-type queries. An agent must infer tool selection from the sibling list alone.

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