Mail Notification MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| IMAP_HOST | No | The IMAP server host. Overrides imap.host in config.json. | |
| IMAP_PASS | No | The IMAP password. If not set, the SMTP password (MAIL_SMTP_PASSWORD or smtp.password) is reused. Overrides imap.password in config.json. | |
| IMAP_PORT | No | The IMAP server port. Overrides imap.port in config.json. Default is 993. | |
| IMAP_USER | No | The IMAP username. Overrides imap.username in config.json. | |
| NOTIFY_TO | No | The default recipient email for notifications. Overrides notification.to in config.json. | |
| IMAP_SECURE | No | Whether to use a secure SSL/TLS IMAP connection. Overrides imap.secure in config.json. Should be 'true' or 'false'. | |
| MAIL_SMTP_PASSWORD | No | The SMTP password or app-specific password. Used as the password for both SMTP and IMAP if IMAP_PASS is not set. Overrides the smtp.password in config.json. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_simple_emailB | Send a simple email. |
| send_custom_emailA | Send a custom email with full configuration options. |
| test_smtp_connectionB | Test SMTP connection. |
| test_imap_connectionA | Test IMAP connection and authentication without reading messages. |
| read_repliesA | Read recent reply emails from IMAP. |
| check_approval_statusB | Find an approval reply and classify it as approved, rejected, or pending. |
| wait_for_approvalB | Poll IMAP until an approval is approved, rejected, or times out. |
| send_progress_updateB | Send a standardized work-progress notification. |
| request_human_approvalB | Email a human approval request with a traceable approval ID. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| compose_email | Generate an email draft from intent, recipient name, and tone. Args: intent: What the email should communicate recipient_name: Name of the recipient tone: Desired tone (professional, casual, formal) |
| compose_reply | Generate a reply to an existing email. Args: original_email: The email being replied to intent: What the reply should communicate tone: Desired tone (professional, casual, formal) |
| compose_followup | Generate a follow-up email when no response has been received. Args: original_context: Context of the original message days_since: How long since the original was sent tone: Desired tone (professional, casual, formal) |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| config_status | Current SMTP configuration status (never exposes passwords). |
| providers | List of supported email providers with configuration details. |
TDQS
Scored across 9 tools
There is meaningful overlap between send_simple_email and send_custom_email, both centered on sending mail, and between read_replies, check_approval_status, and wait_for_approval, all of which interact with incoming IMAP replies. The descriptions help separate them, but an agent could still mis-select when trying to perform a generic send or read action.
Most tool names follow a clear verb_noun snake_case pattern, such as test_imap_connection, send_custom_email, and check_approval_status. Minor deviations like wait_for_approval and the generic read_replies keep it from being perfectly uniform, but the naming is still predictable and readable.
With 9 tools, the set is well-scoped for a Mail Notification MCP covering connection testing, email sending, reply reading, and approval handling. Each tool contributes to the server's core purpose without obvious bloat.
The approval workflow is well covered: send a request, read/classify the reply, and wait for a result. Generic mailbox operations like listing folders or fetching arbitrary messages are absent, but those are not central to the stated notification and approval purpose.