Mail Notification MCP

by Guascoign

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation3/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.5/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Mail_MCP MCP server](https://glama.ai/mcp/servers/Guascoign/Mail_MCP/badges/card.svg)](https://glama.ai/mcp/servers/Guascoign/Mail_MCP)

Score Badge

Copy to your README.md:

[![Mail_MCP MCP server](https://glama.ai/mcp/servers/Guascoign/Mail_MCP/badges/score.svg)](https://glama.ai/mcp/servers/Guascoign/Mail_MCP)

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/Guascoign/Mail_MCP'

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