What can you do with this server?

The Mail MCP Tool server provides a standardized interface for AI models to interact with email services through the Model Context Protocol (MCP). With this server, you can: * Send Emails: Create and send simple text, HTML, and emails with attachments to single or multiple recipients * Receive & Search Emails: List, query, and search emails across folders with filters for sender, recipient, subject, date range, read status, and attachment presence * Manage Emails: Mark as read/unread, delete, and move emails between folders * Handle Attachments: Download and manage email attachments * Contact Management: Fetch and search contact lists * Mailbox Management: List and navigate mailbox folders * Wait for Replies: Monitor for replies to specific emails within a designated timeout period

Which integrations are available for this server?

Offers integration with Git for version control and distribution of the MCP mail tool codebase. Hosts the project repository, providing access to source code, documentation, and project management features. Provides access to Gmail email services, allowing for sending emails, reading messages, managing attachments, and organizing folders/labels. Utilizes Node.js as the runtime environment for the email operations, enabling server-side JavaScript execution for email processing tasks. Uses Python to create a bridge between the mail services and the MCP protocol, allowing AI to interact with email functionality. Uses TypeScript for type-safe development of the email processing functionality, providing better code organization and error prevention. Implements Zod for request validation and type checking of email operations, ensuring data integrity when processing emails.

How do I use Mail MCP Tool?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Mail MCP Tool show me the latest 5 emails in my inbox" 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.

Mail MCP Tool

by shuakami

Overview Schema Related Servers Score Discussions

TypeScript

Local

Mail MCP 工具

ISC License Node.js TypeScript Mail

English Version (README-EN.md)

这是什么

这是一个基于 MCP (Model Context Protocol) 的邮件工具，它能让 AI 模型通过标准化接口访问电子邮件服务。

简单来说，它让 AI 助手能够执行各种邮件操作，如发送邮件、阅读收件箱、处理附件等，无需用户手动输入复杂的API调用或切换到邮件客户端。

邮件发送：普通文本邮件、HTML邮件、带附件邮件、群发邮件
邮件接收与查询：获取文件夹列表、列出邮件、高级搜索、获取邮件详情
邮件管理：标记已读/未读、删除邮件、移动邮件
附件管理：查看附件列表、下载附件、查看附件内容
联系人管理：获取联系人列表、搜索联系人

以下是 Mail MCP 工具的一些核心特点：

高级搜索功能：支持多文件夹、关键词、日期范围、发件人、收件人等复杂条件搜索
智能联系人管理：自动从邮件历史中提取联系人信息，包括联系频率分析
内容范围控制：可以分段查看大型邮件，避免加载过多内容
多种邮件格式：支持纯文本和HTML格式邮件的发送和显示
附件处理能力：智能识别附件类型，支持文本、图片等不同类型的附件预览
安全可靠：本地处理所有邮件操作，不通过第三方服务器转发敏感信息

通过简单的自然语言指令，AI 可以帮助你完成上述所有操作，无需手动编写API调用或在邮件客户端中执行复杂操作。

Related MCP server: Email MCP Server

快速上手

0. 环境准备

安装 Node.js 和 npm
- 访问 Node.js 官网
- 下载并安装 LTS（长期支持）版本
- 安装时选择默认选项即可，安装包会同时安装 Node.js 和 npm
验证安装
- 安装完成后，打开命令提示符（CMD）或 PowerShell
- 输入以下命令确认安装成功：
  node --version npm --version
- 如果显示版本号，则表示安装成功
安装 Git（如果尚未安装）
- 访问 Git 官网
- 下载并安装 Git
- 安装时使用默认选项即可
安装 Python 3.11 或更高版本（必需）
- 访问 Python 官网
- 下载并安装 Python 3.11 或更高版本
- 重要：安装时必须勾选"Add Python to PATH"选项
- 安装完成后重启电脑，确保环境变量生效

Installing via Smithery

To install Mail MCP Tool for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @shuakami/mcp-mail --client claude

1. 克隆并安装

git clone https://github.com/shuakami/mcp-mail.git
cd mcp-mail
npm install
npm run build

2. 构建项目

npm run build

3. 添加到 Cursor MCP 配置

根据你的操作系统，按照以下步骤配置 MCP：

在 Cursor 中，打开或创建 MCP 配置文件：C:\\Users\\你的用户名\\.cursor\\mcp.json
- 注意：请将 你的用户名 替换为你的 Windows 用户名
添加或修改配置如下：

