Which integrations are available for this server?

Provides comprehensive email management capabilities for Proton services via Proton Mail Bridge, enabling folder navigation, searching, reading messages with attachments, and sending or replying to emails. Enables full email management for Proton Mail through Proton Mail Bridge, allowing users to list folders, search and read emails, send new messages and replies, and manage mailbox organization.

How do I use Proton MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Proton MCP Server find the latest email from GitHub and summarize its content" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Proton MCP Server

by cogghaus

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Proton MCP Server

A complete TypeScript Model Context Protocol (MCP) server for Proton Mail integration via Proton Mail Bridge.

What This Does

This MCP server provides full email management capabilities through Claude Code by connecting to Proton Mail Bridge running locally. It allows you to:

List and browse mailbox folders
List, search, and read emails
Send new emails and replies
Move and delete emails
Access full message content with attachments

Related MCP server: ProtonMail MCP Server

Prerequisites

Proton Mail Bridge running and accessible on localhost:
- IMAP server on port 1143 (STARTTLS)
- SMTP server on port 1025 (STARTTLS)
Node.js 18 or higher
A valid Proton Mail account with Bridge credentials

Setup

1. Install Dependencies

npm install

2. Configure Environment

Copy the environment template and add your Proton credentials:

cp .env.example .env

Edit .env with your settings:

PROTON_IMAP_HOST=127.0.0.1
PROTON_IMAP_PORT=1143
PROTON_SMTP_HOST=127.0.0.1
PROTON_SMTP_PORT=1025
PROTON_USER=your-proton-email@protonmail.com
PROTON_PASS=your-bridge-password

3. Build

npm run build

4. Run Locally (Development)

npm run dev

Or run the compiled version:

npm start

Usage with Claude Code

Add this MCP server to your Claude settings (~/.claude/settings.json):

{
  "mcpServers": {
    "proton": {
      "command": "node",
      "args": ["/path/to/proton-mcp-server/dist/index.js"],
      "env": {
        "PROTON_USER": "your-email@protonmail.com",
        "PROTON_PASS": "your-bridge-password",
        "PROTON_IMAP_HOST": "127.0.0.1",
        "PROTON_IMAP_PORT": "1143",
        "PROTON_SMTP_HOST": "127.0.0.1",
        "PROTON_SMTP_PORT": "1025"
      }
    }
  }
}

Or with TypeScript/tsx:

{
  "mcpServers": {
    "proton": {
      "command": "npx",
      "args": ["tsx", "/path/to/proton-mcp-server/src/index.ts"]
    }
  }
}

Available Tools

Reading Tools (Read-Only)

proton_list_folders — List all mailbox folders with message and unread counts
proton_list_emails — List emails in a folder with pagination (newest first)
proton_search_emails — Advanced search with filters (from, to, subject, date range, body content, unread status)
proton_read_email — Read the complete email content including headers, body, and attachment list

Writing Tools

proton_send_email — Send a new email (plain text or HTML)
proton_reply_email — Reply to an email with proper threading headers
proton_move_email — Move email to another folder
proton_delete_email — Delete email (move to Trash)

Project Structure

proton-mcp-server/
├── src/
│   ├── index.ts              # Main entry point
│   ├── constants.ts          # Configuration constants
│   ├── types.ts              # TypeScript interfaces
│   ├── schemas/
│   │   └── index.ts          # Zod input schemas
│   ├── services/
│   │   ├── imap.ts           # IMAP client wrapper
│   │   └── smtp.ts           # SMTP client wrapper
│   └── tools/
│       ├── folders.ts        # proton_list_folders
│       ├── list.ts           # proton_list_emails
│       ├── search.ts         # proton_search_emails
│       ├── read.ts           # proton_read_email
│       ├── send.ts           # proton_send_email
│       ├── reply.ts          # proton_reply_email
│       ├── move.ts           # proton_move_email
│       └── delete.ts         # proton_delete_email
├── package.json
├── tsconfig.json
├── .env.example
├── .gitignore
└── README.md (this file)

Implementation Notes

IMAP Connection

Uses imapflow library with STARTTLS on port 1143
Proton Bridge uses self-signed certificates, so tls.rejectUnauthorized: false
All connections are properly closed with logout() in finally blocks

SMTP Connection

Uses nodemailer with STARTTLS on port 1025
Supports plain text and HTML email bodies
Properly sets In-Reply-To and References headers for email threading

