protonmail-mcp-server

Overview Schema Source Related Servers Discussions Admin

Skicka mejl

send_email

Destructive

Send an email with multiple recipients, subject, body, optional HTML, cc, bcc, reply-to, and attachments. Attachments limited to 20 files and 25 MB total.

Instructions

Skicka ett e-post.

Args: to: Mottagaradress(er) — sträng eller lista subject: Ämnesrad body: Brödtext i klartext body_html: Valfri HTML-version av brödtexten cc: Kopia-adress(er) bcc: Hemlig kopia-adress(er) reply_to: Svarsadress attachments: Filer att bifoga — ett filnamn eller en lista, inom bilagekatalogen (PROTONMAIL_ATTACHMENT_DIR, standard ~/Downloads/protonmail-mcp). Högst 20 filer och 25 MB tillsammans. Filer utanför katalogen (även via symlänk) avvisas, och då skickas inget.

Returns: True om e-posten skickades utan fel. Vägrar servern bara några av mottagarna kastas ett fel som anger vilka som vägrades och vilka som ändå fick mejlet — skicka då inte om till alla.

Input Schema

Name	Required	Description	Default
`cc`	No
`to`	Yes
`bcc`	No
`body`	Yes
`subject`	Yes
`reply_to`	No
`body_html`	No
`attachments`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.0Oct 21, 2026

addedInput schema / properties / attachments

Added value: +{
+  "anyOf": [
+    {
+      "minLength": 1,
+      "type": "string"
+    },
+    {
+      "items": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 20,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Attachments"
+}

First observedv0.1.0Jul 31, 2026

TDQS

A4.1/5.0

Behavior5/5

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

This goes well past the annotations (readOnly=false, destructive=true, openWorld=true, idempotent=false). It discloses attachment sandboxing (only files inside PROTONMAIL_ATTACHMENT_DIR, symlinks rejected), hard limits (20 files / 25 MB), the all-or-nothing rejection behavior, and critically the partial-recipient-failure semantics with an explicit instruction not to resend to everyone. That is exactly the behavioral context an agent needs for a non-idempotent 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?

Docstring-style Args/Returns layout is front-loaded and every bullet carries information; nothing is padding. The opening line is a near-restatement of the tool name, which is the only minor waste.

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 destructive, non-idempotent send tool with an output schema and zero schema-level parameter docs, the description supplies everything an agent needs: all parameter meanings, attachment constraints, and the failure/partial-delivery contract. Nothing material 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 description coverage is 0% and there are 8 parameters, so the description carries the entire burden. It documents every parameter meaningfully: to/cc/bcc/reply_to address semantics, subject, plaintext body vs optional HTML body, and attachment filename-or-list with directory and size constraints. The schema is unusable without this text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Skicka ett e-post' = send an email), which is unambiguous. However, it never distinguishes itself from the closely related siblings reply_to_email, forward_email, or send_draft, so sibling differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus reply_to_email, forward_email, or send_draft — all of which also put mail on the wire. The only operational guidance given is about attachment paths and not re-sending after a partial failure, which is not 'when to use' guidance.

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