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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description goes far beyond by detailing: partial failure semantics (invitation_not_removable means the other party has already accepted), the ordering of operations (delete first then order), that unspecified keep rows are not deleted but pushed to the back, and the irreversible side effect of sending a recall message when deleting an already-sent invitation. It also notes the login/organizer requirement. This is exactly the kind of behavioral context an agent needs and it aligns with the 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 description is long but highly structured with clear labels (【需要登录·主办方】【何时用】【组合链】【口径】) that front-load the essential purpose and usage. Each section adds distinct value: login requirement, when-to-use, workflow chain, and critical rules. It is dense but not wasteful; every sentence earns its place given the complexity of the tool's behavior (destructive, with irreversibility). A slightly tighter wording could earn a 5, but this is genuinely efficient.

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?

Given the tool's complexity—destructive with side effects, three parameters, no output schema—the description covers nearly everything an agent needs: login/organizer requirement, the exact workflow with sibling tools, the operational order (delete then order), error handling (partial failure reporting and specific error code), the behavior of unlisted keep rows, and the irreversible wrong-move warning with a confirmation requirement. There is no output schema to explain, but the description still explains expected outcomes and failure modes, making it complete for correct invocation.

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?

The input schema already provides 100% coverage for all three parameters (keep, remove, activityRef) with descriptions that include the key semantics such as 'array order is invitation priority' for keep. The description does not add substantial parameter-level meaning beyond what the schema already states; it reinforces the ordering rule but does not introduce new parameter details. Given full schema coverage, the baseline is 3, and the description's minimal extra input is appropriate.

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 clearly states the tool's purpose: clean up the guest candidate list in one go by removing unsuitable candidates (remove) and ordering the keep ones (keep), with array order defining invitation priority. It distinguishes itself from siblings like add_guest_candidates by framing it as a cleanup operation on an existing list, and it even references the companion tools (get_activity_invites and set_guest_invite_plan_status) in the combination chain, so an agent knows exactly what this tool is for.

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 description opens with a 'when to use' section (【何时用】) that explicitly describes the scenario: one-shot reorganization of the candidate list. It also provides a combination chain showing the temporal order with sibling tools, which implicitly tells the agent when this tool is the right step. While it doesn't state 'don't use for adding new candidates,' the contrast with the add tool is unambiguous given the description's scope, making it clear enough.

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