SMTP を介してプロジェクトの進捗状況や人による承認のメールを送信する MCP Server です。標準の stdio transport を使用しており、Codex、Claude Desktop、Cursor、VS Code などの MCP クライアントから呼び出すのに適しています。
send_progress_update：プロジェクトの進捗・完了・ブロック状況の報告を送信します。
request_human_approval：人による承認/拒否が必要な事項を送信し、承認番号を生成します。
send_simple_email：通常のプレーンテキストまたは HTML メールを送信します。
send_custom_email：CC/BCC と添付ファイル付きのカスタムメールを送信します。
test_smtp_connection：SMTP 接続と認証をテストします。
test_imap_connection：IMAP 接続と認証をテストします。
read_replies：受信トレイの最新の返信を読み取ります。デフォルトでは既読にしません。
check_approval_status：承認番号に基づいて「承認」「拒否」「処理待ち」を判別します。
wait_for_approval：承認、拒否、またはタイムアウトまで、人からの返信をポーリングして待機します。
進捗ツールのデフォルトの受信者は config.json から取得されます。承認メールでは「承認」または「拒否」の返信を明示的に求めます。他のプロジェクトはSMTPを自分で実装する必要はなく、MCPツールを呼び出すだけで済みます。
Related MCP server: mcp-email-server
プロジェクトルートの config.json を編集します（テンプレートは config.example.json）：
{
"smtp": {
"host": "smtp.gmail.com",
"port": 587,
"secure": false,
"username": "你的发件邮箱@gmail.com",
"password": "",
"password_env": "MAIL_SMTP_PASSWORD",
"from_email": "你的发件邮箱@gmail.com"
},
"imap": {
"host": "imap.gmail.com",
"port": 993,
"secure": true,
"username": "你的发件邮箱@gmail.com",
"password": "",
"password_env": "MAIL_SMTP_PASSWORD"
},
"notification": {
"to": "目标收件邮箱@example.com",
"subject_prefix": "[工程通知]",
"project_name": "我的工程"
}
}パスワードはファイルに直接書き込むのではなく、環境変数に入れることをお勧めします：
$env:MAIL_SMTP_PASSWORD = "你的邮箱应用专用密码"い また smtp.password を直接記入することもできます。config.json は .gitignore で無視されるため、リポジトリにコミットしないでください。
一般的な SMTP 設定：
メールサービス | host | port | secure |
Gmail |
| 587 |
|
Outlook |
| 587 |
|
QQ 邮箱 |
| 587 |
|
163 邮箱 |
| 465 |
|
Gmail、QQ などでは通常、SMTP を有効にし、アプリ専用パスワードを使用する必要があります。Web ログイン用パスワードを直接使用できない場合は、メールサービスの要件に従って認証コード/アプリパスワードを生成してください。
IMAP は返信の読み取りに使用します。QQ 邮箱は通常 imap.qq.com:993 + SSL を使用します。imap.password を省略すると、SMTP のパスワード/認証コードを再利用します。環境変数は config.json を上書きします。IMAP_HOST、IMAP_PORT、IMAP_SECURE、IMAP_USER、IMAP_PASS、NOTIFY_TO も使用できます。
Python 3.11+ と uv が必要です。PowerShell で次を実行します：
cd C:\AI_Tools\Mail
uv sync --extra dev
uv run pytest
uv run python -m email_mcp_server.serverMCP の stdio モードでは、通常の文字を手動で入力しないでください。MCP クライアントから起動します。まず test_smtp_connection と test_imap_connection を呼び出すことをお勧めします。
mcpServers 形式に対応したクライアントを例として、以下のサーバー項目をクライアント設定に統合します。Windows のパスは二重バックスラッシュを使用する必要があります：
{
"mcpServers": {
"mail-notification": {
"command": "uv",
"args": [
"--directory",
"C:\\AI_Tools\\Mail",
"run",
"python",
"-m",
"email_mcp_server.server"
]
}
}
}uv がクライアントの PATH にない場合は、command を uv.exe の絶対パスに置き換えてください。MCP 設定を変更した後、クライアントを再起動します。
進捗報告：
调用 send_progress_update：
project="订单系统"
status="进行中"
summary="已完成数据库迁移脚本，并通过本地测试"
details="迁移了 12 张表，新增回滚检查"
next_steps="部署到测试环境并等待接口联调"人による承認：
调用 request_human_approval：
project="订单系统"
title="是否允许部署到生产环境"
request="请批准今晚 22:00 执行生产部署"
reason="测试环境已通过，预计需要 15 分钟，期间会短暂重启服务"
options="批准部署 / 延后到明天"
deadline="今天 21:30 前"ツールは任意の to パラメータをサポートし、一度だけ受信者を上書きできます。省略時は config.json の notification.to が使用されます。
返信の読み取り：
调用 read_replies：
from_address="target@example.com"
subject_contains="Mail Notification MCP 测试邮件"
since_hours=72承認の確認：
调用 check_approval_status：
approval_id="APR-ABC1234567"承認ツールが返すステータスは approved、rejected、pending、または timeout です。デフォルトでは INBOX のみを読み取り、メールの既読状態を自動的に変更しません。
メインのメールパスワードではなく、アプリ専用パスワードまたは認証コードを優先してください。
実際のパスワードや実際の送信先メール設定を Git にコミットしないでください。
デフォルトはローカルの stdio です。HTTP モードは 127.0.0.1 のみにバインドします。
Find an approval reply and classify it as approved, rejected, or pending.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| approval_id | Yes | ||
| since_hours | No | ||
| from_address | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral burden. It does disclose the main outcome (classification into three states) and implies a read-only 'find' operation, but it ignores what happens when no reply is found, when several replies match, or whether the tool mutates anything. No annotations, so a 3 is fair: core behavior shown, edge cases invisible.
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?
A single sentence, front-loaded with the verb, with no filler content. The conciseness is a strength, though the sentence is so short it fails to share the additional context this four-parameter tool demands.
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?
An output schema exists, so return-value documentation is not needed here. What's missing is the operational context: the meaning of the default window (since_hours=720), the source being searched, and how this interplays with read_approval workflow siblings. The description is minimally viable but not complete enough for confident use in a novel scenario.
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%, and the description only loosely grounds 'approval_id' as the handle to the approval reply. 'limit', 'since_hours', and 'from_address' are left completely unexplained, leaving an agent blind to the filtering and time-window semantics that these parameters clearly imply.
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 states a specific verb and resource ('find' the 'approval reply' and 'classify' it) with a concrete output taxonomy (approved/rejected/pending). It implicitly differentiates from siblings like read_all_messages (generic reads) and wait_for_approval (blocking behavior), but it never names this differentiation, so the agent must infer it from sibling names.
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 gives no 'when to use' or 'when not to use' guidance. There is no mention that this is the non-blocking status look-up, that wait_for_approval is the blocking alternative, or that read_replies is for broader reads. Given the semantically adjacent siblings, an agent is left guessing which tool matches the current intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read recent reply emails from IMAP.
Messages are read with BODY.PEEK and remain unread by default. Use
``from_address`` or ``subject_contains`` to narrow the result.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| mailbox | No | INBOX | |
| mark_read | No | ||
| since_hours | No | ||
| unread_only | No | ||
| from_address | No | ||
| body_contains | No | ||
| subject_contains | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral detail beyond the name: messages are read with BODY.PEEK and remain unread by default, which is useful safety-relevant context given there are no annotations. It does not say what happens when mark_read is true, how the structure 'reply' emails, or mention authentication or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main function, a key behavioral note, and a filter hint are communicated in three short sentences. Nothing is repeated from the schema, and there is no filler.
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 8 optional parameters and no annotations, the description is not fully self-contained. It omits operational details such as what a 'reply' is, how time-based filtering works besides the concept, and the meaning of selecting mark_read or unread_only. The output schema helps describe the return shape, but selection criteria and behavioral flags remain underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage for the 8 parameters, so the description carries the offset (the below-the-bar context, the bulk of the duty). It adds meaning for from_address and subject_contains, but leaves several meaningful parameters—limit, mailbox, since_hours, unread_only, mark_read, and body_contains—without any prose explanation.
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 names a concrete action (read), a specific resource (recent reply emails), and a source (IMAP). This is enough to distinguish the tool from the send-oriented and connection-test siblings without opening the schema.
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 clearly implies the tool is for fetching recent replies from an IMAP mailbox and gives concrete narrowing advice with from_address and subject_contains. However, it does not explicitly state when not to use this tool or contrast it with alternatives such as test_imap_connection for connectivity checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Email a human approval request with a traceable approval ID.
The recipient defaults to ``notification.to`` in config.json. The
email asks the recipient to reply with “批准” or “拒绝”.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| title | Yes | ||
| reason | No | ||
| options | No | ||
| project | Yes | ||
| request | Yes | ||
| deadline | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the burden, and it does disclose a side-effectful email send, the config-driven default recipient, and the approval-response mechanism. What it lacks is detail about tracking behavior, retry/idempotency, or approval lifecycle. It is informative but not comprehensive.
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 action. It contains no wasted words, though the formatting has a minor trailing-space artifact and it over-lacks parameter detail. Structurally it is efficient and easy to parse.
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 seven parameters, no annotations, and limited schema descriptions, the description only provides a high-level workflow. Important operational details about expected fields, project identity, deadline format, and option semantics are missing. An agent could select the right tool, but would likely struggle to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only meaningfully explains the recipient default and the approval-response request. Core parameters such as project, request, reason, options, and deadline have no described semantics, leaving the agent unable to fill required arguments confidently.
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 verb and resource: email a human approval request with a traceable approval ID. It also explains the expected recipient behavior (reply with 批准 or 拒绝), which makes the tool's unique role unambiguous. This distinguishes it from general email tools and status-checking siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the core context: use this when a human must approve something and the reply will be 批准 or 拒绝. However, it does not explicitly contrast it with sibling tools like check_approval_status, wait_for_approval, or the generic email senders, so an agent must infer when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a custom email with full configuration options.
Args:
email: Email message details including:
- to: Recipient email address(es) (string or list)
- cc: CC email address(es) (optional, string or list)
- bcc: BCC email address(es) (optional, string or list)
- subject: Email subject
- text: Plain text email body (optional)
- html: HTML email body (optional)
- attachments: List of attachments (optional), each with:
- path: Local file path to attach (preferred)
- content: Base64-encoded file content (alternative to path)
- filename: Override filename (auto-derived from path if omitted)
- mime_type: MIME type override (optional)
smtp_config: Optional SMTP configuration override with:
- host: SMTP server hostname
- port: SMTP server port
- secure: Use SSL/TLS
- username: Auth username
- password: Auth password
- from_email: Sender email address
Returns:
Success message or error message
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| smtp_config | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral disclosure burden. It goes beyond the bare action by enumerating SMTP authentication fields, optional configuration, and the return outcome of 'Success message or error message'. It does not mention side effects like irreversible sending or failure conditions in detail, but it does describe core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every part is necessary for a tool with two nested objects and many optional fields. The one-line summary is front-loaded and the rest is a structured parameter breakdown with no filler. The format is scan-friendly for an agent.
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 this complexity, the description provides a complete operational picture: what the email object can contain, what the SMTP override accepts, and what return behavior to expect. It compensates for the uninformative schema and the absence of annotations effectively.
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% and both parameters are free-form additionalProperties objects, so the description is essential. It fully compensates by explaining all expected email fields, attachment subfields, and every smtp_config field, while clarifying which options are optional and where defaults apply.
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 states a specific action ('Send a custom email') and a resource/scope ('with full configuration options'). This makes the tool distinct from the simpler sibling send_simple_email, but it does not explicitly draw the contrast or name alternatives in the description text.
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 strongly implies use when full configuration is needed (cc, bcc, attachments, HTML body, SMTP override) but it does not state 'use this instead of send_simple_email when...' or mention any exclusion criteria. Usage guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a standardized work-progress notification.
The recipient defaults to ``notification.to`` in config.json. Use
``to`` only when a one-off recipient override is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| status | Yes | ||
| details | No | ||
| project | Yes | ||
| summary | Yes | ||
| next_steps | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavior not visible in the schema: the recipient defaults to config.json's notification.to, with 'to' acting as an override. With no annotations provided, the description carries the behavioral burden, but it does not mention side effects like whether this sends an email or records a status somewhere, or whether it is a blocking call. Still, the default-recipient behavior is a meaningful disclosure 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 sentences with a brief context block, no filler or repetition. It front-loads the core purpose and adds a practical usage detail. Slightly more spacing in the source than needed, but all content 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?
The tool is a notification-sending operation with six parameters but no annotations and an output schema that likely just confirms delivery. The description covers the recipient override semantics, which is the trickiest part, but does not explain what 'standardized' means, what status values are expected, or how it relates to the sibling email tools. Adequate but a bit more context would improve.
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 compensate. It adds real semantics for the 'to' parameter (config default with override option), but the remaining five parameters (project, status, summary, details, next_steps) receive no additional meaning beyond their names and types. The description partially compensates but does not fully cover the gap.
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 states a specific verb ('send') and resource ('standardized work-progress notification'), which clearly conveys the tool's function. It is distinguishable from email-sending siblings by its 'standardized' framing, though it does not explicitly contrast with them.
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 explains when to use the 'to' parameter (only for one-off overrides) versus the default recipient from config.json, which is useful usage guidance. However, it does not provide any guidance on when to choose this tool over the sibling send_simple_email or send_custom_email tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a simple email.
Args:
to: Recipient email address
subject: Email subject
body: Email body content
is_html: Whether body is HTML (default: False)
smtp_config: Optional SMTP configuration override with:
- host: SMTP server hostname
- port: SMTP server port
- secure: Use SSL/TLS
- username: Auth username
- password: Auth password
- from_email: Sender email address
Falls back to environment variables if not provided.
Returns:
Success message or error message
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| body | Yes | ||
| is_html | No | ||
| subject | Yes | ||
| smtp_config | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that SMTP configuration falls back to environment variables if not provided, which is useful context. It also states the return type as a success or error message. Since no annotations are provided, the description carries the full burden, and while it covers the basic behavior, it does not disclose potential side effects, exclusions, or edge cases.
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 well-structured with an initial one-line summary, an Args section mapping to parameters, and a Returns section. It is not overly verbose, though repeating the parameter names largely duplicates the schema. The smtp_config details are dense but relevant, and each part serves a purpose.
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 presence of an output schema and the number of parameters, the description covers the key aspects: what the tool does, the required parameters, the optional smtp_config, and the fallback behavior. It is complete enough for an agent to understand how to invoke the tool correctly, though it leaves room for more detail on error conditions and rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the parameter descriptions in the docstring add crucial value, especially for smtp_config, which is only typed as an arbitrary object in the schema. The description explains each expected sub-field of smtp_config and the fallback behavior of environment variables. However, the descriptions for to, subject, and body add little beyond their 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 description clearly states the operation: 'Send a simple email.' The verb 'send' and resource 'simple email' are explicit, and the name is distinct from the sibling send_custom_email by the modifier 'simple', which implies it's for basic emails. However, it does not explicitly contrast itself with send_custom_email, so the differentiation is implicit.
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 gives no explicit guidance on when to use this tool versus alternatives such as send_custom_email or test_smtp_connection. It does mention the optional smtp_config override and fallback to environment variables, but this is parameter context rather than usage-selection guidance. The sibling tools are not mentioned or compared at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test IMAP connection and authentication without reading messages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries that burden. It discloses the possibly surprising intent to not read messages, which establishes a safe, non-destructive behavior. It doesn't explicitly describe failure modes or what the output contains, but for a zero-parameter test operation the main behavioral concern is adequately covered.
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?
A single, front-loaded sentence communicates the action, the protocol, and a critical non-behavior without any filler. Every word 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 zero-parameter diagnostic tool with an output schema, this description contains everything an agent needs to select and invoke it correctly. Connection/auth checking plus the explicit 'does not read messages' caveat together provide a complete mental model.
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?
With zero parameters, the schema is vacuously complete and there is no parameter meaning to add. The description still contributes useful context about testing the configured IMAP account/auth, meeting the baseline for a no-parameter tool.
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 states a specific verb ('test') with a resource ('IMAP connection and authentication') and a key boundary ('without reading messages'). This clearly distinguishes it from read_replies and sending tools, while the protocol name makes it distinguishable from test_smtp_connection.
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 clearly implies this tool is for verifying IMAP connectivity/authentication before actually reading messages or sending email. It draws a boundary with 'without reading messages' but does not explicitly name test_smtp_connection as the alternative for SMTP checks or provide a broader when-to-use/when-not-to-use rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test SMTP connection.
Args:
smtp_config: Optional SMTP configuration override with:
- host: SMTP server hostname
- port: SMTP server port
- secure: Use SSL/TLS
- username: Auth username
- password: Auth password
- from_email: Sender email address
Falls back to environment variables if not provided.
Returns:
Connection test result or error message
| Name | Required | Description | Default |
|---|---|---|---|
| smtp_config | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior on its own. It indicates the tool tests a connection and returns success or an error message, but it omits whether the test is read-only, whether it sends a test email, what happens on network timeouts, or which environment variables are read. This uncertainty could lead an agent to call the tool with incorrect assumptions 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 well-structured with a one-sentence summary followed by a labeled Args section and a Returns line. The bulleted fields are compact and each serves a purpose. It is slightly verbose due to the docstring style but remains easy to scan.
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 connection diagnostic with one optional parameter, the description covers the main input shape and general return kind. It lacks explicit success criteria, side-effect disclosure, and any reference to sibling tools, which would improve agent decision-making. Overall it is sufficient for basic use but not fully complete.
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?
Since schema coverage is 0%, the description fully compensates by documenting the smtp_config fields (host, port, secure, username, password, from_email) and stating the override behavior, including fallback to environment variables. This is actionable for an agent populating the argument. It does not provide data types or exact environment variable names, a modest gap.
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 starts with the specific verb phrase 'Test SMTP connection', which clearly identifies the target resource and distinguishes it from sibling testing tools. It goes beyond the name by describing the optional configuration override and the return type. However, it stops short of explaining what the connection test actually does (e.g., authenticates, sends a probe email, or just checks readability).
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?
There is no guidance on when this tool should be chosen over alternatives such as test_imap_connection or the sending tools. The description advises that smtp_config is optional and falls back to environment variables, but it does not indicate scenarios for using a config override versus relying on defaults. An agent must infer usage context entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll IMAP until an approval is approved, rejected, or times out.
| Name | Required | Description | Default |
|---|---|---|---|
| approval_id | Yes | ||
| from_address | No | ||
| timeout_seconds | No | ||
| poll_interval_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does disclose a core behavior beyond the name: it polls IMAP and blocks until the approval is approved, rejected, or times out. However, with no annotations provided the description carries the full burden, and it omits what happens on timeout (result vs. error), the read side effects of polling, and connectivity failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler. The verb 'Poll' is front-loaded, and both the mechanism and the terminal states are stated in the fewest words possible.
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?
An output schema exists, so return values are covered elsewhere. However, the description does not situate this tool in the approval flow: it never says that an approval must already exist (see request_human_approval), how from_address narrows the search, or what a timeout means for the agent. Given 4 required-ish parameters and 8 siblings, more context is needed.
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 compensate, but it does not explain approval_id or mention from_address, timeout_seconds, or poll_interval_seconds at all. The schema defaults (300s, 15s) hint at timing semantics, but the meaning and impact of from_address remain undocumented.
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 names a specific verb (Poll), a resource (IMAP, approval), and explicit termination conditions (approved, rejected, or times out). The blocking 'until ... times out' phrasing clearly distinguishes it from the one-shot sibling check_approval_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given as to when to use this tool versus alternatives. It does not mention check_approval_status as the lightweight one-shot option, does not note that this call blocks, and does not say whether a prior request_human_approval call is required.
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.
v2.0.0check_approval_statusread_repliesrequest_human_approvalsend_custom_emailsend_progress_updatesend_simple_emailtest_imap_connectiontest_smtp_connectionwait_for_approvalScored across 9 tools
There is meaningful overlap between send_simple_email and send_custom_email, both centered on sending mail, and between read_replies, check_approval_status, and wait_for_approval, all of which interact with incoming IMAP replies. The descriptions help separate them, but an agent could still mis-select when trying to perform a generic send or read action.
Most tool names follow a clear verb_noun snake_case pattern, such as test_imap_connection, send_custom_email, and check_approval_status. Minor deviations like wait_for_approval and the generic read_replies keep it from being perfectly uniform, but the naming is still predictable and readable.
With 9 tools, the set is well-scoped for a Mail Notification MCP covering connection testing, email sending, reply reading, and approval handling. Each tool contributes to the server's core purpose without obvious bloat.
The approval workflow is well covered: send a request, read/classify the reply, and wait for a result. Generic mailbox operations like listing folders or fetching arbitrary messages are absent, but those are not central to the stated notification and approval purpose.
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email for AI agents: send, receive with a safety verdict, reply and approve, as MCP tools.
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Hosted email MCP for your own Gmail, Outlook.com, Microsoft 365, iCloud or IMAP inbox: read, search, draft, reply in thread, forward and file mail. It moves or flags up to 500 messages in one call, and a send leaves exactly one copy in Sent. A calendar is a separate connection, and connecting one adds diary and scheduling tools.
