Skip to main content
Glama
proton-mcp

proton-mcp

by RndmJoker

Create a draft

create_draft

Compose a new email draft in the Drafts mailbox without sending it, with recipients, subject, and a plain-text or HTML body. Use it to prepare messages for review before delivery.

Instructions

Writes a new draft into the Drafts mailbox. Nothing is sent. Attachments from files on this machine are not supported on purpose. The body is plain text and markup is not interpreted. HTML written here is delivered as visible characters, so the recipient would read the tags rather than see formatting. Give a message its shape with line breaks, blank lines, indentation and plain lists, and write a link as the bare address so that what is read is what is followed. A message may instead be written as markup, in the html field, which is delivered as formatting rather than as visible tags. Give one or the other, not both: a message that carries markup has its plain text half dropped, so the half that was confirmed would never arrive. Permitted are headings, paragraphs, line breaks, rules, quotes, emphasis, lists, tables, links and images, with colour, font, alignment, spacing and borders. Anything else is refused rather than quietly removed, and the answer names what and why. Note that the preview page linked from the confirmation lists every address in the message in full, including the ones behind links and images, and every alt text, because those are what a recipient reads. The question in the client stays short and carries counts instead. Text is UTF-8 everywhere: subject, body and addresses. Write characters as the language actually spells them, including umlauts, accents, sharp s, quotation marks and any other non-ASCII character. Do not transliterate them away (no "ae" for "ä", no "ss" for "ß"): the subject is encoded for transport and decoded again on arrival, and the body carries its character set, both verified against the Bridge. A transliterated message is simply a message with the wrong words in it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault
ccNoRecipients in copy, visible to everyone. Each entry is an address, optionally as "Display Name <name@example.com>".
toNoThe main recipients. Each entry is an address, optionally as "Display Name <name@example.com>".
bccNoRecipients in blind copy, hidden from the others but they do receive it. Each entry is an address, optionally as "Display Name <name@example.com>".
htmlNoThe body as markup instead of plain text. Give this or text, not both. Permitted are headings, paragraphs, line breaks, rules, quotes, emphasis, lists, tables, links and images, with colour, font, alignment, spacing and borders. Images may point at a full address; anything outside the permitted set is refused with a reason rather than removed.
textNoThe body, as plain text.
subjectNoThe subject line.
markupLevelNoHow much markup is permitted. "standard" covers ordinary formatted mail. "extended" permits every CSS property, including ones that can hide content, and makes the confirmation carry a warning telling the person to open the preview. Prefer "standard"; reach for "extended" only when asked for something that needs it, such as a button, which requires display:inline-block.standard

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.11

TDQS

A4.5/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: drafts are not sent, local attachments are unsupported, text and html are mutually exclusive, unsupported markup is refused with a reason, extended markup triggers a warning, and the preview exposes full addresses. These are exactly the operational consequences an agent needs before invoking a draft-creation tool. The stated behavior is consistent with readOnlyHint=false and destructiveHint=false.

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

Conciseness3/5

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

The description is front-loaded with the key purpose and constraints, but it is long and repetitive, especially around plain-text vs markup and UTF-8 transliteration. Most sentences carry useful information, but the same points are restated in multiple ways. It is usable but not tight.

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 seven parameters, no output schema, and annotations that cover only safety/intent, the description fills in the important behavioral context: what is created, what is not sent, body-format rules, markup handling, preview implications, and encoding requirements. It is complete enough for an agent to call the tool correctly without further guidance.

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 description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: text and html must not be combined, markup is interpreted only in html, plain text is delivered literally, and UTF-8 applies across subject, body, and addresses. It also clarifies the practical effect of markupLevel. Some of this repeats schema text, but the added consequences justify a 4.

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 states a specific verb and resource: it writes a new draft into the Drafts mailbox. It also immediately distinguishes the operation from sending by saying 'Nothing is sent', which separates it from siblings such as send_draft and send_message. An agent can identify the tool's core purpose 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?

The description gives clear usage context: draft creation rather than sending, no attachment support, and a preference for plain text unless markup is explicitly needed. It also explains when to prefer standard vs extended markup. It does not explicitly name sibling alternatives such as update_draft, reply_draft, or send_draft, so it stops short of full when/when-not/alternatives guidance.

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