Apple Mail MCP

Overview Schema Source Related Servers Discussions Admin

create_draft

Save a plain-text email draft in Apple Mail's Drafts folder, either as a new message or as a threaded reply with quoted original, so you can review it before sending.

Instructions

Create a plain-text draft in Apple Mail's Drafts folder.

Two modes:

New message — pass to and subject. body is the message text.
Reply — pass reply_to={"account":..., "mailbox":..., "id":...} (use the values returned by search_messages). subject and to become optional and are auto-set from the original. body is your reply text; the original message is automatically quoted below it. Threading headers (In-Reply-To/References) are set so the recipient's mail client groups this with the original conversation. cc / bcc are additive.

Args: account: Sender account name (from list_accounts). body: Plain-text reply/message text. May be empty. to: Recipient addresses. Required for new messages, optional for replies. subject: Subject line. Required for new messages, optional for replies (defaults to "Re: "). Pass an explicit value to override. cc, bcc: Optional CC/BCC addresses. reply_to: If set, creates a reply. {account, mailbox, id} of the original message. account here is the account where the original was received, which may differ from the sending account. reply_all: If true and replying, replies to all recipients. Default false. visible: If true, Mail brings the compose window forward; if false the draft is saved silently. Defaults to APPLE_MAIL_MCP_DRAFT_VISIBLE.

Returns metadata about the created draft. Does NOT return a persisted Drafts-mailbox id — Mail commits drafts asynchronously. Drafts are reviewed in Mail.app.

HTML body rendering is v1.5.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "account": "<account>",
      "body": "<body>"
    },
    "name": "create_draft"
  }
}

Input Schema

Name	Required	Description	Default
`cc`	No
`to`	No
`bcc`	No
`body`	Yes
`account`	Yes
`subject`	No
`visible`	No
`reply_to`	No
`reply_all`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only declare the write/non-idempotent/non-destructive profile, and the description adds substantial context beyond them: the original is auto-quoted, In-Reply-To/References are set for threading, `visible` controls whether the compose window foregrounds, and the response cannot carry a persisted Drafts id because Mail commits asynchronously. The trailing 'HTML body rendering is v1.5' is too cryptic to convey whether HTML is supported or rejected, leaving one real behavioral unknown.

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?

Front-loaded with the one-line purpose, then a numbered two-mode block, then per-argument notes — a structure an agent can scan. Every line carries information because the schema has no field descriptions, though a few phrasings are loose ('cc / bcc are additive') and the closing v1.5 note is unexplained filler.

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

Completeness4/5

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

For a nine-parameter, non-idempotent compose tool with no output schema, the definition covers mode selection, parameter derivation, threading side effects, and the return-value limitation (metadata only, no persisted id). The only remaining gap is what actually happens with HTML or non-plain-text bodies, hinted at but not resolved by the v1.5 remark.

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?

Schema description coverage is 0%, so the description carries the full burden and does: it documents all nine parameters, gives conditionals for `to`/`subject` (required for new, optional and auto-derived for replies), states the 'Re: <original>' default, clarifies that `body` may be empty, and defines the opaque `reply_to` object's keys. It also resolves a subtle ambiguity the schema cannot — that `reply_to.account` is where the original was received, which may differ from the sending account.

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?

Opens with a specific verb and resource ('Create a plain-text draft in Apple Mail's Drafts folder') and immediately splits into two named modes, so an agent knows exactly what is produced and where it lands. None of the siblings (search_messages, move_to_mailbox, flag_message, etc.) create drafts, and the description's mode vocabulary makes the boundary obvious even though no sibling is named.

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?

Gives explicit conditional guidance: pass `to` and `subject` for a new message, pass `reply_to` with the triple returned by `search_messages` for a reply, and take `account` from `list_accounts`. It also states the downstream expectation ('Drafts are reviewed in Mail.app'), which tells the agent this tool composes rather than sends — the key when-to-use constraint.

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

Deploy Server