Email Management MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EMAIL_PORT | No | The port for the IMAP server | 993 |
| EMAIL_PROMPT | No | Custom prompt for summarization. Must include {{emails}} to insert the email content. Can also use a file path (absolute path) or URL to load prompt content | Summarize the following emails: {{emails}} |
| DEBUG_LOG_FILE | No | Custom path (absolute path) for the debug log file | |
| EMAIL_PASSWORD | Yes | Your email app password | |
| EMAIL_USERNAME | Yes | Your email address | |
| EMAIL_CLIENT_TYPE | No | The type of email client: gmail, outlook, yahoo, etc | gmail |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fetch-emailsC | Get emails from the user's inbox. Can specify the mailbox (INBOX by default), a subject (string), date range (ISO format: YYYY-MM-DDTHH:mm:ss), and sender emails (list of strings) to filter emails. |
| send-emailB | Send Email with subject, destination and body |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| send-email | Send an email to a specified recipient with a subject and body content. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: fetch-emails retrieves emails from an inbox with filtering options, while send-email sends emails out. There is no overlap in functionality, making it easy for an agent to choose the correct tool for reading versus sending.
Both tools follow a consistent verb-noun pattern with hyphen separation (fetch-emails, send-email). The naming is predictable and readable, with no deviations in style or convention across the set.
With only 2 tools, the server feels thin for an email management domain. Key operations like replying to emails, deleting emails, managing folders, or marking emails as read are missing, which limits the server's utility and scope.
The toolset is severely incomplete for email management. It covers basic fetch and send but lacks essential CRUD/lifecycle operations such as update (e.g., reply, forward), delete, or organizational functions (e.g., move to folder). This will cause agent failures in common email workflows.