This server provides an email automation toolkit for sending, receiving, searching, drafting, and managing emails via SMTP/IMAP, compatible with Gmail, Outlook, Yahoo, Fastmail, and any standard email provider.
Send Emails (send_email): Send emails via SMTP with support for plain text or HTML bodies, multiple recipients, CC, and BCC. Includes a safety confirmation/preview mode before actual sending.
Read Inbox (read_inbox): Retrieve recent emails (up to 25) from any mailbox folder, returning subject, sender, date, and body preview.
Search Emails (search_emails): Search emails by sender, subject keyword, recipient, read/unread status, flagged status, or full-text across any IMAP folder.
Create Drafts (create_draft): Save a composed email to your Drafts folder without sending, for later review and sending from your email client.
List Folders (list_folders): Discover all available mailbox folders (e.g., INBOX, Sent, Drafts, Spam) on the IMAP server to use as targets for other operations.
Allows sending and reading emails via Gmail's SMTP/IMAP protocols.
Email toolkit via SMTP/IMAP: send emails, read inbox, search, create drafts, and list folders
Email toolkit via SMTP/IMAP: send emails, read inbox, search, create drafts, and list folders. Works with Gmail, Outlook, Yahoo, Fastmail, and any standard provider. By MEOK AI Labs.
# Install via pip
pip install email_automation_mcp
# Or install via Smithery
npx -y @smithery/cli@latest install email-automation-mcp --client claudeRelated MCP server: Email MCP Server
MCP protocol compliant
Easy installation
Well-documented API
Production-ready
Active maintenance
This MCP server is built with EU AI Act compliance built-in:
ā Article 9 ā Risk Management System
ā Article 13 ā Transparency & Instructions for Use
ā Article 15 ā Bias Detection & Testing
ā Article 26 ā FRIA Support (where applicable)
ā Article 50 ā AI Content Watermarking (where applicable)
Need help getting compliant? Book a free 15-min diagnostic ā
Need custom development, SLA guarantees, or white-label deployment?
Pro: $99/mo ā Full MCP suite + EU AI Act tracking
Enterprise: $499/mo ā Custom dev + SLA + Dedicated support
View Pricing ā | Contact Sales ā
This server is part of the MEOK AI Labs ecosystem ā 300+ MCP servers for sovereign AI governance.
Domain | Purpose |
EU AI Act compliance marketplace | |
AI safety & monitoring | |
Sovereign AI platform | |
Legacy modernization |
MIT Ā© CSOAI-ORG
Build something that touches users? You need compliance. MEOK ships 38 governance MCPs that drop in alongside this tool ā EU AI Act, DORA, NIS2, CRA, GDPR, ISO 42001, FDA SaMD, MDR, Basel, MiFID II, MiCA, COPPA, and more.
# One-shot install of the governance pack
npx meok-setup --pack governanceFree tier: 10 calls/day per MCP. Pro tier (Ā£79/mo): unlimited + cryptographically signed compliance attestations your auditor verifies independently.
ā Full catalogue: councilof.ai/catalogue ā MEOK AI Labs: meok.ai
Tier | Price | What you get | Stripe |
Smoke test | Ā£1 | Signed sample MCP-Hardening report + Article 50 PDF | |
Quick Kit | Ā£9 | EU AI Act Article 50 implementation guide (C2PA + EU-Icon) | |
Founder Call | Ā£29 | 30-min 1-on-1 with the founder |
Refundable. UK Stripe ā VAT-clean. Builds on the 81-MCP MEOK fleet. Verify any signed report at https://meok.ai/verify.
Add to your claude_desktop_config.json (Claude Desktop) or your MCP client config:
{
"mcpServers": {
"email-automation-mcp": {
"command": "uvx",
"args": ["email-automation-mcp"]
}
}
}Or: pip install email-automation-mcp then run the email-automation-mcp command (stdio transport).
Once configured, ask your assistant, for example:
"Use send_email to ā¦"
"Use read_inbox to ā¦"
"Use search_emails to ā¦"
MEOK compliance MCP fleet:
email-validator-ai-mcp
Save an email as a draft without sending it. The draft appears in your Drafts folder and can be sent later from your email client.
Args: to: Recipient email address subject: Email subject body: Email body text
Behavior: This tool generates structured output without modifying external systems. Output is deterministic for identical inputs. No side effects. Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results. Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent ā calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| subject | Yes | ||
| body | Yes | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'Behavioral Transparency' section claims the tool is read-only with no side effects, but saving a draft inherently modifies state. This contradicts the tool's actual behavior. The detailed security/rate-limit information is copied from a different type of tool and does not fit an email draft creator.
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 lengthy and contains irrelevant sections (e.g., behavioral transparency for a different tool). Information is repeated and not front-loaded. The first paragraph is concise, but the rest is unnecessary and misleading.
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 4 parameters, no output schema, and no annotations, the description fails to provide complete guidance. It does not explain how to use the tool, what the response looks like, or what happens after saving. The contradictory sections make it unusable.
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 lists 'to', 'subject', 'body' in the Args section but provides no format, constraints, or examples. The 'api_key' parameter is not mentioned. With 0% schema description coverage, the description adds minimal value beyond parameter names.
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 first sentence clearly states 'Save an email as a draft without sending it', specifying the verb (save), resource (draft), and distinct action (not sending). This distinguishes it from 'send_email' among 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 'When to use' section is generic and unrelated ('structured analysis or classification'), and the 'When NOT to use' mentions 'real-time production decision-making', which does not apply to drafting emails. These sections are misleading and contradict the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all mailbox folders (INBOX, Sent, Drafts, etc.) available on the IMAP server. Useful for discovering folder names before reading or searching.
Behavior: This tool generates structured output without modifying external systems. Output is deterministic for identical inputs. No side effects. Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results. Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent ā calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It covers read-only, side effects, authentication, rate limits, error handling, idempotency, and data privacy. However, inconsistencies with the generic text reduce clarity.
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?
Overly verbose with repetitive and irrelevant sections (e.g., generic behavioral text copied from another tool). Could be significantly shorter without losing essential 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?
Covers many behavioral aspects (rate limits, error handling, etc.) but the irrelevant sections undermine completeness. For a simple list tool, the key purpose and behavior are adequately described.
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?
Only one parameter (api_key) with schema coverage 0%. The description explains it's optional for basic usage and required for higher tiers, adding meaning beyond 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 first sentence clearly states the tool lists mailbox folders (INBOX, Sent, etc.), but later generic text about 'structured analysis or classification' contradicts the actual purpose and confuses the agent.
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?
Provides some context ('Useful for discovering folder names before reading or searching'), but includes contradictory guidance recommending the tool for 'structured analysis' which is misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read recent emails from a mailbox folder. Returns subject, from, date, and body preview for each message.
Args: folder: IMAP folder name (default: INBOX) limit: Max emails to return (default: 10, max: 25)
Behavior: This tool is read-only and stateless ā it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results. Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent ā calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | INBOX | |
| limit | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description provides a comprehensive 'Behavioral Transparency' section covering side effects (read-only, no side effects), authentication, rate limits, error handling, idempotency, and data privacy. This fully informs the agent of behavioral traits.
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 lengthy with structured sections, but some parts (e.g., 'When to use' reads like a generic template) add redundancy. While well-organized, it could be more concise by removing generic statements and focusing on email-specific 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 no output schema, the description adequately explains return format and behavior. However, it omits details about pagination or handling large folders, and the missing api_key parameter explanation reduces completeness. Error handling and rate limits are covered well.
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 0%, so the description must explain parameters. The 'Args' section explains folder and limit (defaults and max), but does not mention the api_key parameter present in the schema. This omission leaves ambiguity about how authentication is handled via parameter vs environment variable.
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 that it reads recent emails from a mailbox folder and returns subject, from, date, and body preview. This distinguishes it from sibling tools like create_draft, list_folders, search_emails, and send_email.
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 includes 'When to use' and 'When NOT to use' sections, but the content is generic ('structured analysis or classification') and not specific to reading emails. It lacks explicit differentiation from siblings or clear guidance on when to use this tool versus search_emails or others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search emails in a folder. Supports these query formats:
Email address: searches FROM field
'subject:keyword': searches subject
'from:name': searches sender
'to:name': searches recipient
'unread' or 'unseen': unread messages only
'flagged' or 'starred': flagged messages
Any other text: full-text search
Args: query: Search query folder: IMAP folder to search (default: INBOX) limit: Max results (default: 10, max: 25)
Behavior: This tool is read-only and stateless ā it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results. Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent ā calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| folder | No | INBOX | |
| limit | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states read-only, stateless, idempotent behavior, authentication requirements, rate limits (free vs. pro), error handling, and data privacy. This provides comprehensive behavioral transparency.
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 structured with sections but is verbose and contains redundant information (Behavior and Behavioral Transparency sections overlap). The generic 'When to use' section could be removed. Concision is adequate but not optimal.
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 lack of output schema, the description should explain return structure. It covers error objects but not success output. It also doesn't mention how api_key is used for authentication. These gaps reduce completeness despite good coverage of query formats and behavior.
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 0%, so the description must compensate. It details query, folder (with default), and limit (with default and max), but misses the api_key parameter entirely. Query format explanation is thorough, but omission of api_key reduces score.
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 'Search emails in a folder' with specific and varied query formats, distinguishing it from sibling tools like create_draft, list_folders, read_inbox, and send_email.
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 'When to use' section is generic and unrelated to searching emails, and there is no guidance on when to use this tool versus alternatives like read_inbox or list_folders. The query format examples offer implicit usage context but no explicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an email via SMTP. Requires EMAIL_ADDRESS and EMAIL_PASSWORD env vars.
Safety: Set confirm=False to actually send. When confirm=True (default), returns a preview without sending so the user can verify before dispatch.
Args: to: Recipient email address (comma-separated for multiple) subject: Email subject line body: Email body (plain text or HTML) html: Set True if body is HTML cc: CC recipients (comma-separated) bcc: BCC recipients (comma-separated) confirm: If True, preview only (does not send). Set False to send.
Behavior: This tool is read-only and stateless ā it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results. Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent ā calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| subject | Yes | ||
| body | Yes | ||
| html | No | ||
| cc | No | ||
| bcc | No | ||
| confirm | No | ||
| api_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It claims the tool is 'read-only and stateless' and 'does not modify any external systems', which is false for an email-sending tool. This is a critical misrepresentation. Other details (rate limits, auth, error handling) are overshadowed by this contradiction.
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 overly long and includes irrelevant sections (classification use cases) that likely were copy-pasted. The relevant email-sending info is mixed with off-topic content. Not concise; structure is poor.
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?
Covers many aspects (safety, rate limits, auth, error handling) but the false read-only claim undermines credibility. Missing output schema. The confusing unrelated sections reduce completeness for the actual task.
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 0%, so description must compensate. It lists all 8 parameters with clear explanations: to/subject/body as plain text, html boolean, cc/bcc as comma-separated, confirm for preview vs send. The api_key parameter is mentioned in behavioral sections. Adds significant value beyond the bare 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 first sentence clearly states 'Send an email via SMTP.' However, subsequent contradictory statements (e.g., 'read-only and stateless') and irrelevant 'When to use' sections about classification frameworks confuse the core purpose.
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?
Includes explicit 'When to use' and 'When NOT to use' sections, but these are copied from an unrelated tool (classification analysis). No comparison to siblings like create_draft or search_emails. The safety note about confirm parameter is helpful but insufficient.
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. Dates show when Glama detected each change.
v1.0.0create_draftlist_foldersread_inboxsearch_emailssend_emailEach tool targets a distinct action: creating drafts, listing folders, reading inbox, searching emails, and sending emails. No functional overlap exists, and descriptions clearly differentiate their purposes despite boilerplate content.
All tool names follow a consistent verb_noun pattern using snake_case: create_draft, list_folders, read_inbox, search_emails, send_email. No mixing of styles or irregular naming.
Five tools is well-scoped for an email automation server. Each tool covers a core operation (draft, list, read, search, send) without redundancy or missing essentials for basic usage.
The tool set covers the primary email workflow: draft creation, folder discovery, inbox reading, search, and sending. However, common operations like deleting emails, marking as read/unread, or moving messages are absent, creating minor gaps.
Email infrastructure for AI agents ā send, receive, search, and reply to email over MCP.
AI-controlled email ops for campaigns, contacts, segments, analytics, and sending.
Sequenzy MCP server for AI-powered email marketing automation.
Email inboxes for AI agents: send, receive, reply, search, and manage threaded 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/CSOAI-ORG/email-automation-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
