Skip to main content
Glama
sethbang

proton-mail-mcp

send_email

Send email messages through Proton Mail SMTP with support for HTML (sanitized by default), plain text, markdown, attachments, CC/BCC, and dry-run preview.

Instructions

Send an email using Proton Mail SMTP. HTML bodies are sanitized through a conservative allowlist by default (v1.0.0: sanitizeHtml defaults to true) — scripts, event handlers, inline styles, and remote <img> beacons are stripped. Pass sanitizeHtml: false to send full-fidelity HTML in trusted-content workflows. Plain-text bodies pass through unchanged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesRecipient email address(es). Multiple addresses can be separated by commas.
subjectYesEmail subject line
bodyNoEmail body content (plain text or HTML). Required unless `markdownBody` is provided.
isHtmlNoWhether `body` contains HTML content
markdownBodyNoMarkdown source — rendered to HTML before sending. Mutually exclusive with `body`/`isHtml`. The email-service computes a plain-text fallback automatically for multipart/alternative.
sanitizeHtmlNoWhen the body is HTML (either via `isHtml: true` or `markdownBody`), strip scripts, event handlers, inline styles, disallowed tags, and remote `<img>` beacons through a conservative allowlist. **Defaults to true as of v1.0.0** for safer-by-default agent-driven sending. Pass `false` to preserve full-fidelity HTML for trusted-content workflows. No-op on plain-text bodies.
ccNoCC recipient(s), separated by commas
bccNoBCC recipient(s), separated by commas
replyToNoReply-To email address. Note: Proton SMTP may rewrite or ignore values that don't match authenticated identities.
fromNameNoDisplay name for the From field. By default rejects values containing `@` to prevent display-name-as-address spoofing (e.g. `"Anthropic Security <security@anthropic.com>"` looks like a legitimate sender in most mail clients even though the envelope From is bound to the authenticated identity). Pass `allowAddressLikeFromName: true` for legitimate cases.
allowAddressLikeFromNameNoOpt-in escape valve for `fromName` containing `@`. Default false — see fromName's note for why this is the safer-by-default posture for agent-driven sending.
attachmentsNoFile attachments (base64-encoded content)
dryRunNoIf true, validate and resolve the full recipient set (To/CC/BCC) + subject + body WITHOUT sending — returns a preview so you can confirm exactly who would receive the mail. Mirrors the bulk/thread dry-run pattern.
Behavior5/5

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

The description goes beyond annotations by detailing sanitization behavior (default true, stripping scripts), plain-text handling, and Proton SMTP specifics like replyTo rewriting and fromName spoofing protection. Annotations provide only basic hints, so the description adds substantial value for agent decision-making.

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

Conciseness5/5

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

The description is extremely concise (two sentences) and front-loaded with the core action. Every sentence provides essential information without repetition or fluff.

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?

Despite 13 parameters and no output schema, the description covers key behavioral aspects (sanitization, plain-text, fromName restrictions, dryRun, replyTo behavior). It omits no critical details given the richness of the schema descriptions.

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?

With 100% schema description coverage, the baseline is 3. The description adds overarching context about sanitization policy and behavioral defaults that are not fully captured in individual parameter descriptions. This enhances understanding 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 'Send an email using Proton Mail SMTP', which is a specific verb-resource pair. It distinguishes from sibling tools like forward_email or reply_email by focusing on composing a new message. The additional detail about HTML sanitization further clarifies the tool's purpose.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives like reply_email or forward_email. While the purpose implies it's for new emails, there is no direct guidance or exclusion. The usage context is mostly implicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sethbang/proton-mail-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server