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

With no annotations supplied, the description carries the whole burden and does substantial work: it discloses partial-failure reporting, explains the invitation_not_removable error as already-accepted or expired invitations, and warns that deleting a sent invitation irreversibly sends a withdrawal message. The main remaining gap is what happens to malformed or unknown ids in either array.

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?

Everything is packed into a few semicolon-delimited clauses with no filler, and the access prerequisite is front-loaded before the semantics. The heavy compression into punctuation-separated fragments makes it slightly harder to scan than a structured sentence would be, but no sentence is wasted.

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 mutation tool with no annotations and no output schema, the description covers workflow position, error code interpretation, irreversible side effects, and confirmation requirements, while the schema handles all parameter details. It is nearly complete; only edge-case behavior for invalid ids and the shape of the success response are unspecified.

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 100%, so all three parameters are already fully documented, including that `keep` order equals invitation order and that unlisted entries are not deleted. The description largely restates those same semantics (ordering, no-delete-for-unlisted, remove = get_activity_invites speakers[].id) rather than adding new meaning, 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 opening clause states the precise operation: `remove` deletes entries one by one, `keep` sets ordering, and unlisted ids are demoted rather than deleted. That is a specific verb+resource pair an agent can act on. It stops just short of a 5 because it never names the neighbouring add_guest_candidates / list_guest_invitation_candidates tools to contrast the operation against.

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 pipeline: take speakers[].id from get_activity_invites, call this tool, then call set_guest_invite_plan_status(start), plus a prerequisite (organizer login) and a pre-condition (show the remove list for confirmation first). What is missing is any explicit statement of when NOT to use it, e.g. pointing newcomers to add_guest_candidates.

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