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

Despite readOnlyHint=true in annotations, the description discloses meaningful additional behavior: it persists each guest to the agent's Output tab, records rows keyed by LinkedIn identifier or email, updates in place, and keeps removed guests removed. It also states persist failures never fail the read. This goes well beyond the annotation and gives the agent an accurate mental model of side effects. No contradiction with readOnlyHint exists because the external Luma data is never mutated.

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?

The description is long but every sentence carries load: the summary front-loads the exhaustive-roster guarantee, the middle paragraph justifies the design and reveals side effects, and the returns section is organized. There is no filler or repeated schema data. The structure with summary and returns sections makes it easy to scan.

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 fully documents the return shape: event_id, guests array, count, list summary, and the useful fields inside each guest object including approval_status, invited_at, registration_answers, and utm_source. It also covers persistence behavior, failure semantics, and re-run behavior, so an agent has everything needed to invoke the tool and interpret results correctly.

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 the structured schema already fully documents event_id (including the "evt-" prefix) and list_name (including default behavior). The description adds no extra parameter-level meaning beyond the schema; it only mentions how the saved person rows are keyed. This meets the baseline but does not exceed it.

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 opens with a specific verb-resource pair: "List every guest of a Luma event, with full registration detail." It also immediately clarifies the tool's exhaustive scope (all approval statuses, paginates to exhaustion), which distinguishes it from event-listing tools like get_luma_events. This is unambiguous and actionable.

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?

The description provides strong usage context: it warns that inferring "who hasn't registered yet" from a partial roster causes false negatives and re-nagging, and explains why the tool deliberately avoids trimming. This tells the agent when to rely on the complete output. It stops short of explicitly naming alternatives or saying "use X instead when Y," so it loses the top point for missing explicit exclusions.

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