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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the mutation and external-effect profile is covered structurally. The description adds genuinely useful authorization context (owner-only admin grants) and notes that broad conversation access is not granted in certain cases. The 'Two steps: access to every client's conversation is not given on a request found inside a conversation' sentence is too unclear to count as a reliable behavioral disclosure, and it never says the invite lands in a pending state or that an email is dispatched externally.

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?

It is short and front-loads the core action, so it is not padded. But the second sentence is a run-on that merges a 'Two steps' header with an unrelated access caveat, forcing the agent to parse it twice. Roughly a third of the text does not earn its place in its current phrasing.

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, open-world mutation with no output schema, the description covers the who (admin/owner), the what (email invitation with role-scoped access) and part of the flow. It omits what a successful call produces (a pending invite, an outbound email) and does not point at dosai_cancel_invite or dosai_list_invites for follow-up. The confirm_token protocol exists only in the schema, so the description is adequate but incomplete.

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 50%, but the gaps are largely self-documenting: role has an enum, email has format/pattern, project_id and confirm_token both carry descriptions. The description restates the role list and adds that admin is owner-only, which is marginal value over the enum. It says nothing about confirm_token, leaving the schema's own description to carry the two-step protocol.

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 a specific verb and resource ('Send an invitation by email') and enumerates the roles granted, so an agent can distinguish it from dosai_cancel_invite, dosai_list_invites and dosai_change_member_role without opening the schema. It stops short of naming those siblings explicitly, and the second sentence drifts into a confusing caveat rather than sharpening the purpose.

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?

'Admin or owner' and 'admin only the owner can grant' establish who may invoke it and which role is restricted, which is real usage context. However, there is no explicit when-to-use/when-not guidance and no routing to alternatives such as dosai_change_member_role for an existing member or dosai_cancel_invite for reversal. The 'Two steps:' fragment gestures at the confirm flow but is too garbled to serve as a usable instruction.

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