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

Annotations already mark destructiveHint=true, and the description reinforces that by stating 'sends real email.' It adds behavioral details: can wait for SMTP delivery outcome, schedule send, and warns about `from` misuse. It mentions the post-send awaitReply step. Missing details like rate limits or cancellation behavior are partially covered by sibling tools, and annotations provide the base safety profile.

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: three sentences each serving a distinct purpose (usage trigger, core behavior, critical instruction and post-send action). It is front-loaded with the use case, and every sentence adds necessary information without redundancy. No filler.

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?

Given the tool's complexity (nested schema, many parameters, output schema present), the description covers the essential workflow: when to use, what it does, the critical `from` rule, and the post-send step with awaitReply. It references sibling tools for setup (createEmailAddress) and follow-up (awaitReply). The output schema exists, so the lack of return value details is acceptable. Minor gap: no mention of error states or the Idempotency-Key behavior, but these are covered in the schema.

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?

The schema itself has a high level of detail (67% coverage) with descriptions for most parameters. The main description adds value for the `from` parameter ('YOUR OWN complete mailbox address, never the recipient's') and references sender_address from createEmailAddress/getAccount. However, it does not explain other key parameters like to, subject, attachments, or the interplay between wait and scheduled_at beyond a brief mention. The schema does the heavy lifting, so the description's additional semantic contribution is modest.

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 it sends real email through Primitive's relay, with options to wait or schedule. It specifies it is for new outbound emails only, distinguishing it from siblings like replyToEmail (replies) and sendEmailDemo (demo). The verb 'sends' plus resource 'email' with explicit scope is specific and 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?

The description explicitly says 'Use this when the user has confirmed a new outbound email,' providing clear when-to-use context. It adds critical guidance: the `from` field must be your own address, and after sending, call awaitReply if expecting an answer. It does not explicitly exclude sibling tools for other scenarios (e.g., replying), but the narrowing to 'new outbound' is sufficient.

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