mailX tools

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct purpose focused on specific email-related DNS checks, server testing, or configuration lookups. For example, dkim_check and spf_check target different authentication mechanisms, while imap_check and smtp_check test different server types, ensuring clear boundaries and no overlap.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case, such as bimi_check, dmarc_generate, and smtp_finder. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for the comprehensive email diagnostics and configuration domain. It covers various aspects like DNS records, server checks, and lookups, though it might feel a bit heavy compared to more streamlined servers.
Completeness5/5
The tool set provides complete coverage for email infrastructure, including DNS-based authentication (SPF, DKIM, DMARC, BIMI), server testing (SMTP, IMAP), and lookup utilities (MX, CNAME, TXT). There are no obvious gaps, allowing agents to handle full email configuration and troubleshooting workflows.
Average 4/5 across 17 of 17 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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.
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?
Annotations cover key behavioral traits: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, repeatable, and flexible read operation. The description adds context by explaining DKIM's purpose, but doesn't disclose additional behaviors like rate limits, error handling, or output format. With annotations providing a solid foundation, the description offers modest value beyond them, warranting an average score.
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 well-structured in two sentences: the first states the tool's purpose, and the second provides background on DKIM. Every sentence adds value, with no wasted words. However, it could be slightly more front-loaded by integrating the DKIM explanation more seamlessly, but it remains efficient overall.
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?
Given the tool's low complexity (2 parameters, no output schema) and rich annotations, the description is minimally complete. It covers the basic purpose and context but lacks details on output (e.g., what 'valid' means, return format) and usage guidelines. With annotations handling safety and idempotency, the description is adequate but has clear gaps in guiding the agent effectively.
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 100%, with clear descriptions for both parameters ('domain_name' and 'dkim_selector'), including examples. The description doesn't add any semantic details beyond the schema, such as explaining selector conventions or domain validation rules. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to.
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 tool's purpose: 'Check if a domain has a valid DKIM (DomainKeys Identified Mail) DNS record for a given selector.' It specifies the verb ('Check'), resource ('DKIM DNS record'), and scope ('domain' and 'selector'). However, it doesn't explicitly differentiate from sibling DNS-related tools like 'dns_lookup' or 'txt_lookup', which could also retrieve DKIM records, so it falls short of a perfect score.
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 explains what DKIM is ('allows the receiver to verify that an email was sent by the domain owner'), but doesn't specify use cases, prerequisites, or comparisons to sibling tools like 'dns_lookup' for general DNS queries or 'dmarc_check' for related email authentication. This leaves the agent without explicit usage instructions.
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?
Annotations cover key traits (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description adds minimal context by implying a hosting/serving action, but does not detail behavioral aspects like rate limits, authentication needs, or what 'host and serve' entails operationally. No contradiction with annotations exists.
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 that front-loads the core action ('Host and serve') without unnecessary details. Every word contributes to understanding the tool's purpose, making it appropriately sized and well-structured.
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?
Given the tool's moderate complexity (2 parameters, no output schema), annotations provide safety and idempotency info, but the description lacks completeness. It does not explain what happens after hosting (e.g., how the file is served, any URLs or confirmation returned), leaving gaps for the agent to infer outcomes.
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 100%, with clear descriptions for both parameters (domain_name and bimi_file). The description does not add meaning beyond the schema, such as explaining the purpose of these inputs in the hosting process, so it meets the baseline of 3 without compensating for any gaps.
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 action ('Host and serve') and resource ('BIMI SVG file for email authentication'), distinguishing it from sibling tools like bimi_check (which likely verifies rather than hosts) and other DNS/email authentication tools. It specifies the exact purpose without being vague or tautological.
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 (e.g., needing a domain and BIMI file ready), exclusions, or comparisons to siblings like bimi_check or dmarc_generate, leaving the agent to infer 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds context about what the tool returns ('Shows where a hostname aliases to'), which is useful but not extensive behavioral detail beyond annotations.
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 two concise sentences that directly state the tool's purpose and output without unnecessary words. It is front-loaded with the core action and efficiently conveys essential information.
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 (single parameter, no output schema), rich annotations, and clear purpose, the description is largely complete. However, it could benefit from more explicit usage guidance relative to siblings to fully address contextual needs.
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 100%, with the parameter 'domain_name' fully documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as format details or examples, so it meets the baseline for high schema coverage.
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 specific action ('Look up CNAME records') and resource ('for a domain'), and distinguishes it from siblings by specifying the exact DNS record type (CNAME) rather than general DNS operations like 'dns_lookup' or other record types like 'mx_lookup' or 'txt_lookup'.
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 implies usage for CNAME-specific queries, but does not explicitly state when to use this tool versus alternatives like 'dns_lookup' (which might return multiple record types) or other sibling tools for different DNS records. No exclusions or prerequisites are mentioned.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds context about BIMI's purpose ('display their logo next to authenticated emails in supporting email clients'), which is useful behavioral insight beyond annotations, though it doesn't detail rate limits or specific 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 two sentences: the first states the tool's purpose clearly, and the second provides helpful background on BIMI. It is front-loaded with the core function and avoids unnecessary details, making it efficient and easy to understand.
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 (1 parameter, no output schema) and rich annotations covering key behavioral traits, the description is mostly complete. It explains what BIMI is and the tool's purpose, but could improve by mentioning output format or error handling, though not strictly required with annotations present.
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 100%, with the parameter 'domain_name' fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or validation rules, so it meets the baseline for high schema coverage.
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 specific action ('Check if a domain has a valid BIMI DNS record') and the resource involved ('domain'), distinguishing it from sibling tools like dns_lookup or txt_lookup by focusing specifically on BIMI records. It also explains what BIMI is, providing additional context.
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 implies usage by mentioning 'BIMI allows brands to display their logo next to authenticated emails', suggesting it's for email authentication purposes. However, it lacks explicit guidance on when to use this tool versus alternatives like dkim_check or dmarc_check, or any prerequisites or exclusions.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds minimal behavioral context by noting the impact on email deliverability, but doesn't disclose details like rate limits, authentication needs, or what 'popular' blacklists entail. No contradiction with annotations.
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 two sentences that are front-loaded with the core purpose and efficiently explain the impact. Every sentence adds value without redundancy, making it appropriately sized and well-structured for quick understanding.
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 (1 parameter, no output schema), good annotations, and high schema coverage, the description is mostly complete. It covers the purpose and impact, but could improve by specifying which blacklists are checked or providing more behavioral details, though annotations help fill some gaps.
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 100%, with the parameter 'domain_name' fully documented in the schema as 'The domain name or IP address to check against blacklists, e.g. example.com or 1.2.3.4.' The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline for high coverage.
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 specific action ('Check if a domain or IP address is listed') and resource ('popular email blacklists (DNSBLs)'), distinguishing it from sibling tools like dns_lookup or spf_check which perform different DNS-related operations. It also explains the practical impact ('can severely impact email deliverability'), adding context beyond the basic function.
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 implies usage context by mentioning 'email deliverability,' suggesting this tool is for email-related blacklist checks, but it doesn't explicitly state when to use it versus alternatives like smtp_check or dns_lookup. No exclusions or specific alternatives are named, though the context is clear for email-focused scenarios.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds context about DMARC's function (handling emails that fail SPF/DKIM), which is useful but does not disclose additional behavioral traits like rate limits, error handling, or output format. No contradiction with annotations.
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 two sentences that are front-loaded with the core purpose and efficiently explain DMARC's role. Every sentence adds value without redundancy, making it appropriately sized and well-structured for quick understanding.
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 (single parameter, no output schema), rich annotations covering key behavioral aspects, and clear purpose, the description is mostly complete. However, it could benefit from mentioning the return type or what 'valid' entails, but annotations help compensate, making it adequate for the context.
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 100%, with the parameter 'domain_name' fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or validation rules, so it meets the baseline for high schema coverage without extra value.
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 ('Check') and resource ('DMARC DNS record'), specifies the purpose ('valid DMARC record'), and distinguishes from siblings by focusing on DMARC rather than other DNS checks like SPF or DKIM. It provides a concise explanation of what DMARC does, making the purpose specific and well-defined.
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 implies usage for verifying DMARC records on domains, which is clear in context, but does not explicitly state when to use this tool versus alternatives like spf_check or dkim_check. It provides some guidance by explaining DMARC's role, but lacks explicit exclusions or named alternatives for sibling tools.
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?
Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating it's a non-destructive, idempotent creation tool. The description adds value by specifying the output format ('record name, value, and type ready to be added to DNS'), which clarifies the tool's behavior beyond annotations. However, it doesn't mention potential rate limits, authentication needs, or error handling.
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, well-structured sentence that efficiently states the action, resource, and output without redundancy. It's front-loaded with the core purpose and avoids unnecessary details, making it highly concise and easy to parse.
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 moderate complexity (3 parameters, no output schema), the description is reasonably complete: it covers the purpose, output format, and distinguishes from siblings. However, it lacks details on error cases, dependencies (e.g., DNS configuration), or example usage, which could enhance completeness for an agent.
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 100%, with clear descriptions for all parameters (domain_name, email, dmarc_policy) including an enum for dmarc_policy. The description doesn't add any parameter-specific details beyond the schema, such as format examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
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 specific action ('generate a DMARC DNS record') and resource ('for a domain'), distinguishing it from sibling tools like dmarc_check (which verifies) and spf_generate (which generates SPF records). It also specifies the output format ('record name, value, and type'), making the purpose explicit and differentiated.
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 implies usage when a DMARC record needs to be created, but it doesn't explicitly state when to use this tool versus alternatives like dmarc_check for verification or spf_generate for SPF records. No guidance is provided on prerequisites, such as DNS access or domain ownership, leaving usage context partially implied.
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?
Annotations already indicate this is a read-only, non-destructive, idempotent, and open-world operation. The description adds value by specifying that it involves connection and authentication attempts, which provides context beyond the annotations. However, it doesn't detail potential outcomes like success/failure states or error handling, leaving some behavioral aspects unclear.
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 front-loaded with the core purpose in the first sentence and adds a usage guideline in the second, with zero wasted words. Both sentences earn their place by clarifying the tool's function and context efficiently.
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 moderate complexity (5 required parameters) and rich annotations covering safety and behavior, the description is mostly complete. It lacks an output schema, so it doesn't explain return values, but the purpose and usage are clear. A minor gap exists in not detailing potential results or errors, but annotations provide sufficient context for a testing tool.
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 100%, with each parameter well-documented in the input schema (e.g., hostname examples, port ranges, encryption options). The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating further.
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 specific action ('Test an IMAP server connection by attempting to connect and authenticate') and the resource ('IMAP server'), distinguishing it from sibling tools like 'imap_finder' which likely discovers servers rather than testing connections. The phrase 'verify email receiving configuration' further clarifies the use case.
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 context for when to use this tool ('to verify email receiving configuration'), but does not explicitly mention when not to use it or name alternatives. For example, it doesn't contrast with 'smtp_check' for sending configuration or 'imap_finder' for server discovery, though the purpose is distinct enough to imply usage.
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?
Annotations already cover key behavioral traits (read-only, non-destructive, idempotent, open-world). The description adds useful context about what is returned (host, port, encryption settings), but does not disclose additional aspects like rate limits, error handling, or data freshness.
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 two sentences, front-loaded with the core purpose and followed by usage context. Every word earns its place with no redundancy or fluff, making it highly efficient.
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?
For a simple lookup tool with good annotations and full schema coverage, the description is mostly complete. However, without an output schema, it could benefit from specifying the return format (e.g., structured object with host/port/encryption fields) to fully guide the agent.
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 100%, so the schema fully documents the single parameter. The description adds no extra meaning beyond implying the parameter accepts common provider names, which aligns with the schema's description. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('look up IMAP server settings') and resource ('for a given email provider'), with examples of providers (Gmail, Outlook, Yahoo). It distinguishes from siblings like 'imap_check' (likely for testing connections) and 'smtp_finder' (for SMTP settings).
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 context for when to use this tool ('to find the correct IMAP configuration for services like Gmail, Outlook, Yahoo, etc.'), but does not explicitly state when not to use it or name alternatives (e.g., 'imap_check' for verifying settings).
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds useful context about what the tool returns (mail servers with priorities), which isn't captured in annotations. It doesn't contradict annotations and provides additional behavioral information.
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 two concise sentences that directly state the purpose and output. Every word earns its place with no redundancy or fluff, and it's front-loaded with the core functionality.
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?
For a simple lookup tool with one parameter, rich annotations (covering safety and idempotency), and no output schema, the description provides adequate context. It explains what the tool does and what it returns, though it could benefit from more explicit usage guidance relative to siblings.
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 100%, with the parameter 'domain_name' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
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 specific action ('look up MX records'), the resource ('for a domain'), and the output ('returns the mail servers and their priorities'). It distinguishes from siblings by focusing specifically on MX records rather than other DNS record types or email-related checks.
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 implies usage context (when you need MX records for a domain) but doesn't explicitly state when to use this tool versus alternatives like 'dns_lookup' (which might return multiple record types) or other email-related checks. No exclusions or prerequisites are mentioned.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable behavioral context beyond annotations by specifying that it 'attempts to connect and authenticate' and 'optionally sends a test email to verify full sending capability', which clarifies the tool's operational behavior and optional destructive action (sending email).
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?
Two sentences that are front-loaded with the core purpose and efficiently convey optional extended functionality. Zero wasted words - every phrase earns its place by adding distinct value about the tool's behavior.
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?
For a connectivity testing tool with comprehensive annotations and full schema coverage, the description provides adequate context. It clarifies the two-phase nature (connection/auth test plus optional email sending) which isn't captured in structured fields. The main gap is lack of output format information (no output schema), but the description compensates reasonably given the tool's straightforward purpose.
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 100%, so the schema fully documents all 7 parameters. The description mentions 'optionally sends a test email' which hints at the optional 'from_email' and 'to_email' parameters, but adds minimal semantic value beyond what's already in the schema descriptions. Baseline 3 is appropriate given complete schema coverage.
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 with specific verbs ('test', 'connect', 'authenticate', 'sends') and resource ('SMTP server connection'). It distinguishes from sibling tools by focusing on SMTP connectivity testing rather than DNS lookups, BIMI checks, or other email-related diagnostics.
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 implies usage context ('test an SMTP server connection') but doesn't explicitly state when to use this versus alternatives like 'smtp_finder' or 'imap_check'. No guidance on prerequisites or exclusions is provided, leaving the agent to infer appropriate scenarios.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds value by specifying that it checks 'valid SPF records' and explains SPF's purpose, which helps the agent understand the domain-specific validation context beyond the generic annotations.
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 front-loaded with the core purpose in the first sentence, followed by a concise explanation of SPF. Both sentences are essential—the first defines the tool's action, and the second provides necessary context—with no redundant or verbose language.
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 (single parameter, no output schema) and rich annotations, the description is reasonably complete. It explains what SPF is and the tool's purpose, though it could benefit from mentioning output expectations (e.g., returns validation status) since there's no output schema.
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 100%, with the parameter 'domain_name' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or validation rules, so it meets the baseline for high schema coverage without extra value.
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 specific action ('Check if a domain has a valid SPF DNS record') and resource ('domain'), distinguishing it from siblings like spf_generate (which creates records) and other DNS-related tools. It provides precise technical context about SPF's purpose, making the tool's function unambiguous.
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 implies usage for SPF validation but doesn't explicitly state when to use this tool versus alternatives like dns_lookup or txt_lookup for broader DNS queries, or spf_generate for creating records. It provides context but lacks explicit guidance on exclusions or comparisons with sibling tools.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable context by specifying that it returns 'all TXT records' and listing common content types (SPF policies, verification tokens, DKIM keys), which helps the agent understand what to expect beyond the basic read operation.
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 two concise sentences that are front-loaded with the core purpose. Every word earns its place by clarifying the scope (all TXT records) and providing examples of content, with no redundant or unnecessary information.
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?
For a simple lookup tool with rich annotations (read-only, non-destructive, idempotent, open-world) and full schema coverage, the description is reasonably complete. It adds context about TXT record content, though it doesn't specify output format or error handling, which is acceptable given the straightforward nature of the tool and lack of output schema.
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 100% with a single well-documented parameter (domain_name). The description doesn't add any parameter-specific information beyond what the schema already provides (e.g., no additional constraints or examples). This meets the baseline of 3 when schema coverage is high.
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 specific action ('Look up all TXT records for a domain') and distinguishes it from siblings by focusing exclusively on TXT records, unlike other tools that check SPF, DMARC, DKIM, or perform general DNS lookups. The examples of TXT record content (SPF policies, verification tokens, DKIM keys) further clarify the purpose.
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 implies usage for retrieving TXT records, but doesn't explicitly state when to use this tool versus alternatives like dns_lookup (which might return all record types) or specific check tools (spf_check, dkim_check). No exclusions or prerequisites are mentioned, leaving some ambiguity about tool selection.
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?
Annotations cover read-only, non-destructive, idempotent, and open-world hints. The description adds value by specifying the scope ('all DNS records') and return types, which are not in annotations. No contradiction with annotations.
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?
Two sentences, front-loaded with the core purpose, no wasted words. Every sentence adds value: the first defines the action and scope, the second lists return types.
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, rich annotations, and 100% schema coverage, the description is mostly complete. It lacks output schema, but the return types are listed, compensating adequately. Could improve by mentioning error cases or limitations.
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 100%, with the parameter 'domain_name' fully documented. The description does not add meaning beyond the schema, such as format details or examples, so baseline 3 is appropriate.
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 ('Look up') and resource ('DNS records for a domain'), specifying it returns multiple record types (A, AAAA, CNAME, MX, NS, TXT, SOA). It distinguishes from siblings like mx_lookup or txt_lookup by emphasizing 'all DNS records in one query'.
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 implies usage for comprehensive DNS queries, but does not explicitly state when to use alternatives like mx_lookup for specific record types or other sibling tools. It provides clear context for bulk lookups without naming exclusions.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds value by explaining the importance of PTR records for email sending reputation, which is useful context beyond the annotations, though it doesn't detail rate limits or specific behavioral traits.
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 two sentences, front-loaded with the core purpose and followed by additional context about email reputation. Every sentence adds value without redundancy, making it efficient and well-structured.
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 (single parameter, 100% schema coverage, annotations covering key behaviors), the description is complete enough for a read-only lookup operation. However, without an output schema, it could benefit from mentioning the return format (e.g., hostname or error), but the context provided is adequate for basic use.
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 100%, with the ip_address parameter fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, so it meets the baseline of 3 without compensating with extra semantic information.
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 specific action ('Reverse DNS lookup') and resource ('Find the hostname associated with an IP address'), distinguishing it from siblings like dns_lookup or mx_lookup by focusing on PTR records specifically. It adds context about email reputation, which further clarifies its unique purpose.
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 implies usage for reverse DNS lookups related to email reputation, but does not explicitly state when to use this tool versus alternatives like dns_lookup or when not to use it. It provides clear context but lacks explicit exclusions or named alternatives.
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?
Annotations already indicate this is a read-only, non-destructive, idempotent, and open-world operation, covering safety and idempotency. The description adds useful context by specifying what settings are returned (host, port, encryption) and that it's for configuration lookup, which helps the agent understand the tool's behavior beyond the annotations. No contradictions with annotations are present.
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 two sentences that are front-loaded with the core purpose and efficiently provide usage context with examples. Every sentence adds value without redundancy, making it appropriately sized and well-structured for quick comprehension.
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 (single parameter, no output schema), rich annotations (covering read-only, non-destructive, idempotent, open-world), and clear purpose, the description is largely complete. However, it could slightly improve by hinting at the return format (e.g., structured data with host, port, encryption) or limitations (e.g., provider coverage), though annotations help mitigate this gap.
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?
The input schema has 100% description coverage, clearly documenting the single parameter 'provider_name' with examples. The description adds marginal value by reinforcing the parameter's purpose ('for a given email provider') and providing additional examples (e.g., SendGrid, Mailgun), but it does not introduce new semantics beyond what the schema already provides. This meets the baseline for high schema coverage.
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 specific action ('look up SMTP server settings') and resource ('for a given email provider'), with examples of providers like Gmail and Outlook. It distinguishes this tool from siblings like smtp_check (which likely tests SMTP connectivity) and imap_finder (which looks up IMAP settings), making the purpose unambiguous.
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 context for when to use this tool ('to find the correct SMTP configuration for services like Gmail, Outlook, SendGrid, etc.'), but it does not explicitly state when not to use it or name alternatives (e.g., using smtp_check for testing instead of lookup). This gives good guidance but lacks exclusions or direct sibling comparisons.
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 adds valuable behavioral context beyond annotations: it specifies the return format ('Returns the record name, value, and type ready to be added to DNS'), which is crucial since there's no output schema. Annotations already cover idempotency and non-destructive nature, but the description usefully explains what the tool produces. No contradiction with annotations.
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 perfectly concise with two sentences that each earn their place: the first states the purpose and context, the second specifies the return format. It's front-loaded with the core functionality and wastes no words. The structure is logical and efficient.
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 moderate complexity (3 parameters, no output schema), the description provides good contextual completeness. It explains what the tool does and what it returns, which is essential since there's no output schema. However, it could be more complete by mentioning typical use cases or prerequisites (like needing domain ownership). The annotations cover safety aspects well.
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?
With 100% schema description coverage, the input schema already fully documents all three parameters. The description doesn't add any additional parameter semantics beyond what's in the schema descriptions. It mentions the provider parameter generically but doesn't elaborate on the specific provider identifiers or their effects beyond what the schema already states.
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 specific action ('Generate an SPF DNS record'), target resource ('for a domain'), and purpose ('based on the email provider being used'). It distinguishes from sibling tools like spf_check (which verifies rather than generates) and dmarc_generate (which generates a different type of DNS record).
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 context about when to use this tool ('Generate an SPF DNS record for a domain based on the email provider being used'), but doesn't explicitly state when not to use it or name specific alternatives. It implies usage for SPF record generation rather than verification (spf_check) or other DNS tools, but lacks explicit exclusions or comparisons.
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:

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

Score Badge

Copy to your README.md:

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

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