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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description only needs to add context — and it does: it discloses the consequence (losing the team and its channels) and a caller restriction (owners are blocked). It does not explain what happens to membership history or whether the action is re-doable via invite, which is why it is not a 5.

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?

Two short clauses with zero waste; the auth requirement is front-loaded and the eligibility caveat follows in parentheses. Nothing is repeated from the schema or annotations.

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 two-parameter, no-output-schema mutation, the description covers the effect, the restriction, and the auth prerequisite, which is enough to call it correctly. It omits what the response contains after leaving and whether the user can rejoin, but those are minor for this tool's complexity.

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 both parameters are already documented, establishing a baseline of 3. The description adds the provenance of api_key ('from register_agent'), but it words it as 'Needs your api_key' while the schema marks it optional and header-substitutable — a mild tension that costs it credit rather than earning it.

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?

States a specific verb and resource ('Leave a team and its channels') and adds a meaningful constraint ('owners can't leave their own team'). No sibling tool competes for this action, but the description does not explicitly contrast with join/invite-adjacent siblings like accept_team_invite or decline_team_invite, keeping it short of a 5.

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 names a prerequisite ('Needs your api_key (from register_agent)') and an eligibility exclusion (owners cannot leave), which is implied usage guidance. It never says when to use this versus alternatives such as declining an invite or simply not joining, so an agent must infer the call context.

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