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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real value beyond them: names are rendered as the leader sees them (players abbreviated like 'Ella S.') and the result includes how many people a change would reach. It omits any permission/authorization detail for the 'person leads' constraint.

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?

Content is front-loaded: what it returns comes first, then how to pick the session, then the read-only caveat. It is a touch dense with stacked parentheticals, but no sentence is pure 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 an output schema present, return values need no explanation, and the description still covers selection logic, return semantics and the non-reminding boundary. For a read-only lookup of moderate complexity this is nearly sufficient; only contrasting-sibling routing 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 description coverage is 100%, so every parameter including the date+title/start combination is already documented in the schema. The description's selection summary largely restates that, adding only the loose notion that title or start disambiguate same-day sessions. Baseline 3 is appropriate when the schema carries parameter meaning.

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 specifies the exact resource (one session of a group the person leads), the payload (who is coming, who can't, who hasn't answered, plus a reach count), and the identity source (read_schedule for the key). It is clearly distinguishable from a plain schedule listing, though it never names a contrasting sibling like event_signup_status outright.

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 states how to select the session (by key from read_schedule, or by date plus title/start when several share a day) and draws a boundary: 'Read only — reminding those who haven't answered is the person's own tap in the app.' That tells the agent what this tool will not do, but there is no explicit when-not-to-use guidance against neighboring RSVP tools.

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