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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is partly covered; the description adds meaningful context beyond that: owner-only authorization and the self-removal guard. It does not state whether removal is reversible or what the confirmed call returns, which would complete the destructive-operation disclosure.

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 the action and the primary constraint. It is slightly telegraphic — 'Two steps.' and the orphaned parenthetical cost a little clarity — 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?

A destructive, confirmed mutation with no output schema needs the description to carry authorization, consequences, and the confirmation contract; it covers authorization and implies confirmation but leaves the effect of the confirmed call and the source of user_id to inference. Adequate, not complete.

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%: project_id and confirm_token are documented in-schema (including the full two-step instruction), but user_id only has a UUID format with no explanation. The description says 'someone's access' without clarifying that user_id is the member id obtained from dosai_list_team, leaving the identity parameter under-explained.

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 concrete verb and resource ('Take away someone's access to the project'), which is clear and distinct from dosai_invite_member and dosai_change_member_role. The parenthetical '(dosai_list_team)' is ambiguous — it is unclear whether it points to a lookup step or an alternative tool — but the core purpose is unambiguous.

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?

Adds two real usage constraints an agent would otherwise miss: 'Owner only' (permission prerequisite) and 'The owner cannot remove themselves' (a hard exclusion). 'Two steps' signals the confirm flow, though its mechanics only become clear from the schema's confirm_token description rather than the description itself.

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