MCP server for IMAP email access via ProtonMail Bridge
The server provides 12 email tools with consistent naming (verb_noun pattern) and generally clear descriptions. Input schemas are well-defined with type information and parameter descriptions. However, there are notable gaps: output schemas are not documented in the provided code, descriptions lack depth regarding when tools should be used relative to each other, no explicit error handling guidance, and parameter constraints (min/max for limits, enum values for mailbox names) are missing. Most tools follow the pattern of 10-200 character descriptions, but some are at the lower end (e.g., 'Remove a tag/flag from an email' = 34 chars). The server is functionally complete for email operations but lacks production-grade polish in discovery and error recovery patterns.
Apply a tag/flag to an email
Download an attachment from an email and save it to the configured attachment directory
Get all available tags/flags for a mailbox
Get the full content of a single email by ID
Get all tags currently applied to an email
Get inbox items (emails from a mailbox with optional date filter)
List all mailboxes (folders) available in the IMAP account
Output schemas are not documented. The code shows input schemas clearly, but tool descriptions do not specify what fields are returned or their types. This prevents LLMs from planning downstream operations or extracting required data.
Parameter constraints missing. 'limit' parameters accept 1-200 but this range is only in the description text, not as JSON Schema minItems/maxItems constraints. 'fields' enum values for search_emails are listed in description ('text, subject, from, to, body') rather than as an enum constraint. LLMs cannot reliably parse text descriptions to extract constraints.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 75 | 2026-07-28+ | v2 |
Move a single email to another mailbox
Move multiple emails to another mailbox in a batch operation
Remove a tag/flag from an email
Search emails by keyword in specified fields
Send an email or reply to an existing email
Error handling and recovery guidance absent. No tool description explains what errors might occur, whether they are retryable, or what the LLM should do next. For example, if 'email_id' is invalid, should the LLM list emails and retry, or ask the user? No guidance.
Tool selection disambiguation missing. When multiple tools operate on similar resources (e.g., apply_tag, remove_tag, get_email_tags, get_available_tags all deal with tags), descriptions do not clearly explain which to call first or in what order. 'Call get_available_tags first to see what tags exist before applying' would guide the LLM.
Destructive operation warnings missing. Tools like move_email, move_emails, and remove_tag modify state but descriptions do not explicitly say 'This is irreversible' or 'This will permanently remove', key information for LLM caution. The Risk field labels them REVERSIBLE or WRITE, but tool descriptions should reinforce this.
No confirmation or dry-run pattern. Irreversible operations like send_email and move_emails accept no confirmation flag or dry-run mode. An agent could accidentally send malformed emails or move thousands of emails to the wrong folder without a safety mechanism.
Pagination and result limits not enforced in schema. get_inbox and search_emails both have a 'limit' parameter (capped at 200) but no offset/page/cursor parameter is visible for retrieving subsequent results. If an agent needs >200 emails, it cannot paginate, it must retry with a different mailbox or filter.
Short descriptions on some tools. 'Remove a tag/flag from an email' is only 34 characters, below the 50-char baseline for clarity. Expands to: 'Remove a tag or flag from an email. This operation is irreversible once confirmed. The email will retain all other tags/flags.'