Prepare a reply as a draft
reply_draftWrite a reply to a Proton Mail message as a draft without sending it, quoting the original and using Reply-To or sender as recipient.
Instructions
Writes a reply to a message as a draft. The recipient is the message's Reply-To if it set one, otherwise its sender. The original is quoted below the new text. Nothing is sent. Note on threading: the reply is built with In-Reply-To and References, but Proton replaces those with its own internal thread id when it stores a draft, so a draft that is stored and sent later carries Proton's idea of the conversation rather than ours. 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
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": {
"messageId": "<messageId>",
"text": "<text>"
},
"name": "reply_draft"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | Your part of the message as markup instead of plain text. The original is quoted below it either way. The quote keeps the original's own markup, character for character, minus what would reach out of it: style blocks, document-level elements, scripts and comments. A message this server would not itself compose can therefore still be replied to or forwarded, but its formatting travels along, and so does anything a link in it points at. | |
| text | Yes | The reply itself. The original is quoted below it. | |
| mailbox | No | The mailbox the original is in, if known. | |
| replyAll | No | When true, the other recipients of the original are put in copy. | |
| messageId | Yes | The message id from a listing or a search, with or without angle brackets. | |
| markupLevel | No | How 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 |