This is a local Email SMTP/IMAP MCP server for managing multiple email accounts from providers like Gmail, iCloud, Outlook, and Fastmail via SMTP/IMAP.
Manage multiple accounts: List all configured accounts, identify the default, and switch by account_name (unlimited named accounts).
Search emails (emails_find): Search by natural language query or structured filters such as sender, recipient, subject, date range, read/unread state, flagged status, and attachment presence. Optionally retrieve full body content and base64-encoded attachments.
Send emails (email_send): Compose and send plain-text or HTML messages with CC, BCC, sender aliases, and base64-encoded file attachments.
Reply and forward (email_respond): Reply, reply-all, or forward an existing email by UID; include original message, forward original attachments, and add new attachments.
Organize inbox (emails_modify): Mark emails as read/unread, flag/unflag, and move them between folders (e.g., Archive, Trash, INBOX).
Browse folders (folders_list): List folders/labels in an account, optionally with total and unread message counts.
Enables sending, searching, replying to, and organizing Gmail emails through SMTP and IMAP protocols, with support for attachments, threading, and folder management.
Enables sending, searching, replying to, and organizing iCloud Mail emails through SMTP and IMAP protocols, with support for attachments, threading, and folder management.
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 SMTP/IMAP MCP Server find unread emails from my boss this week"
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.
One local MCP server for every inbox: search, read, send, reply, forward, and organize email across multiple accounts.
No account-count cap — add work, personal, support, or client inboxes and switch with account_name.
SMTP + IMAP together — send and receive through one small MCP server.
Complete everyday workflow — search, read, reply, forward, attach files, flag, archive, move, and list folders.
Provider-agnostic — works with Gmail, iCloud Mail, Fastmail, Outlook, self-hosted mail, and other standard SMTP/IMAP providers.
Local stdio transport — no hosted relay and no separate control panel.
Related MCP server: Email Send/Receive MCP Server
.envCopy .env.example to a private location and add as many named accounts as you need:
EMAIL_ACCOUNTS_JSON='{
"work": {
"smtp": {
"host": "smtp.gmail.com",
"port": 587,
"secure": false,
"user": "work@example.com",
"password": "app-password"
},
"imap": {
"host": "imap.gmail.com",
"port": 993,
"secure": true,
"user": "work@example.com",
"password": "app-password"
},
"default_from_name": "Your Name",
"sender_emails": ["work@example.com", "alias@example.com"]
},
"personal": {
"smtp": {
"host": "smtp.mail.me.com",
"port": 587,
"secure": false,
"user": "you@icloud.com",
"password": "app-password"
},
"imap": {
"host": "imap.mail.me.com",
"port": 993,
"secure": true,
"user": "you@icloud.com",
"password": "app-password"
}
}
}'
DEFAULT_EMAIL_ACCOUNT="work"The server loads .env from its working directory automatically. EMAIL_ENV_FILE lets an MCP client use an .env stored anywhere.
For Claude Desktop, edit:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"email": {
"command": "npx",
"args": ["-y", "email-smtp-imap-mcp"],
"env": {
"EMAIL_ENV_FILE": "/absolute/path/to/your/.env"
}
}
}
}Use an absolute path, restart your MCP client, then ask: “List my configured email accounts.”
You can skip the .env file and set EMAIL_ACCOUNTS_JSON plus DEFAULT_EMAIL_ACCOUNT directly in the MCP client’s env object. The JSON must be escaped into a single string.
{
"env": {
"EMAIL_ACCOUNTS_JSON": "{\"work\":{\"smtp\":{\"host\":\"smtp.gmail.com\",\"port\":587,\"user\":\"work@example.com\",\"password\":\"app-password\"},\"imap\":{\"host\":\"imap.gmail.com\",\"port\":993,\"user\":\"work@example.com\",\"password\":\"app-password\"}}}",
"DEFAULT_EMAIL_ACCOUNT": "work"
}
}Use SMTP_HOST, SMTP_PORT, SMTP_SECURE, SMTP_USER, SMTP_PASS, IMAP_HOST, IMAP_PORT, IMAP_SECURE, IMAP_USER, and IMAP_PASS instead of EMAIL_ACCOUNTS_JSON.
SMTP_USERNAME/SMTP_PASSWORD and IMAP_USERNAME/IMAP_PASSWORD are accepted aliases. IMAP credentials default to the SMTP credentials when omitted. Use SENDER_EMAILS as a comma-separated allowlist for optional from_email selection.
Tool | What it does |
| List every configured account and identify the default without exposing credentials. |
| Search by text, sender, recipient, subject, date, read state, flag state, or attachments. Optionally return bodies and attachments. |
| Send plain-text or HTML email with CC, BCC, sender aliases, and base64 attachments. |
| Reply, reply-all, or forward by email UID with threading and optional original attachments. |
| Mark read/unread, flag/unflag, or move messages to another folder. |
| List folders with optional total and unread counts. |
Every email tool accepts an optional account_name. Without it, the server uses DEFAULT_EMAIL_ACCOUNT or the first configured account. There is no application-level account-count limit.
After restarting the MCP client, try these in order:
“List my configured email accounts.”
“List folders for my work account.”
“Find the five newest unread emails in my personal account.”
“Send a plain-text email from my work account.”
Provider | SMTP | IMAP | Credential |
Gmail |
|
| |
iCloud Mail |
|
| |
Other providers | Use the provider's SMTP host | Use the provider's IMAP host | Provider password or app password |
Use secure: true for implicit TLS ports such as 465/993. Port 587 normally uses secure: false and upgrades with STARTTLS.
git clone https://github.com/samihalawa/email-smtp-imap-mcp.git
cd email-smtp-imap-mcp
npm ci
npm testRun the compiled stdio server with npm start. Build a production container with docker build -t email-smtp-imap-mcp ..
Issues and focused pull requests are welcome. See CONTRIBUTING.md for the development workflow and SECURITY.md for vulnerability reports.
MIT © Sami Halawa
Reply to or forward an existing email. Use this to continue email conversations, respond to messages, or forward information to others.
| Name | Required | Description | Default |
|---|---|---|---|
| account_name | No | Name of the email account to use | |
| email_id | Yes | ID of the email to respond to (from emails_find results) | |
| response_type | No | 'reply' to sender only, 'reply_all' to all recipients, or 'forward' to new recipients | reply |
| body | Yes | Your response message content | |
| body_type | No | Response body format | html |
| to | No | Array of recipient emails (required for 'forward', optional for replies to override default recipients) | |
| include_original | No | Include the original email content in your response | |
| include_attachments | No | Include attachments from the original email | |
| additional_attachments | No | Additional attachments to include |
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 it mentions the core action (reply/forward), it doesn't describe important behavioral traits like whether this sends the email immediately, requires specific permissions, has rate limits, or what happens on failure. For a mutation tool with 9 parameters, this leaves significant gaps in understanding how the tool behaves beyond basic functionality.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides usage context. There's no wasted text, and the information is front-loaded with the essential action.
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's complexity (9 parameters, mutation operation) and lack of both annotations and output schema, the description is minimally adequate. It covers the basic purpose and usage context but doesn't address behavioral aspects, error conditions, or return values. For a tool that modifies email state, more completeness would be expected to help an agent use it correctly.
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 schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide context about the overall purpose which helps frame parameter usage. This meets the baseline expectation when schema coverage is complete.
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 specific action ('Reply to or forward an existing email') and resource ('email'), distinguishing it from sibling tools like 'email_send' (new emails) and 'emails_modify' (general modifications). It explicitly mentions continuing conversations, responding, and forwarding, which provides comprehensive purpose coverage.
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 clear context for when to use this tool ('to continue email conversations, respond to messages, or forward information to others'), but it doesn't explicitly state when NOT to use it or mention alternatives like 'email_send' for new emails. The guidance is helpful but lacks explicit exclusions or sibling tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a new email with HTML support and file attachments. Use this to send messages, project updates, or any new email conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| account_name | No | Name of the email account to use | |
| to | Yes | Array of recipient email addresses | |
| subject | Yes | Email subject line | |
| body | Yes | Email body content (can be plain text or HTML) | |
| body_type | No | Body format: 'plain' for plain text or 'html' for HTML content | html |
| cc | No | Array of CC recipient email addresses | |
| bcc | No | Array of BCC recipient email addresses | |
| attachments | No | Array of file attachments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions HTML support and file attachments, but fails to address critical aspects like authentication requirements (account_name parameter), rate limits, delivery guarantees, error handling, or whether this is a synchronous or asynchronous operation. For a mutation tool with significant impact, this is inadequate.
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 with two sentences. The first sentence states the core functionality, and the second provides usage examples. There's no unnecessary repetition or fluff. However, it could be slightly more front-loaded with key behavioral information.
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?
For an 8-parameter mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after sending (success/failure indicators, message IDs), doesn't address authentication or permission requirements, and provides minimal guidance on when to use alternatives. The schema does heavy lifting, but the description should compensate for missing behavioral context.
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 8 parameters thoroughly. The description adds minimal value beyond the schema - it mentions HTML support (implied by body_type enum) and file attachments (covered in schema). No additional syntax, format, or constraint details are provided beyond what's in the structured fields.
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 tool's purpose: 'Send a new email with HTML support and file attachments.' It specifies the verb ('send') and resource ('email'), and distinguishes it from siblings like email_respond (reply) and emails_modify (edit). However, it doesn't explicitly differentiate from emails_find (search) beyond the 'new' qualifier.
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 implied usage guidance: 'Use this to send messages, project updates, or any new email conversation.' This suggests it's for initiating conversations rather than replying (email_respond) or modifying existing emails (emails_modify). However, it lacks explicit when-not-to-use instructions or clear alternatives for edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for emails in your inbox with flexible filters. Optionally get full email content and attachments. Use this to find specific emails, check for unread messages, or browse your inbox.
| Name | Required | Description | Default |
|---|---|---|---|
| account_name | No | Name of the email account to use (e.g., 'work', 'personal'). If not provided, uses the default account. | |
| query | No | Natural language search query (e.g., 'unread from boss', 'project update') | |
| filters | No | Structured filters for precise email search | |
| limit | No | Maximum number of emails to return (1-100) | |
| include_content | No | Include full email body content in results | |
| include_attachments | No | Include attachment content (base64 encoded) |
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 'flexible filters' and optional content/attachments but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the return format looks like (e.g., list structure, pagination). For a search tool with 6 parameters, this leaves significant 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 concise and front-loaded, with the core purpose stated in the first sentence. The second sentence adds usage examples without redundancy. However, the examples could be more tightly integrated, and there's room to eliminate minor wordiness (e.g., 'Use this to' is slightly verbose).
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 complexity (6 parameters, nested objects) and lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral constraints, which are crucial for a search tool with filtering options. The agent would struggle to use this effectively without guessing at missing context.
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 adds minimal parameter semantics beyond the schema, which has 100% coverage. It mentions 'flexible filters' and 'optionally get full email content and attachments,' hinting at the 'filters,' 'include_content,' and 'include_attachments' parameters, but doesn't provide additional context like search syntax or performance implications. Given the high schema coverage, the baseline of 3 is appropriate.
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 tool's purpose as 'Search for emails in your inbox with flexible filters' and mentions 'find specific emails, check for unread messages, or browse your inbox.' It specifies the verb (search/find) and resource (emails/inbox) but doesn't explicitly differentiate from sibling tools like 'emails_modify' or 'folders_list' beyond the search focus.
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 implied usage through examples ('find specific emails, check for unread messages, or browse your inbox') but lacks explicit guidance on when to use this tool versus alternatives like 'email_respond' or 'email_send.' It doesn't mention prerequisites or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change email states like read/unread, flagged, or move between folders. Use this to organize your inbox, mark emails as read, archive messages, or flag important emails.
| Name | Required | Description | Default |
|---|---|---|---|
| account_name | No | Name of the email account to use | |
| email_ids | Yes | Array of email IDs to modify (from emails_find results) | |
| mark_read | No | Mark emails as read | |
| mark_unread | No | Mark emails as unread | |
| flag | No | Flag/star emails as important | |
| unflag | No | Remove flag/star from emails | |
| move_to_folder | No | Move emails to a folder (e.g., 'Archive', 'Trash', 'INBOX') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions actions like 'move between folders' and 'mark emails as read', it doesn't address critical behavioral aspects such as whether changes are reversible, what permissions are required, if there are rate limits, or what happens when conflicting parameters are provided (e.g., mark_read and mark_unread both true).
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 sized with two sentences that are front-loaded with the core purpose. The second sentence provides helpful examples without redundancy, though it could be slightly more structured by separating usage scenarios.
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's complexity (7 parameters, mutation operations) and lack of annotations and output schema, the description is insufficient. It doesn't explain return values, error conditions, or behavioral nuances like how multiple state changes interact, leaving significant gaps for an AI agent to understand the tool fully.
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 7 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'move between folders' and 'flag important emails', which slightly reinforces parameter purposes but doesn't provide additional syntax, format details, or usage constraints.
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 tool's purpose with specific verbs ('change email states like read/unread, flagged, or move between folders') and identifies the resource (emails). It distinguishes from sibling tools like email_send or email_respond by focusing on modification rather than creation or response, though it doesn't explicitly differentiate from all siblings.
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 implied usage context with examples ('organize your inbox, mark emails as read, archive messages, or flag important emails'), but lacks explicit guidance on when to use this tool versus alternatives like email_respond or folders_list. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available email folders/labels in your account. Use this to see your folder structure and organize emails.
| Name | Required | Description | Default |
|---|---|---|---|
| account_name | No | Name of the email account to use | |
| include_counts | No | Include unread and total message counts for each folder |
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 listing folders and organizing emails, but fails to disclose critical traits such as whether this requires authentication, rate limits, or how the output is structured (e.g., pagination, error handling). This leaves significant gaps for an agent to understand the tool's behavior.
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 sized with two sentences that are front-loaded and efficient. The first sentence states the purpose clearly, and the second adds context without redundancy, making it easy to parse with minimal waste.
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's low complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but lacks depth. It covers the basic purpose and usage but omits behavioral details like authentication needs or output format, which are important for a tool with no annotations or output schema to rely on.
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 input schema has 100% description coverage, clearly documenting both parameters ('account_name' and 'include_counts'). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 without adding or detracting value.
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 tool's purpose with a specific verb ('List') and resource ('email folders/labels'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'emails_find' or 'emails_modify', which prevents a perfect score.
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 implied usage guidance by mentioning 'to see your folder structure and organize emails', which suggests when this tool might be useful. However, it lacks explicit guidance on when to use this versus alternatives like 'emails_find' for searching emails, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: email_respond handles replies/forwards, email_send creates new emails, emails_find searches, emails_modify changes states, and folders_list enumerates folders. The descriptions reinforce these distinct roles, making tool selection unambiguous.
The naming is mostly consistent with a verb_noun pattern (e.g., email_send, emails_find, folders_list), but there is a minor deviation with email_respond (verb_noun) versus emails_modify (plural_noun_verb). This small inconsistency slightly reduces predictability but remains readable.
With 5 tools, the server is well-scoped for email management. Each tool earns its place by covering core email operations: sending, replying, searching, modifying, and listing folders. This count is appropriate and avoids bloat or thin coverage.
The tool set provides strong coverage for email workflows, including CRUD-like actions (send, find, modify) and folder management. A minor gap is the lack of a tool for creating or deleting folders, but agents can still handle most email tasks effectively with the available tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read, search, send, organize, draft and schedule email across your inboxes from any MCP client.
Read, send, file and search email in any IMAP or Microsoft 365 mailbox, and check it arrived.
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/samihalawa/email-smtp-imap-mcp-archive'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
