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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds value beyond them by documenting the two authentication paths (Bearer header or key argument) and the secret-retention warning, which structured fields do not convey. It still omits consequences of the destructive action (what happens to membership data/history).

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 purpose is front-loaded in the first sentence, followed by retry then auth notes, with no filler sentences. The key-safety warning is repeated almost verbatim from the schema's key description, which is mild redundancy but not wasteful enough to drop the score below 4.

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 destructive, no-output-schema mutation, the description covers auth and idempotency but says nothing about outcomes or failure modes (e.g., error when not a member, what leaving forfeits). Annotations carry the read/write/destructive signal, so this is adequate but with a clear behavioral gap.

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 67%; request_id and key are documented in both schema and description, and the description reinforces request_id's retry role and key's auth role. community_id has no description in either place, and the description does not compensate for that gap, so it adds only marginal meaning beyond 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 description states a specific verb+resource combination ('Leave a private community') and narrows scope with 'private'. It does not name or contrast against siblings like community_join or community_member_remove, so an agent gets a clear purpose but no sibling differentiation.

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?

'Use a stable request_id for safe retries' gives one concrete usage rule (idempotent retry behavior), which is genuinely useful. However, there is no guidance on when to use this versus related tools or any prerequisites (e.g., must be a member, private-only scope), leaving usage largely implied.

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