Skip to main content
Glama
JE4NVRG

MepMail

mailbox_save_draft

Create or update a plain-text email draft in a mailbox without sending it; adds signature, supports attachments, replies, and forwards.

Instructions

Create or update a plain-text draft in a mailbox without sending it; the draft is written from that mailbox's address. The mailbox signature is added at the end, once, and the message also goes out formatted. A new draft takes expected_revision 0; editing one needs its id and current revision (a stale revision is refused, re-read the draft). To answer or pass on a received message, give its id as source_item_id with mode reply or forward. Attachments: attachments adds files (content_base64 with a filename, or a path inside MEPMAIL_MAIL_UPLOAD_DIR); keep_attachments lists the indexes to keep from the draft being edited or the message being forwarded (default: keep them all; a reply keeps none). Limits: 10 files, 256 KiB each, about 700 KiB in all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNoCopy (Cc) addresses
idNoDraft id, when editing an existing draft
toYesRecipient addresses
bccNoBlind copy (Bcc) addresses: they receive the message, and no other recipient sees them; To, Cc and Bcc together count up to 20
modeNoWith source_item_id
textYesPlain-text body
mailboxNoMailbox address (or id) from mailbox_list_accounts. Needed when the credential covers several mailboxes and has no default.
subjectYesSubject line, one line
attachmentsNoNew files: { filename, content_base64 } or { path } inside MEPMAIL_MAIL_UPLOAD_DIR
source_item_idNoReceived message this draft replies to or forwards
keep_attachmentsNoAttachment indexes to keep from the edited draft or forwarded message
expected_revisionNo0 for a new draft; the draft's current revision when editing

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say idempotentHint=false and destructiveHint=false; the description adds substantial context beyond that: the mailbox signature is appended once, the body is formatted, a stale revision is refused and must be re-read, attachment index retention defaults differ between edit/forward (keep all) and reply (keep none), and hard limits are given (10 files, 256 KiB each, ~700 KiB total). This is exactly the behavioral detail an agent needs.

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?

Dense but front-loaded: purpose first, then editing/revision rules, then reply/forward, then attachments, then limits. Every clause carries information, though the run-on paragraph is heavier than it needs to be and the phrase 'the message also goes out formatted' is slightly ambiguous.

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?

For a 12-parameter mutation tool with no output schema, the description covers the create-vs-edit lifecycle, revision conflict handling, reply/forward derivation, attachment retention, and resource limits. Nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is already 100%, so baseline is 3, but the description earns above that by supplying the retention default for keep_attachments (not in the schema), the two attachment input forms, and the size/count limits. It leaves cc/bcc and subject semantics to the schema, which is reasonable.

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?

States a precise verb and resource ('Create or update a plain-text draft in a mailbox') plus the critical qualifier 'without sending it', which cleanly separates it from the sibling mailbox_send_draft. An agent can pick this tool without opening the schema.

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

Usage Guidelines4/5

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

Gives explicit conditions for the two modes: expected_revision 0 for new drafts, id plus current revision for edits, and source_item_id with mode reply/forward for answering or passing on a message. It stops short of naming mailbox_send_draft as the alternative for actually sending, though 'without sending it' implies the boundary.

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