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 "Deploy 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, the description carries the full burden for behavioral disclosure. It fails to mention that this tool sends an email (a consequential, irreversible action), nor does it discuss permissions, delivery semantics, or failure handling. The description is purely functional and lacks transparency about side effects.
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 two sentences, front-loads the core action, and contains no filler or redundant information. Every sentence earns its place.
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 a tool with 9 parameters, no output schema, and no annotations, the description is minimal. It gives a basic orientation but does not offer guidance on complex behaviors like reply-all vs forward, attachment handling, or account selection, leaving the agent to rely solely on the schema.
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 coverage is 100%, so the description does not need to explain parameters in detail. The description adds only high-level context ('reply', 'forward') that aligns with the schema's parameter definitions, providing no extra semantic value beyond the schema.
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 a specific action ('Reply to or forward') on a specific resource ('an existing email'), and the phrase 'existing email' helps distinguish from sending a new email. However, it does not explicitly name sibling tools like email_send, so it lacks full differentiation.
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 use cases: 'continue email conversations, respond to messages, or forward information to others.' This gives context for when to use the tool, but it does not explicitly mention when not to use it or point to alternatives like email_send for composing new emails.
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 must carry the full burden of behavioral transparency. It explains basic state changes but does not disclose potential side effects, permission requirements, or behavior with conflicting flags (e.g., mark_read=true and mark_unread=true together). It is not misleading, but lacks depth for a tool with multiple conditional actions.
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: two sentences that front-load the core purpose and then give practical use cases. There is no wasted text or redundancy. Every sentence contributes to understanding the tool's functionality.
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?
The tool has 7 parameters with potential conflicts and no output schema or annotations. The description does not address edge cases such as mutually exclusive flags or the effect of moving an email out of a folder. While the schema covers parameters, the behavioral context is partially incomplete for a moderately complex modification tool.
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. The description does not add additional parameter-level meaning beyond the schema. Baseline 3 is appropriate since the description gives general usage examples but no syntax or parameter-specific clarifications.
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 function: 'Change email states like read/unread, flagged, or move between folders.' It uses a specific verb ('change') and resource ('email states') and lists concrete examples. This distinguishes it from sibling tools like emails_find (search), email_send (send), and email_respond (reply), which handle different operations.
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 context on when to use the tool: 'Use this to organize your inbox, mark emails as read, archive messages, or flag important emails.' This implies appropriate scenarios without explicitly naming alternatives or exclusions. Given the sibling set, the use cases are clear enough.
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. It states the primary behavior (listing folders) but does not add details about read-only nature, potential side effects, or the meaning of the optional include_counts parameter. For a simple list operation, the behavior is fairly transparent, but the description adds little beyond the schema.
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 two concise sentences, front-loaded with the purpose and followed by a clear usage note. Every sentence earns its place with no fluff or redundancy.
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 a simple list tool with no output schema, the description provides adequate context: it tells what it lists and why to use it. It could mention the include_counts option or behavior when account_name is omitted, but the schema covers these details, and the overall purpose is clear.
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 baseline is 3. The description does not discuss parameters, but the schema fully documents account_name and include_counts, so no additional explanation is required.
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 function: 'List all available email folders/labels in your account.' It uses a specific verb and resource, and is easily distinguished from sibling tools like accounts_list and emails_find, which focus on accounts and emails respectively.
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 the tool: 'Use this to see your folder structure and organize emails.' It does not explicitly mention alternatives or exclusions, but the purpose is distinct enough that this is not a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0email_respondemail_sendemails_findemails_modifyfolders_listScored across 5 tools
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.
Read, send, file and search email in any Gmail, Microsoft 365 or IMAP mailbox, plus its calendar.
Read, send, organize, watch email on any IMAP mailbox: Gmail, iCloud, OVH, Zoho, Fastmail + CalDAV.
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.
