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 behavioral burden for a high-impact mutation that sends external mail. It does not state irreversibility of sends, what happens with scheduling or how cancel-email interacts, any rate limits or quota behavior, or whether tracking is on by default (it only appears as an override). Listing features is not the same as disclosing 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?

A single front-loaded sentence with the verb and the resource first, followed by the capability list. Nothing is redundant, though the trailing enumeration is somewhat list-like rather than informative.

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?

With 15 parameters, nested attachment objects, no output schema and no annotations, the definition leaves real gaps: no return value expectations (e.g. a queued message id), no interaction with the scheduled/cancel sibling tools, and no prerequisites. For a tool of this complexity the one-line feature list is inadequate.

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% with 15 well-documented parameters, including the mutually exclusive url/content attachment pair, so the schema does the heavy lifting. The description adds only a paraphrase of those capabilities and does not resolve open interplay questions such as html vs text precedence or template vs subject requirements. Baseline 3 is appropriate.

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 states a concrete verb+resource ('Send an email via Emailit') and names the capability surface it supports (HTML, text, templates, attachments, scheduling). It is unambiguous against siblings, which are all read/update/delete operations on emails, domains, keys, audiences, contacts and templates – nothing else sends mail. It stops short of 5 because the capability list is a feature dump rather than an explicit scope statement.

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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites such as a verified sending domain or API key scope, and no note on the relationship between sending now and the sibling cancel-email/scheduled flow. The agent must infer that scheduled_at is what makes cancel-email relevant, which is not stated anywhere.

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