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

Annotations only declare destructiveHint=true and readOnlyHint=false; the description adds concrete consequences the agent cannot infer: a cap of 100 withdrawals per call, no email notification to anyone, cancelled:false plus no-op for unmatched targets, and scope limited to one beta project. These are exactly the operational details an agent needs before performing a destructive action.

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 key constraint (what is withdrawn and where targets come from) is front-loaded, and every sentence carries information. It is a single dense paragraph with stacked em-dash clauses, which is slightly harder to scan than a short bulleted structure would be.

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?

No output schema exists, yet the description still explains the meaningful return signal (cancelled:false for non-matching targets). Combined with the source of targets, the 100-item cap, and the interaction with removeTester, an agent has everything needed to call this 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% and each parameter is documented, but the description adds cross-parameter meaning absent from the schema: emails only work for addresses listPendingInvitations reports while invitationIds work for every invitee, the two inputs combine freely, at least one is required, and naming the same person both ways counts as one target. That is genuine added value, though per-field detail largely duplicates the 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 and resource scoped precisely: "Withdraws THIS beta project's pending tester invitations." The emphasis on THIS and pending separates it from removeTester and from actions on other beta projects without requiring the agent to open a sibling schema.

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?

Explicitly routes the agent to listPendingInvitations as the source of targets, and names the alternative for a related case ("people who already accepted and became testers are unaffected (use removeTester for those)"). It also states the exclusion that invitations to OTHER beta projects are untouched, so when-to-use and when-not-to-use are both covered.

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