{
  "mcpServers": {
    "mail-mcp": {
      "command": "pythonw",
      "args": [
        "C:/Users/你的用户名/mcp-mail/bridging_mail_mcp.py"
      ],
      "env": {
        "SMTP_HOST": "smtp.qq.com",
        "SMTP_PORT": "465",
        "SMTP_SECURE": "true",
        "SMTP_USER": "your.email@qq.com",
        "SMTP_PASS": "your-app-specific-password",
        "IMAP_HOST": "imap.qq.com",
        "IMAP_PORT": "993",
        "IMAP_SECURE": "true",
        "IMAP_USER": "your.email@qq.com",
        "IMAP_PASS": "your-app-specific-password",
        "DEFAULT_FROM_NAME": "Your Name",
        "DEFAULT_FROM_EMAIL": "your.email@qq.com"
      }
    }
  }
}

⚠️ 请注意:
将 你的用户名 替换为你的 Windows 用户名
确保路径正确指向你克隆或解压的项目目录
路径应该反映你将项目文件放置的实际位置
不要删除克隆或解压的文件夹，这会导致 MCP 无法正常工作

在 Cursor 中，打开或创建 MCP 配置文件：/Users/你的用户名/.cursor/mcp.json
- 注意：请将 你的用户名 替换为你的 macOS 用户名
添加或修改配置如下：

{
  "mcpServers": {
    "mail-mcp": {
      "command": "pythonw",
      "args": [
        "/Users/你的用户名/mcp-mail/bridging_mail_mcp.py"
      ]
    }
  }
}

⚠️ 请注意:
将 你的用户名 替换为你的 macOS 用户名
确保路径正确指向你克隆或解压的项目目录
路径应该反映你将项目文件放置的实际位置
不要删除克隆或解压的文件夹，这会导致 MCP 无法正常工作

在 Cursor 中，打开或创建 MCP 配置文件：/home/你的用户名/.cursor/mcp.json
- 注意：请将 你的用户名 替换为你的 Linux 用户名
添加或修改配置如下：

{
  "mcpServers": {
    "mail-mcp": {
      "command": "pythonw",
      "args": [
        "/home/你的用户名/mcp-mail/bridging_mail_mcp.py"
      ]
    }
  }
}

⚠️ 请注意:
将 你的用户名 替换为你的 Linux 用户名
确保路径正确指向你克隆或解压的项目目录
路径应该反映你将项目文件放置的实际位置
不要删除克隆或解压的文件夹，这会导致 MCP 无法正常工作

4. 启动服务

配置好之后，重启 Cursor 编辑器，它会自动启动 MCP 服务。然后你就可以开始使用了。

你可以要求 AI 执行以下操作：

"列出我的邮箱文件夹"
"显示收件箱中的最新5封邮件"
"发送一封主题为'测试邮件'的邮件给example@example.com"
"搜索包含'发票'关键词的邮件"
"查看UID为1234的邮件详情"
"下载邮件中的附件"

工作原理

本工具基于 MCP (Model Context Protocol) 标准实现，作为 AI 模型与电子邮件服务之间的桥梁。它使用 nodemailer 和 node-imap 作为底层邮件客户端，并通过 Zod 进行请求验证和类型检查。

主要技术组件包括：

SMTP 客户端：负责所有邮件发送功能，支持HTML内容和附件
IMAP 客户端：负责连接邮箱服务器，获取邮件列表、详情和附件
邮件解析器：使用 mailparser 解析复杂的电子邮件格式
内容处理：智能处理HTML和纯文本内容，并支持分段加载大型邮件
联系人提取：从邮件历史中自动提取和整理联系人信息

每个邮件操作都被封装为标准化的 MCP 工具，接收结构化参数并返回格式化结果。所有数据都经过处理，以确保以人类可读的格式呈现，使 AI 模型能够轻松理解电子邮件的内容结构。

许可证

ISC

如果这个项目对你有帮助，欢迎给个 Star ⭐️ (｡♥‿♥｡)

Available Tools

17 tools

deleteEmailD

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`folder`	No		INBOX

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getAttachmentD

ParametersJSON Schema

Name	Required	Default
`uid`	Yes
`folder`	No	INBOX
`attachmentIndex`	Yes
`saveToFile`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getContactsD

ParametersJSON Schema

Name	Required	Description	Default
`maxResults`	No
`searchTerm`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

getEmailDetailD

ParametersJSON Schema

Name	Required	Default
`uid`	Yes
`folder`	No	INBOX
`contentRange`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

listEmailsD

ParametersJSON Schema

