Local MCP

Proton Send Email

proton_send_email

Destructive

Sends a plain-text message from a connected Proton Mail address, through Proton Mail Bridge on this computer. The first call returns a preview with sender, recipients, subject and body, and connects to nothing; confirm=true sends. No attachments. It requires a Proton plan that includes Bridge, with Bridge running.

Input Schema

Name	Required	Description
`cc`	No	Copy recipients, the same form as `to`.
`to`	Yes	Recipient address, or several (an array, or separated by commas).
`body`	Yes	Plain text.
`account`	No	The Proton Mail account: its address, as proton_status lists it. Optional when one account is connected.
`confirm`	No	Must be true to send. Without it the call returns a preview and sends nothing.
`subject`	Yes
`remember`	No	With confirm: true, also stop asking for this kind of action from now on. Only when the person said so ("don't ask again"). The person can revoke it in LMCP or with set_always_allowed.

Output Schema

Name	Required	Description
`cc`	No
`to`	Yes
`body`	No
`from`	Yes
`note`	No
`status`	Yes	preview or sent.
`account`	No
`subject`	Yes
`message_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / account / description

Previous value: -"The Proton Mail account: its address, as proton_connect lists it. Optional when one account is connected."New value: +"The Proton Mail account: its address, as proton_status lists it. Optional when one account is connected."

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / remember

Added value: +{
+  "description": "With confirm: true, also stop asking for this kind of action from now on. Only when the person said so (\"don't ask again\"). The person can revoke it in LMCP or with set_always_allowed.",
+  "type": "boolean"
+}

AddedOct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: the first call returns a preview with sender, recipients, subject, and body, and 'connects to nothing'; confirm=true actually sends. That two-step confirmation model, plus the no-attachments constraint and the Proton Bridge prerequisite, is exactly the behavioral context an agent needs for an irreversible external send. The description is consistent with destructiveHint=true and openWorldHint=true.

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?

Three tight sentences, front-loaded with what the tool does, followed by the preview/confirm behavior and the key limitations. Every sentence carries useful information with no repetition or filler.

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?

Given an output schema and annotations, the description is complete enough to call correctly: it covers channel, prerequisites, the preview-first confirmation flow, and the no-attachments limitation. No critical preconditions or behavioral surprises are left undisclosed.

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 description coverage is 86%, so the schema already explains most parameters. The description reinforces the confirm-gated preview behavior but does not add new meaning for account, remember, cc, to, or subject beyond what the schema provides. Baseline 3 is appropriate when the schema carries most parameter documentation.

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?

States a specific verb and resource: sends a plain-text message from a connected Proton Mail address via Proton Mail Bridge. This clearly distinguishes it from Proton read/list/search tools and from other send-email siblings such as send_email, m365_send_email, and thunderbird_send_email by naming the Proton/Bridge delivery path.

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?

Gives clear preconditions: a Proton plan that includes Bridge, with Bridge running, and a connected Proton Mail address. It also sets a limitation (no attachments), which helps an agent rule it out for attachment use. It stops short of explicitly naming alternative send tools, but the channel-specific wording provides adequate routing context.

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

All Local MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.