Send an email

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that 'from' must use a verified domain and sandbox keys are restricted to a single recipient. However, it does not describe side effects, response behavior, failures, or rate limits, leaving meaningful gaps for a sending operation.

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?

Two sentences with no wasteful preamble or redundant restating of the name. The key constraint is stated immediately after the core action, making it easy to parse.

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 an 8-parameter sandless mutation tool with no output schema and no annotations, this is only partially complete. It covers the most important prerequisite domain verification and sandbox behavior, but it omits body-field requirements, optional parameter semantics, and any indication of what happens after the email is accepted.

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 50%, so the description must partially compensate. It adds important semantic constraints for 'from' (verified domain) and indirectly for 'to' (sandbox limit), but it says nothing substantive about cc, bcc, reply_to, html, text, or subject beyond what the schema already documents.

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 uses a specific verb and resource: sending a transactional email via Maillog. It clearly distinguishes itself from the sibling list_emails by operation, so an agent can tell the tools apart without inspecting schemas.

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 states the intended context (transactional email via Maillog) and gives operational restrictions: verified domains, sandbox keys. It does not explicitly point to list_emails as the alternative for reading, but the operation split is obvious and the eligibility guidance is sufficient.

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