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

Annotations already flag this as destructive and non-idempotent, and the description goes well beyond them: it states the personal-token auth requirement, the creator-cannot-leave restriction, and precisely what removal means (existing inbox messages retained, no new messages, group unreadable). That is exactly the post-action consequence an agent needs before committing to an irreversible operation.

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?

Four short sentences, front-loaded with purpose, then role rules, then omitting-the-parameter mechanics, then consequences. Every sentence carries a distinct constraint; nothing is padding.

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 only two parameters, no output schema, and destructive annotations, the description supplies everything an agent needs: authorization requirement, role gating, the leave-via-omission path, and the resulting access state. No material gap remains.

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 100%, so the baseline is 3, but the description adds role semantics beyond the schema: omitting agent_address is only valid for non-creator members, and the parameter may target either an existing member or a proposed agent. The only redundancy is restating the omit-to-leave rule already present in the schema.

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 first sentence states a specific verb and resource ('Remove a group member, or leave'), and the dual mode is spelled out immediately. It is clearly the inverse of the sibling add_group_member, so an agent can distinguish the two without inspecting schemas.

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 gives role-based selection rules: the creator can remove a member or decline a proposal, any other member can only remove itself, and the creator cannot leave. That covers both when and when-not. It stops short of naming a sibling tool as an alternative, but the role conditions leave little ambiguity.

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