Name	Required	Default
`folder`	No	INBOX
`limit`	No
`readStatus`	No	all
`from`	No
`to`	No
`subject`	No
`fromDate`	No
`toDate`	No
`hasAttachments`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

listFoldersD

ParametersJSON Schema

Name	Required	Description	Default
`random_string`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

markAsReadD

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`folder`	No		INBOX

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

markAsUnreadD

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`folder`	No		INBOX

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

markMultipleAsReadD

ParametersJSON Schema

Name	Required	Description	Default
`uids`	Yes
`folder`	No		INBOX

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

markMultipleAsUnreadD

ParametersJSON Schema

Name	Required	Description	Default
`uids`	Yes
`folder`	No		INBOX

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

moveEmailD

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`sourceFolder`	Yes
`targetFolder`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchEmailsD

ParametersJSON Schema

Name	Required	Description	Default
`keywords`	No
`folders`	No
`startDate`	No
`endDate`	No
`from`	No
`to`	No
`subject`	No
`hasAttachment`	No
`maxResults`	No
`includeBody`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sendBulkMailD

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes
`cc`	No
`bcc`	No
`subject`	Yes
`text`	No
`html`	No
`attachments`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sendHtmlMailD

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes
`cc`	No
`bcc`	No
`subject`	Yes
`html`	Yes
`attachments`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sendMailD

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes
`cc`	No
`bcc`	No
`subject`	Yes
`text`	No
`html`	No
`useHtml`	No
`attachments`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sendSimpleMailD

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes
`subject`	Yes
`body`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

waitForReplyD

ParametersJSON Schema

Name	Required	Description	Default
`folder`	No		INBOX
`timeout`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.8/5.0

Disambiguation3/5

Most tools have distinct purposes targeting different email operations, but there's some overlap between sendMail, sendSimpleMail, sendHtmlMail, and sendBulkMail that could cause confusion about which to use for basic sending. The marking tools (markAsRead/markAsUnread vs markMultipleAsRead/markMultipleAsUnread) are clearly differentiated by single vs batch operations.

Naming Consistency4/5

The naming follows a consistent verb-first pattern with camelCase throughout (e.g., deleteEmail, getAttachment, listEmails). Minor deviation exists with 'waitForReply' which uses a different verb style, but overall the convention is predictable and readable.

Tool Count4/5

With 17 tools, the count is slightly high but reasonable for an email management server covering folders, emails, contacts, attachments, and sending operations. It's comprehensive without being overwhelmingly bloated, though some consolidation might improve efficiency.

Completeness4/5

The toolset covers core email workflows well, including listing, reading, sending, searching, organizing (move/delete), and status management (mark read/unread). Minor gaps include no update/delete for contacts or folders, and no tool for managing email drafts, but agents can work around these with the provided operations.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302
AgentMail
to.agentmail
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Email Communication
2
AgenticEmail A
dev.agenticemail
Hosted email for AI agents: create inboxes, send, receive, and reply over MCP with scoped API keys
Email Communication
2
Mermail
app.mermail
Privacy-first email inboxes for AI agents with MCP mail tools and Composio connect/execute.
Email App Automation Communication
2

Related MCP Servers

Email MCP Server
App Automation Developer Tools
TimeCyber
A
license
B
quality
D
maintenance
An MCP service that enables AI to fully manage email accounts, supporting sending emails with attachments and multiple recipients across various email providers.
Updated 2 months ago (2026-06-26 04:24 UTC)
7
577
73
MIT
Email MCP Server
Communication App Automation
tianpeijun
A
license
Not graded
quality
D
maintenance
Enables AI to send, read, search, delete and reply to emails through SMTP or Gmail API, supporting common email services like QQ, 163, Gmail and Outlook with HTML/text formats and attachments.
Updated 9 months ago (2025-11-25 10:44 UTC)
48
1
ISC
Email MCP Server
Email App Automation
chinmay4382
F
license
Not graded
quality
D
maintenance
An MCP server that enables AI models to read, search, and send emails via IMAP and SMTP protocols. It supports various providers like Gmail and Outlook, allowing for tasks such as retrieving unread messages, searching by sender, and managing mailbox folders.
Updated 5 months ago (2026-03-22 19:52 UTC)
Mail MCP Server
Email Communication
martinzarfl
A
license
B
quality
D
maintenance
Enables AI assistants to send, read, and manage emails via SMTP and IMAP, with support for attachments, threads, and mailbox organization.
Updated 9 months ago (2025-11-19 11:53 UTC)
16
42
1
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shuakami/mcp-mail'

If you have feedback or need assistance with the MCP directory API, please join our Discord server