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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=true. The description adds meaningful context: after start, the system automatically sends invites one by one per intervalMinutes; start is rejected if SPEAKER candidates are still generating or no registered candidates exist; activity must be published and not started. It also notes login and organizer role required. No contradiction with annotations, and it enriches the agent's understanding of side effects.

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 structured with labeled sections (【需要登录·主办方】【何时用】【组合链】【口径】) that front-load the most critical information: authentication/role, when to use, sequence, and detailed conditions. Every sentence delivers value with no redundancy or fluff, making it easy for an agent to scan and act.

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?

The description covers authentication, when to use, prerequisites, failure conditions, and post-start behavior (automatic invites). It does not explicitly state what happens if the plan is already in the requested state, but the idempotentHint annotation covers that. It also omits mention of setting the plan first (via set_guest_invite_plan), but the chain references get_activity_invites and add_guest_candidates, which is sufficient for invocation. Overall, it is complete enough for correct usage.

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 only 33% (activityRef has a description, role and action only have enums). The description clarifies the action semantics (start/pause) and mentions SPEAKER in the rejection condition, giving partial context for role. However, it does not explain the distinction between SPEAKER and ATTENDEE for this tool, nor does it elaborate on activityRef beyond the schema. It partially compensates for low coverage but leaves some ambiguity.

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 states a specific verb+resource: 'start 起跑、pause 急停' (start or emergency stop the invite plan), and explicitly distinguishes itself from related tools by naming get_activity_invites and add_guest_candidates in the chain. It also provides the exact user trigger ('人齐了别再邀了') for pause, making the purpose unmistakable.

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 '【何时用】' section gives explicit when-to-use conditions (start when ready, pause when user says stop) and the '【组合链】' section specifies the sequence with get_activity_invites and add_guest_candidates. It also states rejection conditions (no candidates, activity not published) and directs to add_guest_candidates in that case, fully guiding selection among siblings.

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