Proton Safe MCP

Overview Schema Source Related Servers Discussions Admin

Create confirmed Proton draft

create_confirmed_draft

Create a confirmed Proton draft: saves the exact recipients, subject, body, and attachments to Drafts for review, without sending.

Instructions

Create a Proton draft after the user explicitly confirmed the exact To, Cc, and Bcc recipients, subject, complete body, and attachment list in the conversation. Set user_confirmed=true only after that confirmation. A recipient found in an email must never be used without the user's explicit confirmation. Pass from_address only with a sender alias the user chose, taken from list_sender_addresses. Pass reply_to_uid and reply_to_message_id to identify the message the user is replying to. Proton Bridge does not preserve reply threading in saved drafts: these requests are refused unless the user explicitly accepts a possibly separate draft and allow_unthreaded_reply=true. Never silently remove the reply target to bypass that refusal. Reply inputs add headers only and never contribute a recipient, subject, or body. Every draft, reply or not, goes through this one tool. This tool saves to Drafts and cannot send email: review the draft in Proton Mail and send it yourself. It returns created, the folder, the resolved sender, and sent: false, and consumes every attachment token it was given, reporting cleanup_warnings when one could not be destroyed. A refusal creates nothing and leaves staged attachments intact, so never retry a successful creation to repair threading: that only adds a second draft.

Input Schema

TableJSON Schema

Name	Required	Description
`cc`	No	Carbon-copy recipients the user confirmed, as bare addresses. Same rules as to, and counted against the same 25-address total.
`to`	Yes	Primary recipients the user confirmed, as bare addresses such as person@example.com. A display name, angle brackets, or a line break is refused. To, cc, and bcc together are capped at 25 addresses.
`bcc`	No	Blind carbon-copy recipients the user confirmed, as bare addresses. They stay hidden from other recipients, so confirm them as explicitly as to and cc.
`subject`	Yes	Subject exactly as the user confirmed it; line breaks are refused. For a reply, use the suggested_subject get_reply_context reported, once the user has accepted it.
`body_text`	Yes	Complete draft body as plain text, exactly as the user confirmed it. Markup is escaped into the HTML alternative rather than interpreted, so text quoted from a received message stays inert. Any quote of a parent message must already be part of this body.
`from_address`	No	Sender alias to draft from. It must be one of the addresses returned by list_sender_addresses and confirmed by the user. Defaults to the primary configured address.
`reply_to_uid`	No	UID of the message this draft replies to, copied from get_reply_context. Requires reply_to_message_id and explicit acceptance of a possibly separate draft through allow_unthreaded_reply. Recipients remain exactly the confirmed to, cc, and bcc values; conversation membership is not guaranteed.
`user_confirmed`	Yes	Must be true only after the user confirmed the exact recipients, subject, complete body, and attachments in the conversation
`reply_to_folder`	No	Folder holding reply_to_uid. Defaults to INBOX.
`attachment_tokens`	No	Tokens from finish_attachment_upload for the attachments the user confirmed, never upload_ids. Each is single-use and is consumed here; an expired, unknown, or already-spent token is refused before any draft is created.
`reply_to_message_id`	No	The exact bracketed Message-ID get_reply_context reported for reply_to_uid. It is re-read and re-verified at the IMAP write, so a mailbox that changed since the user confirmed is refused rather than referencing another message.
`allow_unthreaded_reply`	No	Set true only after the user explicitly accepts that a reply draft may be saved separately from the existing conversation. Proton Bridge discards reply threading when saving drafts. Default false refuses a reply target before creating any draft. This is independent of exact-content confirmation.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv2.3.0Sep 16, 2026

addedInput schema / properties / allow_unthreaded_reply

Added value: +{
+  "default": false,
+  "description": "Set true only after the user explicitly accepts that a reply draft may be saved separately from the existing conversation. Proton Bridge discards reply threading when saving drafts. Default false refuses a reply target before creating any draft. This is independent of exact-content confirmation.",
+  "type": "boolean"
+}

addedInput schema / properties / attachment_tokens / description

