send_email

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

No annotations are provided, so the description carries the full burden. It discloses the side effect (sending a real email), the from-address validation rules (existing mailbox or verified domain), and the automatic signature appending with a warning not to duplicate it. This is substantial, though it does not mention rates, limits, errors, or return behavior.

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 dense sentences with no wasted words. The core purpose is front-loaded, followed by the most important operational constraint and then a critical behavioral warning. Every sentence contributes.

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 8 parameters and no annotations or output schema, the description covers the non-obvious traps that would otherwise cause incorrect calls. However, it does not describe success/failure return values or what happens immediately after sending, and it relies on the schema for most parameter details, so it falls just short of fully complete.

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 75%, so the baseline is 3. The description adds meaning beyond the schema by explaining DNS-level domain verification and the signature duplication gotcha for the from parameter. Other parameters are left to the schema, which already documents most of them, so the added value earns a 4.

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 'Send a real email,' which clearly identifies the action and resource. The phrase 'real email' distinguishes it from draft-related sibling tools, and the rest of the description reinforces that it performs an actual send with side effects.

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?

Usage is implied by the tool name and the verb 'Send,' and the description gives essential constraints for the from address. However, it never explicitly contrasts this tool with create_draft or other siblings, and it does not state when not to use it, so an agent must infer the selection context.

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