MiniMail MCP Server

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation4/5
Most tools have distinct purposes (send, receive, configure, status, help), but mailing_list_latest overlaps slightly with check_inbox as a specialized variant. Descriptions help differentiate.
Naming Consistency3/5
Uses snake_case consistently, but mixes verb-first (check_inbox, list_services) with noun-first (email_help, email_status) patterns. Also 'mailing_' prefix vs 'email_' adds inconsistency.
Tool Count5/5
10 tools cover essential email operations plus extras (help, subject suggestions, mailing list presets) without being overwhelming.
Completeness3/5
Core send/receive and service management are covered, but lacks email deletion, folder movement, and attachment support, which are common email tasks.
Average 4.3/5 across 10 of 10 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 44 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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?
Discloses use of host LLM sampling and optional Anthropic fallback, which is behavioral info. However, it omits what the tool returns (plan vs. execution) and side effects, given no annotations.
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?
Two sentences, front-loaded with main purpose. No wasted words, but could be slightly more informative without lengthening.
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?
Lacks essential details: output format (despite output schema existence), prerequisites, and clarification that it only plans, not executes. Given complexity of LLM-assisted planning, coverage is insufficient.
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?
Input schema has one 'goal' parameter with 0% description coverage. The description implies goal is the workflow objective, but provides no format guidance or examples, requiring compensation.
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?
Description states it plans a multi-step email workflow using sampling, which is a specific verb+resource. It distinguishes from siblings like send_email or check_inbox, but could be more explicit about what constitutes a workflow.
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 clear guidance on when to use this tool versus alternatives like send_email or suggest_email_subject. The description only explains technical behavior (sampling/fallback), not usage context.
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 provided, the description must disclose behavioral traits. It mentions that the tool uses MCP sampling when available, which is a key behavior. However, it does not state what happens when sampling is unavailable, nor does it clarify if the tool is read-only or has any side effects. The description is adequate but lacks full transparency.
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 a single, efficient sentence with 14 words. It is front-loaded with the core action and concisely adds the sampling behavior. Every word contributes meaning without redundancy.
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 tool's low complexity (one parameter, output schema exists), the description covers the key aspects: it suggests 1-3 subject lines and mentions sampling. The existence of an output schema reduces the need to describe return values. However, it could be improved by clarifying the expected input format (e.g., full email body).
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 input schema has 0% description coverage, meaning the parameter 'body' is not described. The description says 'for the given body' but does not explain what constitutes a valid body (e.g., email content, plain text, length limits). This is insufficient compensation for the missing param descriptions.
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 the tool's purpose: to suggest 1–3 concise email subject lines for a given body. The verb 'suggest' and resource 'email subject lines' are specific, and it distinguishes itself from sibling tools like 'send_email' or 'check_inbox' by focusing on subject line generation.
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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or when not to use it. For example, it doesn't clarify if the tool is intended for drafting new emails or improving existing ones, nor does it compare with other email-related 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?
With no annotations, the description carries full burden. It explains that it loads from EMAIL_MCP_MAILING_LISTS and allows overrides, but does not disclose whether the operation is read-only or has side effects (e.g., marking messages as read). The return shape is mentioned but not detailed.
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 well-structured with a title line, usage context, explicit Args section, and Returns note. It is concise, front-loaded with purpose, and every sentence adds value without redundancy.
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?
The description covers purpose, parameters, and return shape (referencing check_inbox). However, it omits error conditions, prerequisites beyond the catalog, and behavior when limit/unread_only are null. The existence of an output schema reduces the burden, but some gaps remain.
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?
Despite 0% schema coverage, the description's Args section fully explains each parameter: list_id (preset id from catalog), limit (override max messages with default), and unread_only (override UNSEEN-only). This adds significant meaning beyond the schema's type-only definitions.
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 the tool's purpose: 'Fetch newest messages for a preset id', which is specific and distinct from sibling tools like check_inbox and mailing_lists_catalog. The verb 'Fetch' and resource 'newest messages' are precise.
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 provides context on typical use (newsletter drops in a dedicated IMAP folder) and references the catalog for preset ids, but does not explicitly state when not to use this tool versus alternatives like check_inbox. No exclusion criteria or alternative tools are mentioned.
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?
No annotations are provided, so the description carries the full burden. It describes the return structure and includes examples and notes, which gives good behavioral insight. However, it doesn't explicitly state that the tool is read-only or safe, which would be helpful.
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 well-organized: starts with purpose, then detailed return schema, examples, and notes. Every sentence adds value, and it is front-loaded with the core function.
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?
Given no parameters and an output schema provided in the description, the tool is fully explained. The description covers what it returns and provides usage context, making it complete for an agent.
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 tool has zero parameters, so the baseline is 4. The description adds meaning by detailing the output structure, which goes beyond the empty input schema.
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 the verb ('Get help and usage information') and specific resource ('email MCP tools and services'). It distinguishes from sibling tools like list_services and email_status by noting they have different purposes.
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?
It provides context on when to use this tool (to get help) and mentions related tools (list_services, email_status, configure_service) for other tasks. However, it does not explicitly state when not to use it.
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?
With no annotations, the description carries the full burden. It discloses that configuration is stored in memory (not persisted) and becomes available immediately. It also notes service name uniqueness. Missing details on error handling if name duplicates or if type is invalid, but overall good transparency.
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 clear sections (Args, Returns, Examples, Notes). It is front-loaded with the purpose. While slightly lengthy due to examples, the structure and clarity justify the length.
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 tool's complexity (4 params, nested objects, output schema), the description covers parameters, return format, examples, and important notes. It mentions the output schema structure. Missing validation details for 'type' values (e.g., accepted strings) but examples cover common ones.
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?
The input schema has 0% description coverage. The description provides detailed parameter explanations in Args (name, type, config, enabled) and includes comprehensive examples. This adds substantial meaning beyond the schema.
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 'Configure a new email service dynamically.' with a specific verb and resource. It distinguishes from sibling tools like list_services, send_email, etc., by focusing on service configuration rather than usage.
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 explains when to use the tool (to add a new email service) and provides notes on uniqueness and persistence. It references list_services() to see available services, implicitly suggesting when not to add a duplicate. However, it lacks explicit alternatives for modifying existing services.
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?
Despite no annotations, the description fully explains the return format, sorting order (most recent first), and limitations (e.g., non-supporting services). It does not cover authentication or rate limits, but given the tool's simplicity, the disclosure is substantial.
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 somewhat lengthy but well-structured with clear sections (Args, Returns, Examples, Notes). The opening sentence is direct, and each component serves a purpose. Minor redundancy could be trimmed, but overall it's efficient.
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?
Given the presence of an output schema (described in detail), 6 parameters, and zero annotations, the description completely covers usage, behavior, and return values. Examples and notes further enrich completeness, leaving no critical gaps for agent invocation.
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?
All 6 parameters are thoroughly described with valid options, defaults, and behavior (e.g., case-insensitive filters for from_contains). Since schema description coverage is 0%, the description carries the full burden and excels, adding meaning far beyond the bare schema types.
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 tool description explicitly states 'Check inbox via specified email service' and details the retrieval of emails from a service and folder. It distinguishes itself from sibling tools like send_email and email_help by focusing solely on reading emails, with no overlap in functionality.
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 provides clear parameter options (services, folders) with defaults and examples. It notes that not all services support inbox checking, offering guidance on when the tool may not be applicable. However, it does not explicitly compare with alternatives like email_status or suggest_email_subject.
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?
The description discloses the behavior: it reads from a JSON configuration, lists presets, and returns specific fields or an error if unset/invalid. Since no annotations are provided, the description carries full burden, and it adequately explains the return structure and error conditions.
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 concise, with each sentence adding value. It front-loads the purpose, then gives usage context, then outlines the return format. No redundant information.
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?
Given no parameters and no annotations, the description is complete. It explains what the tool returns, how to use it (with reference to sibling tool), and potential errors. It fits well within the context of sibling tools.
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 tool has zero parameters, and the input schema is an empty object. The description adds value by explaining the return fields and possible error, which is sufficient given no parameters need 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 description clearly states the tool's purpose: 'List named mailing-list presets from EMAIL_MCP_MAILING_LISTS (JSON).' It uses a specific verb ('List') and resource ('mailing-list presets'), and distinguishes itself from the sibling tool 'mailing_list_latest' by mentioning it returns configuration that can be used with that tool.
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 provides guidance on when to use this tool: 'Configure labels/folders once ... then use mailing_list_latest(id).' This implies the catalog should be used first to list presets before using the latest tool. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: supports multiple services, automatic detection, multipart emails, return format with success/error, and notes on service limitations. No contradictions.
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 Args, Returns, Examples, and Notes sections. It front-loads the main purpose and is appropriately detailed for a complex tool, though slightly verbose. Every sentence serves a purpose.
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?
Given 7 parameters, 3 required, no annotations, and an output schema, the description covers all aspects: parameter details, return format, examples, and notes. It fully equips an agent to use the tool correctly.
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?
The description adds extensive meaning beyond the schema's type/required fields: formats for email addresses, service options, HTML usage, and default values. It compensates for 0% schema description coverage with detailed parameter documentation.
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 'Send an email via specified email service' and lists supported services. It distinguishes from sibling tools like check_inbox, configure_service, etc., by focusing on sending emails with various backends.
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 provides detailed usage guidance with parameter formats, service options, and examples. It implicitly tells when to use different services (e.g., webhooks for chat). However, it lacks explicit 'when not to use' or alternatives for sibling tools, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals that the tool tests actual connectivity, mentions timeout of 5-10 seconds, and states that API keys/passwords are not exposed. This provides complete transparency for a read-only diagnostic tool.
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 well-structured with clear sections: overall description, Args, Returns, Examples, Notes. Every sentence adds value, and the length is appropriate for the tool's complexity.
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?
The description is fully complete given the presence of an output schema. It includes the return structure, notes on behavior, and usage examples. No gaps remain for the agent to infer.
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?
Despite 0% schema description coverage, the description thoroughly explains the single 'service' parameter: 'Specific service to test, or None for all services,' with examples. This adds significant meaning beyond the schema's type definition.
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 'Get email service status and test connectivity,' using specific verbs and resources. It distinguishes itself from sibling tools like check_inbox and list_services by emphasizing actual connectivity testing.
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 provides explicit usage guidance via Args and Examples, showing how to check all services or a specific service. It notes that it tests actual connectivity, not just configuration presence, which helps differentiate from list_services. However, it does not explicitly state when not to use or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: it details the return structure, includes examples, and explains that the tool shows both automatically configured and manually added services and that configuration status indicates credential availability.
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 sections but is somewhat lengthy due to detailed output schema and examples. It is clear and front-loaded, but could be slightly more concise.
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?
The description is complete: it explains the tool's purpose, behavior, output format, and relationship to siblings. With zero parameters and no missing context, it fully covers what an agent needs to know.
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?
There are no parameters; the schema coverage is 100% and the description does not need to add parameter semantics. Baseline of 4 is appropriate for zero parameters.
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 'List all configured email services' with a specific verb and resource. It clearly differentiates from the sibling tool email_status by noting that email_status tests actual connectivity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives, including 'Use email_status() to test actual connectivity.' It also notes what the tool shows and omits.
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:

[![email-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/email-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sandraschi/email-mcp)

Score Badge

Copy to your README.md:

[![email-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/email-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sandraschi/email-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/sandraschi/email-mcp'

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