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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context: it is asynchronous, requires the member's message quota, has the same limits and idempotency as speedbot_invite, and does not support free-form messages, automatic acceptance, or payment. This goes beyond the annotations and helps an agent predict side effects and constraints. It does not mention failure modes or quota exhaustion behavior, but the provided context is solid.

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 description is three sentences, each adding distinct information: the action and prerequisite, the relationship to speedbot_invite, and the exclusions. It is front-loaded with the core action and does not waste words. The structure is easy to parse and remember.

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 tool with no output schema and only 25% parameter coverage, the description covers the key behavioral constraints: asynchronous, quota-required, idempotent, and limited to team-member invitations. It also warns about the team_key via the schema. It does not explain what the response looks like or what happens on failure, but the annotations and sibling context provide enough for an agent to select and invoke the tool correctly. A 4 is justified because the description is strong but not exhaustive.

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 description coverage is only 25%, so the description carries some burden. The description explains the overall purpose but does not explain individual parameters beyond what the schema provides. The schema already gives patterns and a warning for team_key ('Never include it in public text'), but the description does not clarify the roles of target_agent_id, client_invitation_id, or agent_id. The description's mention of 'on behalf of one managed team member' implies agent_id is the sender and target_agent_id is the recipient, but this is not explicit. Baseline 3 is appropriate because the description adds some context but leaves parameter-level semantics mostly to 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 clearly states the action ('Send an asynchronous invitation'), the scope ('on behalf of one managed team member'), and a key prerequisite ('Requires that member’s available message quota'). It also distinguishes itself from the sibling speedbot_invite by referencing 'Same limits and idempotency as speedbot_invite' and by noting the absence of free-form message, automatic acceptance, or payment. This gives an agent a precise understanding of what the tool does and how it differs from similar tools.

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 implies when to use this tool: when inviting on behalf of a managed team member, and it references speedbot_invite as the baseline for limits and idempotency, which helps an agent compare alternatives. However, it does not explicitly state when NOT to use it or name a specific alternative for non-team invitations. The sibling list includes speedbot_invite, so the contrast is implicit but not fully explicit.

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