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

Annotations already declare it is a non-readOnly, idempotent, non-destructive, non-openWorld mutation. The description adds real context beyond that: the ask-first requirement and the 'most can decides immediately' auto-resolution rule. However, the 'draft'/'send'/'off' consent modes imply a mode argument that the schema (additionalProperties: false, 3 params) does not have, which is misleading rather than transparent.

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?

Front-loaded with the purpose, which is good, but the consent sentence is dense and introduces terminology ('groups'/'friends' policy, draft/send/off) that is never grounded in the tool's inputs, so it reads as noise relative to the callable surface.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Still, the description leaves planId unaddressed and buries the actual invocation contract under consent-policy language that does not map to any parameter.

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 67%: rsvp and optionIds are already described in the schema, planId is not. The description restates the rsvp values and the 'which options work' idea without adding syntax or constraints, and says nothing about planId. Baseline 3 for a partially documented schema.

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+resource: 'Answer a plan for the person (RSVP)', and enumerates the answer values. An agent can tell this answers an existing plan. It does not, however, differentiate itself from the sibling rsvp_event, which uses the same 'RSVP' vocabulary.

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?

Gives one strong usage constraint — 'ONLY with the person's own answer — ask first, never guess' — which is actionable. But the following sentence about 'draft'/'send'/'off' describes consent behaviour keyed to parameters that do not exist in the schema, muddying rather than clarifying when and how to invoke the tool, and no alternative tool is named.

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