Message Parsing

Uses mailparser to extract full message content
Supports text, HTML, and attachment handling
Returns attachment metadata (filename, content type, size)

Pagination

Email list pagination uses offset and limit parameters
Results are always newest first
Search results also support pagination

Troubleshooting

Connection Issues

Ensure Proton Mail Bridge is running: protonmail-bridge --cli
Check localhost connectivity: telnet 127.0.0.1 1143 (IMAP) and 1025 (SMTP)
Verify credentials in .env file

Email Issues

Some email clients may not recognize replies without proper Message-ID headers
HTML emails are parsed to text; use the raw HTML body for better formatting
Large attachments may take time to process

Build Issues

Ensure Node.js 18+ is installed: node --version
Clear node_modules and reinstall: npm clean-install
Check TypeScript compilation: npm run build

Dependencies

@modelcontextprotocol/sdk — MCP protocol implementation
imapflow — IMAP client for email reading
nodemailer — SMTP client for sending emails
mailparser — Email parsing and content extraction
zod — Input validation schemas
dotenv — Environment variable loading

License

MIT

Support

For issues with Proton Mail Bridge, see: https://proton.me/support/bridge

For MCP protocol documentation, see: https://modelcontextprotocol.io

Available Tools

8 tools

proton_delete_emailDelete EmailA

DestructiveIdempotent

Delete an email by moving it to the Trash folder. Use the folder name and email UID.

ParametersJSON Schema

Name	Required	Description	Default
`folder`	No		INBOX
`uid`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate destructive and idempotent behavior. The description adds the specific behavioral detail that deletion is performed by moving to the Trash folder, which is not available from annotations alone. This provides useful context beyond what annotations state.

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 concise: a single sentence that immediately states the action and the required inputs. Every part earns its place without unnecessary words.

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 simple tool with two parameters and no output schema, the description is adequately complete. It explains the core behavior and parameter usage. However, it could mention success/failure behavior or error conditions to be fully complete.

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?

The schema has 0% description coverage, so the description must add meaning. It maps 'folder name' and 'email UID' to the parameters uid and folder, but does not elaborate on format, ranges, or the fact that folder defaults to INBOX. The description provides basic semantic context but lacks detailed parameter guidance.

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 that the tool deletes an email by moving it to the Trash folder. It specifies the action (delete) and the resource (email), and it distinguishes itself from sibling tools like proton_list_emails or proton_move_email by explicitly mentioning moving to Trash.

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 provides some implicit guidance by stating the action is moving to Trash, which implies standard deletion. However, it does not explicitly compare to other tools like proton_move_email (which could also move to Trash) or explain when to use this versus a hard delete or other methods. No explicit when-to-use or when-not-to-use guidance is given.

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

proton_list_emailsList Emails in FolderA

Read-onlyIdempotent

List emails in a specific folder with pagination. Shows sender, subject, date, and read status. Results are newest first.

ParametersJSON Schema

Name	Required	Default
`folder`	No	INBOX
`limit`	No
`offset`	No

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's main contribution is contextual: results are newest first, pagination details, and shown fields. No contradictions. Adds value but annotations cover safety.

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 sentences with no redundancy. The first sentence states the core purpose, the second describes output, and the third specifies order. No wasted words.

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?

Given no output schema, the description mentions the fields shown (sender, subject, date, read status), which is good. However, it does not describe the overall return structure (e.g., array, total count). Adequate for a simple list tool but could be richer.

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 0%, so the description must compensate. It hints at 'specific folder' for the folder parameter and 'pagination' for limit/offset, but does not explain the values, defaults, or min/max constraints. Adequate but not detailed.

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 action (list emails), the resource (specific folder), the output fields (sender, subject, date, read status), and ordering (newest first). It effectively distinguishes from sibling tools like proton_search_emails and proton_read_email.

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?

The description implies usage for browsing emails in a folder with pagination, which is distinct from searching or reading single emails. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a perfect score.

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

proton_list_foldersList Proton Mail FoldersA

Read-onlyIdempotent

List all mailbox folders (INBOX, Sent, Drafts, Trash, etc.) with message counts and unread counts

ParametersJSON Schema

Name	Required	Description	Default
`response_format`	No		text

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying what data is returned (counts), which is not in annotations.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose and output. No unnecessary words.

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 simple list tool with minimal parameters and annotations present, the description is sufficiently complete. It covers what the tool does and returns, though it omits mention of response format or pagination.

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

