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

With no annotations, the description carries the full disclosure burden and does add real operational context: tier availability ('every API V2 tier') and a hard 90-day polling window implying records fall out of reach beyond that gap (consistent with `since` defaulting to 90 days ago). It still omits whether records are ever purged, how to iterate the cursor, and what failure/non-success looks like.

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?

Three short sentences, front-loaded with what is returned, followed by access scope and the critical polling rule. No redundancy and no filler; the ordering and cadence details both earn their place.

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 simple paginated list tool with full schema coverage, the description supplies the essentials an agent needs: resource, sort order, tier access, and the polling window that governs correct usage. With no output schema, it could say a bit more about what a removal record contains, but nothing critical is missing.

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%, so `limit`, `since`, and `cursor` are already fully documented in the schema. The description only adds the sort order, which indirectly justifies cursor pagination but adds no parameter syntax or format detail beyond the schema. 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?

The description states a specific verb and resource: it returns removal (cancellation) records and notes their ordering by `cancelledAt` then `id`. That is clear enough to identify the resource, but it never differentiates from siblings like `list_events` or `get_event`, and 'removal records' is slightly vaguer than the tool name's 'event cancellations'.

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?

It gives a concrete polling directive — poll regularly, never leave more than 90 days between successful requests, and do so 'even when webhooks are enabled' — which tells the agent this is a reconciliation feed rather than an on-demand lookup. It stops short of explicitly naming an alternative tool or stating when this should be skipped.

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