Connects to Gmail via IMAP to search and retrieve emails with filtering capabilities by subject, date range, sender, and mailbox, plus the ability to mark emails as read
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Email Management MCP Server search for emails from my boss in the last week and summarize them"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project is designed to summarize emails using a custom IMAP client to connect to the user's email inbox and retrieve relevant messages based on specified criteria.
Connects to an IMAP server to fetch emails.
Can filter emails by:
Subject
Date range
Sender email address
Mailbox (default is 'INBOX')
Related MCP server: mcp-imap-server
Stdio: If you run this server in STDIO mode, all logs are saved in server.log file, in the location where you run the command. You can change this, setting the DEBUG_LOG_FILE environment variable to a custom path (absolute path).
Docker: this mode use STDIO mode, so all logs are saved in server.log file, in the location where you run the command. You can change this, setting the DEBUG_LOG_FILE environment variable to a custom path (absolute path).
Stream: If you run this server in stream mode, all logs are printed to the console.
search-emails: Get emails from the user's inbox.
mark-emails-as-read: Mark specified emails as read.
Install dependencies pnpm install -g @cardor/email-summarizer
Add the configuration to your app client.
"email-summarizer": {
"type": "stdio", // Maybe your client MCP require specific type, like 'stdio'
"command": "cardor-email-summarizer",
"env": {
// Your email address.
"EMAIL_USERNAME": "<your-email>",
// Your email app password.
"EMAIL_PASSWORD": "<your-app-password>",
// The port for the IMAP server (default is 993).
"EMAIL_PORT": "993",
// The type of email client: gmail, outlook, yahoo, etc (default is 'gmail').
"EMAIL_CLIENT_TYPE": "gmail",
// Custom prompt for summarization. Must include `{{emails}}` to insert the email content.
"EMAIL_PROMPT": "Summarize the following emails: {{emails}}",
// You can also use a file path to load the prompt content. You must use absolute path.
// The file types supported are: .txt, .md, .json or .pdf.
// "EMAIL_PROMPT": "file://Absolute/Path/To/Prompt.txt"
// Also you can define a URL to load the prompt content. The URL must return a text content.
// The file types supported are: .txt, .md, .json or .pdf.
// "EMAIL_PROMPT": "https://example.com/path/to/prompt.txt"
}
}Clone the repository git clone <repository-url>
Build the Docker image pnpm run docker:build
Add the configuration to your app client.
"email-dock": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"EMAIL_USERNAME=<your-email>",
"-e",
"EMAIL_PASSWORD=<your-app-password>",
"-e",
"EMAIL_PORT=993",
"-e",
"EMAIL_CLIENT_TYPE=gmail",
"-e",
// Custom prompt for summarization. Must include `{{emails}}` to insert the email content.
// As above, you can use a file path or a URL.
"EMAIL_PROMPT=Summarize the following emails: {{emails}}",
"email-summarizer",
]
}You can also use the HTTP API to interact with the email summarizer. The API expects the following headers:
Clone the repository git clone <repository-url>
Install dependencies pnpm install
Build the MCP pnpm run build
Start the MCP pnpm run start
Use the MCP serve to http://localhost:5555/mcp
Send in headers:
email-username: Your email address.
email-password: Your email app password.
email-port: The port for the IMAP server (default is 993).
email-client-type: The type of email client (default is 'gmail').
email-prompt: Custom prompt for summarization (default is 'Summarize the following emails: {{emails}}'). Must include {{emails}} to insert the email content. As above, you can use a file path or a URL.
I'll be working on:
Allow execute action as marking emails as read, deleting, etc.
Allow override default prompt for the summarization.
Adding more filters and options for email retrieval.
Allow fetch whole body information of the email (text, HTML, attachments, etc.).
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.
| Name | Required | Description | Default |
|---|---|---|---|
| mailbox | No | Mailbox to fetch emails from | INBOX |
| subject | No | Optional subject to filter emails by subject or sender. Only sent if user provides a subject to search EXPLICITLY! | |
| dateRange | Yes | Date range is a dictionary with the keys "start" and "end". Must be provided on date time ISO string format. | |
| senders | No | Optional array of email addresses to filter emails by sender |
| Name | Required | Description |
|---|---|---|
| error | No | |
| emails | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities and default values, but doesn't cover important aspects like pagination behavior, rate limits, authentication requirements, error handling, or what the output contains. For a tool with 4 parameters and an output schema, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise - a single sentence that efficiently communicates the core functionality and key parameters. It's front-loaded with the main purpose and doesn't contain unnecessary information. However, it could be slightly more structured by separating the purpose from parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and 100% schema description coverage, the description is reasonably complete for basic understanding. However, for a tool with 4 parameters including a nested object and no annotations, it should provide more behavioral context about how the filtering works, what happens when no emails match criteria, and typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it mentions the default for 'mailbox' and format for 'dateRange', but these are already covered in the schema. The description's mention of filtering logic is somewhat helpful but doesn't significantly enhance understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('emails from the user's inbox'), making the purpose evident. It distinguishes from the sibling 'send-email' by being a read operation versus a write operation. However, it doesn't explicitly differentiate beyond that basic read/write distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions filtering capabilities but doesn't specify scenarios where filtering is appropriate or when other tools might be better suited. There's no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send Email with subject, destination and body
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination email | |
| subject | Yes | Email subject, min 1 char and max 30 chars | |
| body | Yes | Email body, min 1 char and max 255 chars |
| Name | Required | Description |
|---|---|---|
| error | No | |
| success | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Send Email' implies a write/mutation operation, the description doesn't disclose important behavioral traits like authentication requirements, rate limits, delivery confirmation, error handling, or whether this is a synchronous or asynchronous operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core action and parameters with zero wasted words. Every element in the description serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations but with a complete input schema and output schema available, the description is minimally adequate. However, for an email sending operation that likely has important behavioral considerations (delivery, errors, authentication), the description should provide more context about what happens when the tool is invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the three parameters (subject, destination, body) but adds no semantic meaning beyond what's already fully documented in the input schema (100% coverage). The schema already provides format validation, length constraints, and clear descriptions for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Send') and resource ('Email') along with the key parameters (subject, destination, body). It's specific about what the tool does but doesn't distinguish it from its sibling 'fetch-emails' beyond the obvious action difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'fetch-emails' or provide any context about appropriate use cases, prerequisites, or limitations for sending emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect any mailbox to Claude, ChatGPT & AI: read, send, reply, schedule & search emails.
Read, send, file and search email in any IMAP or Microsoft 365 mailbox, and check it arrived.
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Manage Gmail end-to-end: search, read, send, draft, label, and organize threads. Automate workflow…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Karopatu/email-management-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
