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

readOnlyHint=true already covers safety, but the description goes well beyond it: cursor pagination with newest-first ordering, a hard 1000-item ceiling, ~3-day recording lag for left_at, unreliability before 2026-08-02, and the fact that pages can be shorter than 'total' because re-registered IDs are dropped. That is exactly the kind of hidden behavior annotations cannot express.

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?

Purpose and scope are front-loaded, and the dense caveats (lag, unreliable date floor, dropped re-registrations, wider alternative) each carry information an agent needs. It is slightly long, but no sentence is filler.

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 carries the return shape itself — each item is a /v1/participants list item plus left_at, the close of its latest registration. Combined with pagination rules and data-freshness caveats, nothing an agent needs to call or interpret this tool 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 coverage is 100%, so limit and cursor are already documented and the baseline would be 3. The description adds real semantics on top: it states the newest-first ordering, the implicit cap of 1000, and that shorter-than-expected pages are legal — context that changes how an agent consumes cursor and reads limit.

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 ("List the latest De-registered IDs") and immediately pins the population to the same set as /v1/stats/deregistered with the newest leave date, size cap, and sort order. It also explicitly contrasts itself with the wider /v1/participants?registered=false list, so an agent can tell it apart from the participant-listing siblings.

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?

Gives a clear routing rule: use this for de-registered IDs, and use /v1/participants?registered=false if never-registered IDs must be included — an explicit when-not. Minor deduction because the alternative is named as an HTTP endpoint rather than a sibling tool (e.g. list_participants), leaving the agent to map it.

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