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

Annotations already cover the read-only, non-destructive safety profile, so the description earns credit for what it adds: a required authorization role (EventRegistrationReport, Read) and an upper bound of 31 days per date window. It omits the response shape and any note about how unpaginated results are signaled, but the essentials beyond annotations are present.

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 the resource and the date axes, then the input constraint, then auth and endpoint. No filler and no repetition of schema field text.

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?

Covers resource, scope limits, mandatory role, and endpoint, which is sufficient for a read-only list tool with no output schema. The main residual gap is the date string format (the schema declares plain strings with no format), which an agent must guess when constructing filters.

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 baseline is 3, but the description adds a genuinely non-obvious rule: despite zero required parameters in the schema, at least one date pair must be supplied. It also clarifies that the 31-day cap applies per period, which the per-field schema text does not state.

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 ('Cancelled event registrations') plus the two possible axes (cancellation date or event date), which separates it from courtreserve_list_event_registrations and, by domain, from courtreserve_list_cancelled_reservations. It never names those siblings explicitly, so an agent must infer the distinction from the noun phrase alone.

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?

'Give at least one period' and 'at most 31 days each' are concrete usage constraints that prevent a call with no date filters or an over-wide window. However, nothing tells the agent when to prefer this tool over courtreserve_list_event_registrations or courtreserve_list_cancelled_reservations; no alternatives or exclusions are named.

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