Loading ToolBench
MCP server for Proton Mail via Proton Bridge
This server demonstrates solid foundation with 8 well-named tools operating on Proton Mail via IMAP/SMTP. All tools have descriptions (avg 157 chars, within 194-char baseline) and schemas defined in Zod format. However, critical gaps exist: output schemas are not documented, LLMs cannot predict what fields are returned; error handling lacks recovery guidance; parameter descriptions are minimal (12-35 chars, well below 72-char baseline); and composition issues around idempotency and chaining. Tools follow verb_noun naming (proton_ACTION_NOUN) consistently, but descriptions omit execution semantics (which are reversible vs destructive) and many parameters lack constraint documentation. Per-tool analysis: proton_send_email and proton_reply_email are stateful (create side effects) but descriptions don't warn LLMs about retry semantics. proton_move_email is marked REVERSIBLE but the description doesn't say 'reversible'. proton_delete_email moves to Trash (not permanent delete), which the description explains but misses the 'reversible' semantics. No recovery guidance: what happens if send fails mid-way? No batch operations despite potential for bulk actions (e.g., move 10 emails). Output format for proton_list_folders includes a response_format enum (text/json), but no schema documents what 'json' shape is. ReadEmailSchema validates uid is positive but doesn't explain what uid is in plain terms. SearchEmailsSchema accepts 'since' and 'before' as ISO datetime but no validation example. Missing: output pagination hints (are results truncated?), chaining IDs (does list_emails return a UID that read_email accepts?, yes, but not documented), and per-item error details.
Delete an email by moving it to the Trash folder. Use the folder name and email UID.
List emails in a specific folder with pagination. Shows sender, subject, date, and read status. Results are newest first.
List all mailbox folders (INBOX, Sent, Drafts, Trash, etc.) with message counts and unread counts
Move an email from one folder to another. Specify source folder, email UID, and destination folder.
Read the complete content of an email, including headers, body, and attachments. Specify folder and email UID.
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.
Output schemas are not documented. LLMs have no way to predict which fields are returned by list_folders, list_emails, search_emails, or read_email. This forces agents to guess at downstream field names and risks silent failures when expected fields are missing.
Parameter descriptions are too brief. 'Folder name to list emails from' (35 chars), 'Filter by sender email address' (29 chars), 'Email UID (unique identifier)' (28 chars) are below the 72-char baseline. Descriptions should include constraints, examples of valid values, and context for when to use the parameter.
No recovery guidance in error handling. If proton_send_email fails (network error, recipient invalid, quota exceeded), the tool does not guide the LLM on retry strategy, which parameter caused the failure, or what to try next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Search emails by sender, recipient, subject, date range, body content, or unread status. Multiple criteria are combined with AND logic.
Send a new email. Supports plain text and HTML formats. Recipients can be a single string or array of strings.
Write operations lack confirmation/dry-run semantics. proton_send_email and proton_delete_email are irreversible (send cannot be unsent; delete, though marked as moving to Trash, is effectively permanent from user perspective). No confirmation tool or dry-run capability to prevent accidental sends/deletes.
Tool descriptions omit execution semantics. proton_move_email is marked REVERSIBLE but the description says nothing about reversibility. proton_delete_email says 'Delete by moving to Trash' (good) but fails to clarify that this is reversible and that permanent deletion (if Trash is emptied) is not supported.
No batch operations despite high potential for bulk actions. An agent tasked with 'move 50 emails to Archive' must call proton_move_email 50 times serially, wasting tokens and latency. A batch_move_email or move_email_many variant would be more efficient.
Pagination outputs lack explicit totals and next_cursor. proton_list_emails and proton_search_emails accept limit and offset but do not return total message count or next_cursor. This forces the agent to make an extra call (e.g., via search_emails with no parameters) to determine if more results exist.
Parameter constraints undocumented. SendEmailSchema accepts 'to' as string or array but description does not explain format (single email vs comma-separated vs array of objects). ReplyEmailSchema 'reply_all' boolean default is false, good, but description doesn't clarify what happens if reply_all is true (does it include all original recipients or only those on the current message?).