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

Annotations only declare destructiveHint=false, so the description carries the burden and delivers real behavioral context: preview-hash invalidation when participants or content change, per-item outcome codes (SENT/ALREADY_INVITED/PREPARED/FAILED/PENDING), the fact that PREPARED is not delivery and partial failures are still reported, MANUAL only staging link copy, and no phone numbers returned. It stops short of stating permission/auth requirements and rate limits beyond '冷却', which keeps it from a 5.

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?

Nearly every clause carries information, but the text is an unpunctuated pile of fragments and the opener '登录/打扰他人;' is a dangling note that precedes the actual purpose. The critical preview/confirm workflow is present but not front-loaded above the constraint list, making the first read harder than necessary.

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?

For a 6-parameter, two-phase send tool with no output schema, the description covers the confirm flow, recipient constraints, channel semantics, and the shape of the per-item result, which is enough for an agent to call it correctly. Remaining gaps are the lack of sibling differentiation and of explicit authorization requirements.

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?

With 67% schema coverage, the description adds substantial meaning the schema lacks: it explains that channel APP is an in-app invite, SMS is a real SMS, and MANUAL only prepares link copy; that the same person may appear on multiple channels but userId/channel pairs must be unique; that recipients cap at 60 items with batch confirmation for large lists; and that resend applies only to already-delivered SMS. These directly annotate the undocumented enum and nested recipient fields.

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 conveys a specific action: preview then send invitations to a meetup's participants for a given activity, across APP/SMS/MANUAL channels. The core verb ('邀请…发送') and resource (参会人/活动) are identifiable despite the opening fragment '登录/打扰他人;', which is a truncated aside rather than a purpose statement. It does not distinguish itself from nearby siblings such as invite_organization_match_pair_to_activity or send_activity_ledger_invitations.

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?

Strong procedural guidance: preview=true is the default and must be confirmed before preview=false is sent with the same params plus previewHash, and resend=true is restricted to explicitly requested resends of delivered SMS subject to cooldown/accepted/rejected limits. What is missing is routing guidance against alternatives — nothing tells the agent why to pick this over invite_organization_match_pair_to_activity or send_activity_ledger_invitations with the same audience.

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