Loading ToolBench
MCP server for Proton Mail integration, providing tools to read, send, move, and delete emails via IMAP/SMTP, and fetch calendar events from Proton Calendar ICS feeds.
Proton MCP demonstrates solid definition quality with consistent naming conventions, detailed descriptions, and well-structured input schemas. All 8 tools follow verb_noun naming patterns (calendar, delete_mail, get_mail_body, list_mail_details, list_mail_folders, list_mail_messages, move_mail, send_mail). Descriptions are substantive (120-320 chars) and explain both function and prerequisites. Input schemas use Zod validation with explicit types. However, there are notable gaps: output schemas are not documented, making it unclear what fields agents should expect from responses; error handling guidance is minimal; and some parameter descriptions could be more specific about constraints (e.g., exact date format enforcement, numeric bounds). The calendar tool's complex recurring event logic is well-documented in comments but not exposed to the LLM via the tool description. Security-sensitive tools (delete_mail, send_mail, move_mail) lack explicit permission scope declarations.
Fetches events from Proton Mail calendars via secret ICS links. Use 'list_calendars' to see which calendars are configured, then 'get_events' to retrieve events for a specific calendar and date range.
Permanently deletes an email message via IMAP (Proton Bridge or any IMAP server). This action cannot be undone. The message will be expunged from the mailbox immediately. Configure the server via IMAP_HOST, IMAP_PORT, IMAP_USERNAME, IMAP_PASSWORD, IMAP_SECURITY env vars.
Fetches the body text of a single message by UID. This is the highest-privilege mail tool — it grants access to full message content. Set include_headers to true to also receive subject, sender, and recipient information alongside the body (note: enabling include_headers grants the same header discovery as list_mail_details). Body is truncated at 50,000 bytes.
Lists messages with full header metadata: UID, subject, sender, all recipients (To + Cc), date, size, and read/flagged status. Grants topic discovery via subjects — use list_mail_messages if subject access is not needed. Supports filtering by folder, date range, sender, subject keyword, and read status.
Output schemas are not documented. The rubric requires tools to document return types so LLMs know what fields to expect. Calendar.get_events, list_mail_details, list_mail_messages all return complex objects but responses are undescribed. This forces LLMs to discover structure via trial and error.
Destructive operations (delete_mail, send_mail, move_mail) lack explicit dry-run or confirmation patterns. Per pattern:confirmation-request, irreversible operations should support a confirmation step to prevent catastrophic agent mistakes. No mention of testing mode or rollback capability.
Error handling is underspecified. Tools lack guidance on retryability, user-fixable vs fatal errors, or next-step recovery hints. E.g., if IMAP connection fails, should the agent retry? Contact the user? The tool description does not clarify.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Lists all available mailbox folders. Returns folder names and special-use labels (Inbox, Sent, Trash, etc.) only — no message content, subjects, or sender information.
Lists messages with basic metadata: UID, sender, recipients, date, size, and read/flagged status. Subject is intentionally excluded to limit topic discovery — use list_mail_details to include subjects. Supports filtering by folder, date range, sender address, and read status.
Moves an email message to a different folder via IMAP (Proton Bridge or any IMAP server). Use read_mail with action=list_folders to see available destination folders. Configure the server via IMAP_HOST, IMAP_PORT, IMAP_USERNAME, IMAP_PASSWORD, IMAP_SECURITY env vars.
Sends an email via SMTP (Proton Bridge or any SMTP server). Requires IMAP_USERNAME and IMAP_PASSWORD (or SMTP_USERNAME and SMTP_PASSWORD) to be set. Configure the server via SMTP_HOST, SMTP_PORT, SMTP_SECURITY env vars.
Permission scopes are not declared. Tools like delete_mail, send_mail, and move_mail should declare required scopes (e.g., 'write:email', 'delete:email') per pattern:scope-declaration. This prevents least-privilege configuration and audit clarity.
Numeric parameter bounds are missing. list_mail_details and list_mail_messages accept a 'limit' parameter (1 - 100) with a default of 20, but the description says '(1 - 100)' as text rather than enforcing this via schema validation. The Zod schema does not appear to include explicit min/max constraints visible in the source.
Date format flexibility is not machine-enforced. Calendar tool accepts 'ISO 8601 format' but description mentions accepting 'today' or 'this Friday', natural language. No clear statement of what formats are actually supported or how the parser handles ambiguity (e.g., '01/02/2024' in MM/DD vs DD/MM locales).
Parameter dependencies are undocumented. calendar.get_events requires calendar_name when action='get_events' but not when action='list_calendars'. This conditional requirement should be explicit in all three parameter descriptions (action, calendar_name, start_date, end_date).