Dove

Create draft

create_draft

Compose a new email draft in a mailbox's Drafts folder, including threaded replies, forwards, and attachments, so the owner can review and send it later.

Instructions

Create a new draft, a threaded reply (reply_to_message_id, quotes the original by default) or a forward (forward_message_id or forward_ref, includes the original's attachments by default) in a mailbox's server Drafts. Attach files by reference to a message you can read (bytes stay on the server) or inline as base64: at most 10 per draft, 10 MiB in total by default. Recipients are never inferred. If the operator set a signature for the sender it is appended after body_text (before a quote or forward block) unless you pass signature: false; update_draft never adds it again. Generate a fresh UUID request_key per intent and reuse it only to retry the same request. The owner reviews and sends it in their mail app unless send rights exist. Change it with update_draft; send it with send_draft when you have send rights, otherwise ask the owner with request_send.

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>",
      "request_key": "<request_key>",
      "body_text": "<body_text>"
    },
    "name": "create_draft"
  }
}

Input Schema

Name	Required	Description
`cc`	No	Cc recipients (email addresses, at most 50).
`to`	No	To recipients (email addresses, at most 50).
`bcc`	No	Bcc recipients (email addresses, at most 50).
`account`	Yes	Mailbox alias or email address from list_accounts.
`subject`	No	Subject line.
`body_text`	Yes	Plain-text body (at most 500 KB).
`signature`	No	Append the sender's signature after body_text (default true; nothing happens when none is set).
`attachments`	No	Files to attach. Either a reference {ref \| account + message_id, attachment_id} to an attachment of a message you can read, or inline {filename, mime_type, content_base64}.
`forward_ref`	No	Forward the message of this ref from search_messages (any mailbox you can read).
`request_key`	Yes	Client-generated UUID for idempotent retries.
`from_address`	No	The mailbox address or one of its send-as aliases (list_accounts shows from_addresses for IMAP mailboxes; Gmail uses the account's send-as list).
`quote_original`	No	Replies: quote the original's text below body_text (default true when you have read on this mailbox).
`forward_message_id`	No	Forward this message of `account` (needs read).
`include_attachments`	No	Forwards: attach the original's attachments (default true).
`reply_to_message_id`	No	Make a threaded reply to this message of `account`.

Output Schema

Name	Required	Description	Default
`account`	No
`draft_id`	No
`revision`	No
`thread_id`	No
`message_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedNov 14, 2026
- addedInput schema / properties / attachments / items / properties / account / description
```
Added value: +"Reference: mailbox alias of that message (with message_id)."
```
- addedInput schema / properties / attachments / items / properties / content_base64 / description
```
Added value: +"Inline: the file content, base64 encoded."
```
- addedInput schema / properties / attachments / items / properties / filename / description
```
Added value: +"Inline: file name."
```
- addedInput schema / properties / attachments / items / properties / message_id / description
```
Added value: +"Reference: message id (with account)."
```
- changedInput schema / properties / attachments / items / properties / mime_type / description
```
Previous value: -"type/subtype, e.g. application/pdf"New value: +"Inline: type/subtype, e.g. application/pdf"
```
- addedInput schema / properties / attachments / items / properties / ref / description
```
Added value: +"Reference: opaque ref from search_messages of the message holding the attachment."
```
- addedInput schema / properties / bcc / description
```
Added value: +"Bcc recipients (email addresses, at most 50)."
```
- addedInput schema / properties / body_text / description
```
Added value: +"Plain-text body (at most 500 KB)."
```
- addedInput schema / properties / cc / description
```
Added value: +"Cc recipients (email addresses, at most 50)."
```
- addedInput schema / properties / reply_to_message_id / description
```
Added value: +"Make a threaded reply to this message of `account`."
```
- addedInput schema / properties / subject / description
```
Added value: +"Subject line."
```
- addedInput schema / properties / to / description
```
Added value: +"To recipients (email addresses, at most 50)."
```
First observedv0.11.0Nov 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say non-read-only, non-destructive, non-idempotent; the description goes well beyond them by disclosing that recipients are never inferred, that a sender signature is auto-appended after body_text and where it lands relative to a quote/forward block, the signature:false opt-out, that update_draft never re-adds it, and the 10-attachment / 10 MiB caps. The request_key guidance is a genuine behavioral addition rather than repetition of idempotentHint=false, since it explains how to obtain idempotency the hint says is absent.

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 three creation modes, then limits, then the downstream workflow — a sensible ordering with no filler sentences. It is dense for its length and the signature-customization clause sits mid-paragraph rather than in the workflow tail where an agent would look for it, but nothing is redundant.

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 15-parameter, 3-required creation tool with an output schema, the description covers everything an agent needs: which modes exist, which parameter pairs conflict, size and count limits, idempotency/retry discipline, and what happens after the draft exists. Return values can be left to the output schema, so no material gap remains.

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 100%, so the baseline is 3; the description nonetheless adds cross-parameter meaning the schema does not carry — mutually exclusive reply vs forward modes, the 10 MiB total size limit (schema only gives maxItems 10), the reference-vs-inline attachment dichotomy with bytes staying on the server, and the conditional default for quote_original ("default true when you have read on this mailbox"). It stops short of explaining from_address/send-as resolution or cc/bcc behavior beyond what the schema already states.

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 new draft") and immediately enumerates the three distinct modes — new draft, threaded reply via reply_to_message_id, forward via forward_message_id/forward_ref — with the destination scope ("mailbox's server Drafts"). It also names sibling tools (update_draft, send_draft, request_send), so an agent can distinguish this from adjacent operations without opening a schema.

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?

Explicit routing is present: change with update_draft, send with send_draft when send rights exist, otherwise request_send from the owner. It states a precondition for the fallback path ("when you have send rights") and clarifies the default outcome that the owner reviews and sends in their mail app, which is exactly the when-to-use context an agent needs.

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