Skip to main content
Glama

Update draft

update_draft
DestructiveIdempotent

Replace an existing draft's entire content: recipients, subject, and body. Provide complete new values; omitted fields are dropped.

Instructions

Replaces the whole message of a draft this deployment holds, and SENDS NOTHING. The draft keeps its identifier, its version count goes up by one, and the owner's Drafts folder ends up showing one message rather than one per edit. It states the WHOLE message rather than the part that changed: a recipient you leave out is no longer addressed, a body you do not restate is gone, and htmlBody you omit is dropped. Read the draft you are editing back from what you wrote and send it all again, or you will silently drop what you did not repeat. The shape is save_draft's and the same rule applies: name account and subject for a message of its own, or name answeredEmailId and answering for an answer and neither of the other two. An answer is re-derived from the stored email every time it is edited, which is what keeps an edited reply a reply — so the email being answered has to be named again, and naming a different one turns the draft into an answer to that message instead. Only a draft this deployment created can be updated, named by the draftId save_draft answered. A draft the owner wrote in their own mail client is not one of them, and neither is a draft that has already been sent with send_draft: both are refused as a draft this deployment does not hold, and what stops a message that was already sent is cancel_outgoing_email.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoThe addresses the new version copies, each a plain mail address. It replaces the previous cc rather than adding to it.
toNoThe addresses the new version is addressed to, each a plain mail address. This replaces whoever the draft addressed rather than adding to them, so omitting it leaves the draft addressed to nobody. On an answer these are the people you are adding beside whoever the answer already reaches.
bccNoThe addresses the new version blind-copies. It replaces the previous bcc rather than adding to it.
accountNoThe account the draft belongs to, named as list_accounts returned it. Required for a message of its own, and refused on an answer. It has to be the account that already holds the draft: naming another one is refused as a draft this deployment does not hold, so editing is never a way to move a message into a different mailbox.
draftIdYesThe draftId save_draft returned for the draft you are replacing. A UUID that does not change when the draft is edited.
subjectNoThe subject line the new version carries. Required for a message of its own, and refused on an answer, where it is derived from the email being answered.
htmlBodyNoAn HTML alternative to plainTextBody. Omitting it drops the HTML the draft had, leaving the plain text alone.
answeringNoWhich answer this draft is, required whenever answeredEmailId is named and refused otherwise. Changing it changes who the answer would reach.
plainTextBodyYesThe message body as plain text, which every draft carries, and which replaces the body the draft had. It is required even when you also write htmlBody. On an answer it is placed above the quoted original, which is added for you again — do not paste or paraphrase the message being answered.
answeredEmailIdNoThe storedEmailId of the email this draft answers, required whenever the draft is an answer. Name it together with answering, and name neither to write 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

A4.8/5.0
Behavior5/5

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

Beyond annotations, the description discloses that the tool replaces the entire message, drops omitted fields (recipients, body, htmlBody), increments the version count, and re-derives answers from the answered email. It also states that drafts not held by the deployment are refused. Despite annotations indicating idempotent and destructive hints, the description aligns and adds depth about side effects, without contradicting 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 front-loaded with the core purpose, but it is a dense wall of text with some redundancy (e.g., 'Read the draft... send it all again' rephrases earlier warnings). While every sentence carries important information, better formatting would improve scannability; it's appropriately detailed for a 10-parameter complex tool.

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 tool's complexity (10 parameters, conditional requirements, restrictions on draft ownership, and answer behavior), the description covers all essential aspects: what it does, how to use parameters correctly, what it refuses, and side effects. The presence of an output schema relieves the need to describe return values, making this description complete and self-contained.

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

Parameters4/5

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

The schema already has 100% coverage with detailed descriptions for each parameter, providing a baseline of 3. The tool description adds valuable high-level rules about parameter combinations (account+subject vs answeredEmailId+answering) and warns that omitting fields silently drops them, which goes beyond the individual schema descriptions and helps correct invocation.

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 'Replaces the whole message of a draft this deployment holds' and explicitly says 'SENDS NOTHING', distinguishing it from send_draft. It also names the resource (draft) and the action (replace), making the purpose unambiguous.

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?

The description gives explicit guidance on when to use the tool: only for drafts created by this deployment (identified by draftId from save_draft), and not for drafts from other clients or already sent via send_draft. It also contrasts with save_draft's shape and mentions cancel_outgoing_email for stopping sent messages, providing clear boundaries versus alternatives.

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