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

Beyond the annotations' destructiveHint=true, the description adds critical behavioral detail: the email cannot be recalled, the call sends the draft's current contents rather than any new content, and all AIsa callers share one account so the email can reach message and thread state created by other callers. This materially helps an agent understand real-world side effects.

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 compact and front-loaded with the core action and return values, followed by essential warnings. Every sentence adds value, though the warning section is slightly wordy with the emoji and the shared-account note combined.

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, non-idempotent send operation with an output schema and 100% parameter coverage, the description is complete. It provides the return values, the prerequisite review step, the irreversible nature of the action, and the shared-account caveat. Nothing essential is missing for correct invocation.

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 100%, so the baseline is 3. The description adds no specific parameter-level meaning beyond noting that the call has no content of its own, which indirectly clarifies why send-related content parameters are absent. The parameter meanings themselves are already adequately documented in 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 opens with a specific verb and resource: sending an existing draft and returning `message_id` and `thread_id`. It also distinguishes itself from other send-like siblings by emphasizing that it takes no content of its own and sends whatever the draft currently holds.

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 gives clear usage context: review the draft with `get_agentmail_inbox_draft` first, and only send when the draft is ready. It does not explicitly name alternative send tools or state when not to use them, but the 'takes no content of its own' phrasing makes the intended workflow reasonably clear.

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