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

Annotations only declare the generic safety profile (openWorld, non-idempotent, non-destructive); the description adds the real behavioral substance: the confirmation hash requirement, the channel-source rule (latest invitationActions.channels), cooldown/accept/decline limits on resends, and that MANUAL only stages a personal link. It also clarifies status semantics (PREPARED/PENDING ≠ delivered, ACCEPTED ≠ signup/attendance) and the privacy behavior (no phone numbers emitted).

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?

It is a dense, run-on academic-style block, but it is front-loaded with the scope tag and then the preview→confirm workflow, and each remaining sentence carries distinct operational information. Slightly over-stuffed, yet nothing is clearly redundant.

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 non-idempotent outbound-send tool with nested recipients, low schema coverage and no output schema, the description covers the confirmation flow, channel derivation, resend constraints, status interpretation and privacy limits. An agent has enough to invoke 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?

Schema coverage is low at 25%, so the description has to compensate, and it does: it explains preview/previewHash roles, where channel values come from, and the exact meaning of resend. It leaves activityRef largely to the schema description and does not spell out the APP/SMS enum pair beyond MANUAL, so it is not fully exhaustive.

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 opens with a bracketed scope tag 【需登录·对外邀请】and states a specific verb+resource: continue inviting existing members on the activity invitation ledger. It is immediately distinguishable from siblings like send_guest_invite_now or invite_organization_members because it is ledger-scoped.

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 gives an explicit two-phase workflow: default preview=true to review the list, channels and resends, then re-issue the same parameters plus previewHash with preview=false to actually send. It also states a precondition for resend (user must explicitly request it) and calls out the MANUAL channel as prepare-only, not send.

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