Loading ToolBench
Professional ProtonMail MCP server with 23 tools for email management, folder operations, analytics, and seamless Proton Bridge integration.
ProtonMail MCP server has 21 tools with generally present but inconsistently detailed schemas and descriptions. Most tools have basic name-verb structure (send_email, get_emails, search_emails) which is correct. However, many parameter descriptions are generic or missing critical constraints. Output schemas are not explicitly documented, responses are inferred from implementation. Error handling is mentioned but not comprehensive. The server follows basic MCP patterns but lacks production-grade polish in parameter validation guidance, output documentation, and recovery instructions. STDIO transport caps protocol readiness at 50, significantly limiting scoring potential.
🧹 Clear all server logs
📁 Create a new email folder. Use 'Folders/FolderName' for custom folders or 'Labels/LabelName' for labels
🗑️ Delete an email (moves to Trash)
🗑️ Delete an email folder or label (must be empty). Works with 'Folders/' or 'Labels/' prefixes
🔗 Get current SMTP and IMAP connection status
👥 Get email contacts with interaction history
Output schemas not documented. None of the 21 tools explicitly document what fields and types they return. LLMs must infer output structure from descriptions or empirical testing, increasing hallucination risk and preventing pre-planning of downstream tool chains.
Parameter descriptions lack validation constraints. Parameters like 'folder' (in get_emails, search_emails, move_email) describe the semantic meaning but do not specify valid format, regex pattern, or allowed values. 'Folder path (e.g., INBOX, Sent, Folders/MyFolder)' invites LLMs to guess valid paths instead of following a constraint.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
📈 Get advanced email analytics with trends, top contacts, and activity patterns
📧 Get a specific email by its ID (returns full email body and attachments)
📊 Get email statistics and analytics
📬 Get emails from a specific folder with pagination (returns truncated body preview, attachment metadata only)
📁 Get all email folders with statistics. Note: Labels appear as folders with 'Labels/' prefix (e.g., 'Labels/Work')
📋 Get server logs with optional filtering
✅ Mark email as read/unread
📦 Move email to a different folder
✏️ Rename an email folder or label. Works with 'Folders/' or 'Labels/' prefixes
🔍 Search emails with advanced filters (returns truncated body preview, attachment metadata only)
🚀 Send email with advanced options (templates, scheduling, attachments)
🧪 Send a test email to verify SMTP functionality
⭐ Star/unstar email
🔄 Synchronize folder structure from server
🧪 Verify SMTP connection to ProtonMail
Error handling not documented. No tool description explains what errors can occur, what they mean, or how to recover. A failed SMTP connection in send_email or folder operation should guide the LLM to retry, verify credentials, or call verify_smtp_connection. Current descriptions offer no recovery path.
Destructive operations lack confirmation step. delete_email and delete_folder carry HIGH risk (email/folder deleted permanently) but offer no dry-run or confirmation mechanism. Agents can trigger these irreversibly without a safe confirmation pattern.
Tool composition fragmentation. Reading operations return 'truncated body preview, attachment metadata only' (get_emails, search_emails) but get_email_by_id returns full content. This forces agents to call get_email_by_id for most practical workflows, making list operations near-useless. Consider returning full body in all read tools or clearly document when truncation occurs.
No pagination totals or cursors. get_emails and search_emails accept limit and offset but do not document whether they return a total_count or next_cursor. Without this, LLMs cannot determine if more results exist or when to stop paginating, risking infinite loops or incomplete result sets.
Parameter types incomplete or ambiguous. attachments in send_email is described as 'File attachments (base64 encoded)' but lacks array item schema (is each item a string? an object with name+data?). dateFrom/dateTo in search_emails lack format specification (ISO 8601? Unix epoch? Natural language?).
No scope or permission declarations. Tools carry high-risk operations (send_email, delete_email, delete_folder) but do not declare what permissions they require (read:email, write:email, delete:email). This prevents least-privilege agent configuration and audit trail clarity.
Logging and system info tools expose internal operations. get_logs returns server logs with optional filtering, and clear_logs wipes them. No mention of rate-limiting, access control, or log retention policies. Agents could exhaust disk or leak sensitive trace data via get_logs.