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

Annotations already establish this is a non-read-only, non-destructive, non-idempotent write. The description adds genuinely useful behavioral context beyond them: the address is confirmed immediately with no verification code (contrasting with the confirm_quiz_email_recipient flow), and the number of recipients is capped by the plan. It does not say what happens on duplicate addresses, which the non-idempotent hint suggests is possible.

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 action and its key differentiator (auto-confirmed, no code) are front-loaded, and the remaining clauses carry real information about eligibility and plan limits. It is a single dense sentence built with dashes, which is efficient but slightly cluttered rather than cleanly structured.

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 2-parameter mutation tool with full schema coverage and annotations, the description covers the essentials: what it adds, the no-code confirmation behavior, the source and eligibility of user_id, and the plan cap. Only edge cases (duplicate address, error when the member is inactive) are left unstated, and no output schema exists to explain returns.

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 the baseline is 3; the description earns above that by adding the eligibility constraint on user_id — it must be an active member obtained from get_workspace_members — which is meaning beyond the schema's bare 'user_id участника (из get_workspace_members)'.

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 names a specific verb (adds) and resource (the 'To' field of quiz emails), and crucially specifies the subject is an account member's address that is auto-confirmed without a code. This distinguishes it from the generic sibling add_quiz_email_recipient, which takes an arbitrary address, without needing to open either schema.

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 gives an explicit precondition — only members who accepted the invitation (status = active per get_workspace_members) — and points to that source tool, which effectively routes the agent away from this tool for non-members. It does not explicitly name add_quiz_email_recipient as the fallback for non-member addresses, so it stops short of full alternative routing.

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