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

Beyond the annotations (which already declare readOnly/idempotent/non-destructive), it adds real behavioral context: login + organizer role required, 'speakers' covers guests only, 'audienceStats' returns counts with no name list, and no contact details are exposed (only hasContacts). These are traits an agent cannot get from the schema or annotations.

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 text is dense and telegraphic, packed into semicolon-delimited clauses that mix the tool's own behavior with downstream workflow routing. Little is wasted, but the structure is hard to parse and the purpose statement is not front-loaded ahead of the side guidance.

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 does the work of describing the returned fields and their limits (guest-only speakers, count-only audience stats, no contacts). Combined with the role requirement and the follow-up routing, an agent has enough to invoke and interpret it 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?

There is a single parameter with 100% schema description coverage, and the schema already explains that activityRef is a slug or id sourced from list_my_activities / get_organizer_activity. The description adds nothing about the parameter, so the baseline 3 applies.

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 enumerates the data the tool surfaces (SPEAKER/ATTENDEE plans, status stats, guest rank/verdict/profile completion, audience stats) and the title frames it as an invite overview, so the resource is inferable. However, it never states a clean verb+resource sentence ('returns the invitation overview for an activity'); the purpose must be reconstructed from a list of field names and mixed-in workflow guidance.

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 explicitly gives when-not guidance ('openInvite已有链接，勿再建') and names alternatives for adjacent tasks ('联系用conversationId走start_conversation'), plus a review ordering for update_guest_candidates → set_guest_invite_plan_status → send_guest_invite_now. What's missing is a positive statement of when to reach for this tool versus the sibling list_activity_guests or list_guest_invitation_candidates.

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