Skip to main content
Glama

Send draft

send_draft
DestructiveIdempotent

Send a draft email permanently to its recipients. This action cannot be undone, so verify the draft before sending.

Instructions

Sends a real email: the message a draft holds, exactly as the owner would read it in their Drafts folder. It reaches strangers' mailboxes and CANNOT be recalled, edited, or deleted once it has left — treat every call as final, and ask the person you are acting for before sending on their behalf. This is the one draft tool that causes mail to leave; save_draft, update_draft, and delete_draft send nothing. The call itself transmits nothing: the message is written down durably and a delivery pass offers it to a mail server seconds later, so the result says queued and never that anything was delivered. Call get_outgoing_email with the outgoingEmailId it answers to learn what became of the message, and cancel_outgoing_email to stop it while it is still waiting. Nothing is recomposed and nothing may be changed here: what goes out is what the draft says, so edit it with update_draft first and read what you wrote before sending. There is no idempotencyKey, because the draft is the identity: promoting one draft sends ONE message however many times you call, and a repeated call answers with the record the first one wrote rather than sending a second message. A draft addressed to nobody is refused naming that, and the remedy is update_draft rather than a second save. Everything this deployment refuses a send for is asked again now rather than when the draft was written, so a draft composed before a limit was tightened is refused by the limit that holds today, and a refusal leaves the draft exactly as it was. The draft is not deleted when this answers: the message is queued rather than sent, so the copy stands in the owner's folder until the message has actually been delivered and is taken out in the same pass that files the sent copy.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
draftIdYesThe draftId save_draft returned for the draft you are sending. A UUID, and the whole of what this call takes: the message, the recipients, and the account are the draft's.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateYesHow far this message has got. A fresh send is queued, meaning it is written down and has not been transmitted. A repeated call carrying an idempotencyKey already used answers with whatever the first message has reached since.
queuedAtYesWhen the send was first written down, as an ISO 8601 timestamp. For a repeated call it is when the first identical call wrote the record, not when this one was made.
accountIdYesThe configured MailFathom account identifier the message is sent as. Its Delivery configuration decides the From address, which a caller never supplies.
recipientCountYesHow many people the message will be offered to across its to, cc, and bcc headers, after addresses named twice were reduced to one. Nobody is named.
outgoingEmailIdYesThe stable identifier of the queued message. It is what this send is known by afterwards, and an identical call carrying the same idempotencyKey answers with this same identifier rather than queueing a second message.
Install Server

TDQS

A4.6/5.0
Behavior5/5

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

Despite detailed annotations (readOnlyHint false, openWorldHint true, idempotentHint true, destructiveHint true), the description adds substantial behavioral context: irreversibility ('CANNOT be recalled, edited, or deleted'), exact transmit semantics ('queued and never that anything was delivered'), idempotency mechanism ('the draft is the identity... repeated call answers with the record'), refusal behavior ('everything this deployment refuses a send for is asked again now'), and that the draft is not deleted. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence delivers critical safety and behavior details; it is front-loaded with the core purpose. While not as compact as the TDQS 4.3 example, the verbosity is justified by the irreversible, high-stakes action. It is well-structured, progressing from what it does to consequences, alternatives, and edge cases, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (one simple parameter but high-stakes side effects), the description covers all angles: what happens (queued), how to check delivery (get_outgoing_email), how to cancel, idempotency, refusal handling, draft preservation, and pre-send editing. With an output schema present and annotations providing basic hints, the description fully explains the tool's behavior and what the agent needs to know, making it exceptionally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the only parameter (draftId) as 'The draftId save_draft returned for the draft you are sending. A UUID, and the whole of what this call takes...' (100% coverage), so the description adds no new semantic meaning about the parameter itself. It reinforces the identity concept but that is behavioral, not parameter-focused. Given the schema coverage, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sends a real email from a draft ('Sends a real email: the message a draft holds') and explicitly distinguishes it from siblings ('This is the one draft tool that causes mail to leave; save_draft, update_draft, and delete_draft send nothing.'), making its unique purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance by naming alternatives and their behaviors ('save_draft, update_draft, and delete_draft send nothing'), advises editing first ('edit it with update_draft first'), and directs follow-up actions ('Call get_outgoing_email...' and 'cancel_outgoing_email to stop it'), covering both prerequisites and post-send steps.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Krzysztof318/MailFathom'

If you have feedback or need assistance with the MCP directory API, please join our Discord server