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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine value by explaining that include_deleted surfaces records with status DELETED, but says nothing about permissions, rate limits, or ordering of results.

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?

Two short sentences plus the endpoint reference, with the returned-fields summary front-loaded and no filler. The only cost is that the terse phrasing reads more like data notes than a call instruction.

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?

There is no output schema, so the description correctly compensates by listing the returned fields, and pagination semantics are carried by the schema's next_first_result hint. What is missing is any statement about ordering or result volume, but for a filtered list operation this is largely complete.

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, event_part_id, pagination and updated_since are already fully documented. The description only reinforces include_deleted (deleted rows come back with status DELETED), a marginal add over the schema's own wording. 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 names the specific resource (registrations for one session) and enumerates the core returned fields (contact id, status, attendance, category, dates), plus the underlying endpoint. It is clearly distinct from the guest/contact list siblings, though it never uses an explicit verb like 'list' to anchor it.

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?

Usage is implied by scoping to a single event part, and include_deleted gives one concrete behavioral choice, but there is no explicit 'use this when...' framing or pointer to alternatives such as evenium_list_guests or evenium_list_event_parts. An agent must infer the routing itself.

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