Allows sending progress updates, approval requests, and custom emails through Gmail's SMTP, and reading replies and checking approval status via Gmail's IMAP.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Mail Notification MCP Send a progress update that all tests passed and request approval to deploy to production"
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.
An MCP server that sends engineering progress and human approval emails via SMTP. It uses the standard stdio transport and is suitable for invocation by MCP clients such as Codex, Claude Desktop, Cursor, VS Code, and others.
send_progress_update: Send a project progress, completion, or blocked update report.
request_human_approval: Send an item requiring human approval or rejection, and generate an approval number.
send_simple_email: Send a plain-text or HTML email.
send_custom_email: Send a custom email with CC/BCC and attachments.
test_smtp_connection: Test SMTP connection and authentication.
test_imap_connection: Test IMAP connection and authentication.
read_replies: Read the latest replies in the inbox; by default they are not marked as read.
check_approval_status: Determine whether an approval number is "approved", "rejected", or "pending".
wait_for_approval: Poll and wait for a human reply until approved, rejected, or timeout.
The default recipient for the progress tool comes from config.json; approval emails explicitly ask for an "Approve" or "Reject" reply. Other engineering teams only need to call the MCP tools and do not need to implement SMTP themselves.
Related MCP server: mcp-email-server
Edit config.json in the project root (template: 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": "我的工程"
}
}It is recommended to put the password in an environment variable rather than writing it directly into the file:
$env:MAIL_SMTP_PASSWORD = "你的邮箱应用专用密码"You can also fill in smtp.password directly. config.json is ignored by .gitignore and should not be committed to the repository.
Common SMTP settings:
Mailbox | host | port | secure |
Gmail |
| 587 |
|
Outlook |
| 587 |
|
QQ mailbox |
| 587 |
|
163 mailbox |
| 465 |
|
Gmail, QQ Mail, etc. usually require SMTP to be enabled and an app-specific password to be used; when the regular web login password cannot be used directly, generate an authorization code/app password as required by the mailbox provider.
IMAP is used to read replies. QQ Mail typically uses imap.qq.com:993 with SSL; if imap.password is omitted, the program reuses the SMTP password/authorization code. Environment variables override config.json, and you can also use IMAP_HOST, IMAP_PORT, IMAP_SECURE, IMAP_USER, IMAP_PASS, and NOTIFY_TO.
Requires Python 3.11+ and uv. Run in PowerShell:
cd C:\AI_Tools\Mail
uv sync --extra dev
uv run pytest
uv run python -m email_mcp_server.serverThe stdio mode of MCP should not be typed into manually; it should be launched by an MCP client. We recommend first calling test_smtp_connection and test_imap_connection.
Using a client that supports the mcpServers format as an example, merge the following server entry into the client configuration. Windows paths must use double backslashes:
{
"mcpServers": {
"mail-notification": {
"command": "uv",
"args": [
"--directory",
"C:\\AI_Tools\\Mail",
"run",
"python",
"-m",
"email_mcp_server.server"
]
}
}
}If uv is not on the client's PATH, replace command with the absolute path of uv.exe. Restart the client after modifying the MCP configuration.
Progress report:
调用 send_progress_update：
project="订单系统"
status="进行中"
summary="已完成数据库迁移脚本，并通过本地测试"
details="迁移了 12 张表，新增回滚检查"
next_steps="部署到测试环境并等待接口联调"Human approval:
调用 request_human_approval：
project="订单系统"
title="是否允许部署到生产环境"
request="请批准今晚 22:00 执行生产部署"
reason="测试环境已通过，预计需要 15 分钟，期间会短暂重启服务"
options="批准部署 / 延后到明天"
deadline="今天 21:30 前"The tools support an optional to parameter as a one-time recipient override; when omitted, notification.to in config.json is used.
Read replies:
调用 read_replies：
from_address="target@example.com"
subject_contains="Mail Notification MCP 测试邮件"
since_hours=72Approval confirmation:
调用 check_approval_status：
approval_id="APR-ABC1234567"The approval tools return approved, rejected, pending, or timeout. By default, they only read the INBOX and do not automatically modify the read/unread state of messages.
Prefer app-specific passwords or authorization codes; do not use the primary mailbox password.
Do not commit real passwords or real target mailbox configuration to Git.
Local stdio is used by default; HTTP mode binds only to 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 inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Your agent needs a mailbox of its own — to receive, thread, draft and send, with attachments, without borrowing your personal inbox or your company's SMTP. **What you can ask for** • "Create an inbox for this agent and tell me its address." • "Read the new messages in this thread and draft a reply." • "Send this message with the attachment and wait for the response." • "Search this inbox for everything from that domain." • "Show delivery metrics and the events on this inbox." **How to use it** Point any MCP client at https://mcp.aisa.one/mail/mcp and sign in with OAuth — there is no key to create or paste. 49 tools: create and delete inboxes, list and read messages, raw message bodies, attachments, threads, drafts and draft attachments, send and reply, message search, inbox events, metrics, and list entries — reads and writes. **Why this rather than the source** A real inbox an agent owns, rather than an SMTP credential it borrows from a human. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the contact elsewhere in the catalogue, then write to them from here — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/sales/mcp finds the person to write to.
Send email with approval: hosted MCP for email, campaigns, contacts, domains.