Parameters2/5

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

Schema description coverage is 0%. The one parameter (response_format) is not mentioned in the description. Though the enum values are self-explanatory, the description adds no meaning 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 action (list), resource (mailbox folders), and the returned data (message counts and unread counts). It distinguishes from sibling tools which operate on emails.

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?

While the purpose is clear, the description does not explicitly state when to use this tool versus alternatives like email search tools. The usage context is implied but not spelled out.

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

proton_move_emailMove EmailB

Idempotent

Move an email from one folder to another. Specify source folder, email UID, and destination folder.

ParametersJSON Schema

Name	Required	Description	Default
`folder`	Yes
`uid`	Yes
`destination`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Annotations indicate idempotentHint=true, but the description does not elaborate on behavioral traits like side effects, error conditions, or what happens if the source/destination is invalid. It adds minimal context beyond what annotations provide.

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?

Two short sentences, no fluff. The information is front-loaded. Could have been one sentence, but it's still efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple move operation with three parameters, but lacks details on idempotency, return values, or prerequisites. Better descriptions would cover what happens on failure or whether the operation is reversible.

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

Parameters2/5

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

With 0% schema description coverage, the description must compensate. It merely restates parameter names ('source folder, email UID, and destination folder') without adding format, constraints, or examples. The value added is nearly zero.

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 'Move an email from one folder to another.' It specifies the verb (move) and resource (email), distinguishing it from sibling tools like delete, list, or read.

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?

No guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites (e.g., folder existence), or exclusions (e.g., not for copying).

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

proton_read_emailRead Full EmailA

Read-onlyIdempotent

Read the complete content of an email, including headers, body, and attachments. Specify folder and email UID.

ParametersJSON Schema

Name	Required	Description	Default
`folder`	No		INBOX
`uid`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns complete content (headers, body, attachments), which is useful but minimal. No disclosure of potential size limits or pagination.

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?

Two sentences, direct and front-loaded. Every sentence provides value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and description doesn't specify return format (e.g., JSON structure, attachment encoding). For a tool that returns full email content, this is a significant gap. However, the tool is simple with only 2 parameters.

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 0% (no descriptions in schema). Description mentions both parameters (folder, email UID) but doesn't explain constraints like uid format or folder naming. Partially compensates for missing schema 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?

Description clearly states the verb 'Read' and resource 'email', and specifies scope: complete content including headers, body, attachments. Distinguishes from sibling tools like proton_list_emails which likely list metadata only.

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?

Description implies when to use (need full email content) but lacks explicit guidance on when not to use or comparison to alternatives like proton_search_emails. No prerequisites stated.

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

proton_reply_emailReply to EmailA

Send a reply to an existing email. Properly sets In-Reply-To and References headers for threading. Can reply to all or just the sender.

ParametersJSON Schema

Name	Required	Default
`folder`	No	INBOX
`uid`	Yes
`body`	Yes
`reply_all`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations set readOnlyHint=false and destructiveHint=false, indicating mutation without destruction. Description adds behavioral detail about setting In-Reply-To and References headers, which is beyond annotations.

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?

Two concise sentences with no fluff. Could improve by structuring parameter details, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has 4 parameters (2 required) and no output schema. Description lacks details on body format, folder role, or expected errors. Incomplete for reliable invocation.

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

Parameters2/5

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

Schema description coverage is 0%; description only mentions reply_all behavior. Does not clarify uid, body, or folder parameters. Body format and folder usage are missing, leaving ambiguity.

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?

Title 'Reply to Email' and description clearly state the action: sending a reply with threading headers. Distinguishes from sibling tools like proton_send_email which creates new emails.

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?

Description indicates when to use reply_all vs just sender. Context with sibling tools implies this is for replies, not new emails. No explicit when-to-use or exclusions, but clear enough.

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

proton_search_emailsSearch EmailsA

Read-onlyIdempotent

Search emails by sender, recipient, subject, date range, body content, or unread status. Multiple criteria are combined with AND logic.

ParametersJSON Schema

Name	Required	Default
`folder`	No	INBOX
`from`	No
`to`	No
`subject`	No
`since`	No
`before`	No
`body`	No
`unseen_only`	No
`limit`	No
`offset`	No

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds the AND logic and filter criteria, but does not explain pagination (offset/limit) or rate limits. No contradiction with annotations.

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?