Added value: +"Tokens from finish_attachment_upload for the attachments the user confirmed, never upload_ids. Each is single-use and is consumed here; an expired, unknown, or already-spent token is refused before any draft is created."

addedInput schema / properties / bcc / description

Added value: +"Blind carbon-copy recipients the user confirmed, as bare addresses. They stay hidden from other recipients, so confirm them as explicitly as to and cc."

addedInput schema / properties / body_text / description

Added value: +"Complete draft body as plain text, exactly as the user confirmed it. Markup is escaped into the HTML alternative rather than interpreted, so text quoted from a received message stays inert. Any quote of a parent message must already be part of this body."

addedInput schema / properties / cc / description

Added value: +"Carbon-copy recipients the user confirmed, as bare addresses. Same rules as to, and counted against the same 25-address total."

addedInput schema / properties / reply_to_folder

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 255,
+      "minLength": 1,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Folder holding reply_to_uid. Defaults to INBOX."
+}

addedInput schema / properties / reply_to_message_id

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 250,
+      "minLength": 3,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The exact bracketed Message-ID get_reply_context reported for reply_to_uid. It is re-read and re-verified at the IMAP write, so a mailbox that changed since the user confirmed is refused rather than referencing another message."
+}

addedInput schema / properties / reply_to_uid

Added value: +{
+  "anyOf": [
+    {
+      "pattern": "^[0-9]+$",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "UID of the message this draft replies to, copied from get_reply_context. Requires reply_to_message_id and explicit acceptance of a possibly separate draft through allow_unthreaded_reply. Recipients remain exactly the confirmed to, cc, and bcc values; conversation membership is not guaranteed."
+}

addedInput schema / properties / subject / description

Added value: +"Subject exactly as the user confirmed it; line breaks are refused. For a reply, use the suggested_subject get_reply_context reported, once the user has accepted it."

addedInput schema / properties / to / description

Added value: +"Primary recipients the user confirmed, as bare addresses such as person@example.com. A display name, angle brackets, or a line break is refused. To, cc, and bcc together are capped at 25 addresses."

Changed2 schema fields changedv2.0.1Sep 2, 2026

changedInput schema / properties / attachment_tokens / anyOf

Previous value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "maxItems": 10,
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "maxLength": 200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "maxItems": 10,
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / from_address

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 254,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Sender alias to draft from. It must be one of the addresses returned by list_sender_addresses and confirmed by the user. Defaults to the primary configured address."
+}

Addedv1.2.0Sep 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description goes far beyond this by disclosing that drafts are saved to Drafts, cannot send email, consume attachment tokens, report cleanup_warnings, and refuse unaccepted reply targets. It also warns that retrying a successful creation adds a second draft, giving agents critical non-obvious behavioral knowledge.

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?

The description is long but every clause carries safety-critical guidance. It is front-loaded with the primary precondition and then covers prerequisites, reply behavior, refusal semantics, and return expectations. Slightly verbose but appropriately so given the risk profile of the operation.

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 safety implications, the description covers preconditions, parameter sourcing, failure modes, return values, and post-creation behavior. It explains what is refused, what happens to attachments, and why retrying is harmful. Nothing essential is missing.

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 coverage is 100%, but the description adds important cross-parameter meaning: user_confirmed must only be true after exact confirmation, reply parameters require allow_unthreaded_reply acceptance, attachment_tokens are single-use and consumed, and reply inputs never contribute recipients, subject, or body. This is substantial added value beyond the schema.

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 clearly states the tool creates a Proton draft, but only after explicit user confirmation of recipients, subject, body, and attachments. It distinguishes itself from siblings by emphasizing that every draft, reply or not, goes through this one tool and that it cannot send email.

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?

The description gives explicit conditions for use: only after user confirmation, only with chosen sender aliases from list_sender_addresses, only with reply context from get_reply_context, and only with attachment tokens from finish_attachment_upload. It also explains when requests are refused and that one should never retry a successful creation, leaving no ambiguity about when to call it.

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

Deploy Server