Skip to main content
Glama

Save draft

save_draft

Store a new email draft in the owner's mailbox without sending anything. Compose a new message or create a reply or forward, then edit or delete it later. Useful when a message needs review before it goes out.

Instructions

Writes a message into the owner's own Drafts folder and SENDS NOTHING. Nobody receives it, no mail server is offered it, and the only person who ever sees it is the mailbox's owner, in their own mail client. Use it when the person you are acting for should read a message before it goes out; sending it afterwards is send_draft, a separate tool behind a separate permission that this tool does not grant. A draft can be edited with update_draft and taken back with delete_draft, so nothing here is final. There are two shapes and a call states exactly one of them. A message of its own: name account and subject, and address it with to, cc, and bcc. An answer to mail this deployment already holds: name answeredEmailId and answering, and name NEITHER account NOR subject — the account, the subject, the threading headers that put the answer in the right conversation, the quoted original, and the files a forward carries are all read from the stored email, and to, cc, and bcc then add people beside whoever the answer already reaches. A call that states both shapes, or neither, is refused rather than guessed at. A draft addressed to nobody is an ordinary draft — writing the message before deciding who reads it is what drafting is for — and send_draft is what refuses it later, so nothing here requires a recipient. Calling this twice writes TWO drafts: there is no idempotency key, because a duplicate costs a deletion rather than a recipient a second message, so a retry after a timeout leaves a second draft to remove with delete_draft rather than one message sent twice. To change a draft, call update_draft with the draftId this answers rather than saving again. The From address is not an argument — the draft belongs to the account you name, or to the account the answered email is in, and that account's configuration decides the address. This tool will not attach files, will not schedule anything, and will not send.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoThe addresses to copy, each a plain mail address. Everybody the message would reach can see them. Omit it to copy nobody.
toNoThe addresses the draft is addressed to, one entry per person, each a plain mail address such as person@example.com without a display name. Omit it to address nobody yet, which is an ordinary draft. On a reply these are added beside the people the answer already reaches rather than replacing them; on a forward they are what the message would go to.
bccNoThe addresses to copy without naming them to anybody else. No other recipient would see that they received it. Omit it to blind-copy nobody.
accountNoThe account the draft belongs to, named by the accountId or the display name list_accounts returned. Required for a message of its own, and refused on an answer, where the account is read from the stored email being answered.
subjectNoThe subject line, as it will be stored. Required for a message of its own — empty text is allowed and means a message nobody has titled yet — and refused on an answer, where the subject is derived from the email being answered. A line break in it is refused, because a subject is written into a header.
htmlBodyNoAn HTML alternative to plainTextBody, stored beside it so each client shows the one it prefers. Omit it to write the plain text alone. It is the same message written twice, not a second message.
answeringNoWhich answer this draft is, required whenever answeredEmailId is named and refused otherwise. The three reach three different sets of people, so state it deliberately.
plainTextBodyYesThe message body as plain text, which every draft carries. It is required even when you also write htmlBody: a plain text derived by stripping markup reads as damage in the clients that show it, so the text you write here is what is stored. On an answer it is placed above the quoted original, which is added for you — do not paste or paraphrase the message being answered.
answeredEmailIdNoThe storedEmailId a listing, a search, a read, or an answer returned for the email this draft answers. Name it together with answering, and name neither to draft a message of its own.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateYesWhether the owner's own drafts folder shows this version of the draft yet. The draft is held here either way and can be sent either way.
draftIdYesThe stable identifier of the draft. It is what update_draft, delete_draft, and send_draft name it by, and it does not change when the draft is edited.
savedAtYesWhen this version of the draft was written down, as an ISO 8601 timestamp.
revisionYesWhich version of the draft this is, counted from one. Every accepted update_draft call adds one, and the folder ends up showing one message rather than a version apiece.
accountIdYesThe configured MailFathom account identifier the draft belongs to, and the one it would be sent as. Its Delivery configuration decides the From address, which a caller never supplies.
recipientCountYesHow many people the draft is addressed to across its to, cc, and bcc headers, after addresses named twice were reduced to one. Nobody is named. A draft addressed to nobody is an ordinary draft that send_draft refuses until it is addressed.
Install Server

TDQS

A5/5.0
Behavior5/5

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

Despite annotations indicating non-read-only, non-idempotent, and non-destructive, the description adds rich behavioral context: no sending, no mail server involvement, no idempotency (duplicate drafts on retry), refusal of ambiguous calls, and clarifications about From address and excluded capabilities (attach, schedule, send). This goes well beyond annotation info.

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

Conciseness5/5

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

The description is lengthy but deliberately structured: it opens with the core purpose, then covers alternatives, shapes, refusal logic, idempotency, and exclusions. Every sentence contributes meaningful context for a complex tool, and the information is front-loaded with the most critical behavioral distinction (sends nothing).

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?

With 9 parameters, only 1 required, 100% schema coverage, an existing output schema, and no nested objects, the description thoroughly covers all behavioral nuances: the two invocation modes, parameter interdependencies, error conditions (refusals), idempotency, and what the tool does not do. It leaves no ambiguity for an agent to misuse the tool.

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

Parameters5/5

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

The schema descriptions are thorough (100% coverage), but the tool description adds high-level parameter semantics: the two shapes (own message vs. answer) dictate which parameters are required/refused, how to/cc/bcc behave differently in replies, and that account/subject are derived from the answered email. This is not present in the schema and significantly aids agent understanding.

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 writes a draft and sends nothing, distinguishing from send_draft, update_draft, and delete_draft explicitly. It identifies the resource (draft) and the action (write) with precise scope.

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 explicitly states when to use it ('when the person you are acting for should read a message before it goes out') and contrasts with send_draft, update_draft, and delete_draft. It also clarifies the two distinct invocation shapes and refusal rules, giving thorough guidance on usage.

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