proton-mcp

Overview Schema Source Related Servers Discussions Admin

Send a draft

send_draft

Destructive

Send an existing Proton Mail draft exactly as stored, including attachments, with a confirmation prompt before sending; the draft remains until you trash it after it appears in Sent.

Instructions

Sends a draft that is already in "Drafts", exactly as it was stored, its files included. Its markup is not checked against the levels again, because it was when the draft was written; the confirmation warns when it carries more than standard. The draft is not removed afterwards: this server does not follow a send it deliberately does not verify with a second write. Use trash_messages on the draft once the message shows up in Sent. By default every send asks the user to confirm first, through the client, showing the sender, every recipient separated into To, Cc and Bcc, and the subject. It carries no part of the message itself and links to a page where the whole thing can be read as the recipient will see it, and a client that cannot show the question cannot send. The user can allow a tool to send without asking, within bounds they choose; the answer then says that it did.

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>"
    },
    "name": "send_draft"
  }
}

Input Schema

Name	Required	Description	Default
`messageId`	Yes	The id of the draft, from list_drafts or create_draft.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.11Nov 1, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, it discloses that the draft is not re-validated against markup levels, that the confirmation warns when the message exceeds standard, that the draft is deliberately not deleted afterwards, and that clients unable to render the confirmation prompt cannot send. The confirmation payload contents (sender, To/Cc/Bcc, subject, no message body, link to a preview) and the auto-approve-within-bounds path are exactly the behavioral context an agent needs before triggering an irreversible send.

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 core action is front-loaded and every sentence adds a distinct fact (no re-validation, no deletion, confirmation flow, auto-approve). The prose is occasionally convoluted, notably "this server does not follow a send it deliberately does not verify with a second write", which costs a little readability.

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 one-parameter, irreversible send with no output schema, the definition covers the confirmation gate, the non-deletion behavior and the required cleanup step, which is close to everything needed. It leaves failure/error behavior and what the response states on a normal confirmed send unaddressed, though it does note the answer for auto-approved sends.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and messageId is fully documented in the schema, so the description carries no new parameter syntax. It does add the meaningful constraint that the message is sent exactly as stored with no overrides allowed at send time, which implicitly rules out content parameters, but that is a minor addition.

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?

"Sends a draft that is already in 'Drafts', exactly as it was stored, its files included" names a specific verb and resource and scopes it to existing drafts, which separates it from send_message, send_reply and send_forward without opening a schema. It also ties the stored-state semantics back to create_draft, so an agent knows this is not a compose-and-send call.

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?

It gives a clear post-send rule ("Use trash_messages on the draft once the message shows up in Sent"), which tells the agent the correct follow-up tool and ordering. It does not, however, explicitly say when to prefer update_draft or reply_draft/forward_draft over this tool, so some routing inference is left to the agent.

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