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

The readOnlyHint annotation already carries the safety profile, lowering the bar. The description adds the returned field set and the backing endpoint (GET /accounts/{accountId}/eventregistrations), which is useful context, but it says nothing about pagination, result volume, or the fact that both id filters are optional.

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 states purpose, scope, and return fields, followed by the endpoint reference. Well-sized with no filler, though the trailing API path is of marginal value to an agent invoking the tool.

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 helpfully enumerates the fields returned, and five fully-covered optional params carry the invocation detail. It omits pagination/result-limit behavior, which is the only notable gap for a list tool.

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 event_id, contact_id, and the three boolean flags are already fully documented in the schema. The description's event/contact framing reinforces the id params but adds no format or default information beyond what the schema provides, so the 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 uses a specific verb+resource ('List registrations') and clarifies the two scopes the tool covers — an event's attendee list or a contact's signups — with the returned data ('registration type, fee, paid, checked in, waitlist'). It is clearly distinguishable from create_event_registration and check_in_attendee, though it does not name any sibling explicitly.

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 clear context for the two invocation modes: pass an event to get an attendee list, pass a contact to see what they signed up for. There are no explicit exclusions or named alternatives (e.g. when to prefer list_event_registration_types), so it stops short of a 5.

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