Two sentences, no redundant information, front-loaded with the core action and criteria. Concisely conveys essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters and no schema descriptions, the description covers about 60% of parameters. It lacks explanation of limit, offset, folder, and does not mention that results are paginated. Overall acceptable but not exhaustive.

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?

With 0% schema description coverage, the description compensates partially by listing most key parameters (from, to, subject, since/before, body, unseen_only), but misses limit, offset, and folder. Names are self-explanatory but incomplete.

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 verb 'search' and resource 'emails', lists specific filter criteria (sender, recipient, subject, date range, body content, unread status), and notes AND logic. It distinguishes from siblings like proton_list_emails.

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 implies usage for searching with multiple filter criteria, but does not explicitly state when not to use or provide alternatives. It lacks guidance on using proton_list_emails for unfiltered listing.

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

proton_send_emailSend EmailB

Send a new email. Supports plain text and HTML formats. Recipients can be a single string or array of strings.

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes
`cc`	No
`bcc`	No
`subject`	Yes
`body`	Yes
`html`	No

TDQS

B3.4/5.0

Behavior3/5

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

Annotations provide basic non-readonly, non-destructive hints. Description adds 'plain text and HTML' support but lacks details on limits, attachments, or consequences.

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 concise sentences with no redundant information. Front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks crucial context: no return value description, no error information, no mention of attachment handling or size limits. Incomplete for a 6-parameter tool without output schema.

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?

With 0% schema coverage, description partially compensates by explaining recipients format and body format. However, 'cc', 'bcc', and 'html' boolean details are missing.

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?

Clearly states 'Send a new email' with explicit support for plain text and HTML. Distinguishes from sibling tools like reply and move.

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?

No guidance on when to use this tool versus alternatives (e.g., reply, forward). No prerequisites or exclusions mentioned.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv1.0.0Mar 17, 2026
- First observedproton_delete_email
- First observedproton_list_emails
- First observedproton_list_folders
- First observedproton_move_email
- First observedproton_read_email
- First observedproton_reply_email
- First observedproton_search_emails
- First observedproton_send_email

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored 2026-04-17 20:06 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific email operations: listing, reading, sending, replying, searching, moving, deleting, and folder management. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency5/5

All tool names follow a consistent 'proton_verb_noun' pattern using snake_case, such as proton_list_emails and proton_send_email. This uniformity enhances readability and predictability across the toolset.

Tool Count5/5

With 8 tools, the server is well-scoped for email management, covering essential operations like CRUD (create, read, update via move/reply, delete), search, and folder handling. Each tool serves a clear purpose without redundancy.

Completeness5/5

The toolset provides complete coverage for email workflows, including listing, reading, sending, replying, searching, moving, deleting, and folder management. There are no obvious gaps, enabling agents to handle full email lifecycle tasks effectively.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3
AgentMailOAuth
to.agentmail
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Email Communication
2

Related MCP Servers

protonmail-mcp
Email Security
darkroomdevs
A
license
Not graded
quality
C
maintenance
Enables AI clients to interact with ProtonMail accounts through the Proton Bridge using SMTP and IMAP protocols. Provides email management capabilities via secure local bridge connections.
Updated 5 months ago (2026-04-17 21:25 UTC)
11
MIT
ProtonMail MCP Server
Email Communication
ronamosa
A
license
A
quality
C
maintenance
Enables AI agents to send, read, search, and organize emails via ProtonMail using Proton Bridge. Supports MCP-compatible clients like Claude and Cursor.
Updated 3 days ago (2026-09-10 02:49 UTC)
17
7
3
MIT
Proton Mail MCP Server
Email Communication
fincher65
A
license
Not graded
quality
C
maintenance
Enables AI assistants to send, read, search, and organize Proton Mail email via SMTP and IMAP through the Model Context Protocol.
Updated 21 days ago (2026-08-23 03:43 UTC)
MIT
proton-bridge-mcp
Communication Email
Considus
A
license
A
quality
A
maintenance
Enables AI assistants to read, organize, and send Proton Mail through the local Proton Bridge, with careful gating for sending and attachment access.
Updated 13 days ago (2026-08-31 13:25 UTC)
6
34
1
Apache 2.0