Check SPF/DKIM/DMARC/BIMI, blacklists, SMTP/IMAP; DNS lookups; generate email DNS records.
Scored across 17 tools
Most tools target a distinct record type or action, and audit_domain is clearly framed as a bulk check versus the individual spf_check/dkim_check/dmarc_check. There is some overlap between dns_lookup (all records) and mx_lookup/txt_lookup/cname_lookup (subsets), plus audit_domain duplicating several single checks, but the descriptions clarify the boundaries well enough.
The set follows a consistent noun_action pattern (dkim_check, dmarc_generate, cname_lookup, imap_finder, smtp_check, etc.). audit_domain is the sole verb_noun outlier, a minor deviation in an otherwise predictable scheme.
17 tools is on the heavier side but each covers a specific, non-trivial deliverability concern (individual record checks, generators, auth testers, and provider finders). Nothing feels redundant enough to drop, so the count is reasonable though slightly large.
Strong coverage across SPF, DKIM, DMARC, BIMI, blacklist, MX, PTR, CNAME, DNS, TXT plus IMAP/SMTP check and provider finders, with generate helpers for SPF and DMARC. Minor gaps: no dkim_generate, and no MTA-STS/TLS-RPT or DNS propagation checks, but core lifecycle needs are met.
Use this when the user asks why their emails go to spam or wants a full deliverability check of a domain. Runs SPF, DKIM (finds the selector on its own), DMARC, blacklist and MX checks in one call and returns pass, warning or fail for each, an overall result, and the fixes to apply in priority order with help links. Takes about 10 seconds. mailX never changes DNS.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain to audit, e.g. example.com | |
| dkim_selector | No | The DKIM selector, e.g. google (Google Workspace), selector1 or selector2 (Microsoft 365). Optional: omit it to try common selectors. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds genuinely new context: per-check pass/warning/fail results, an overall result, priority-ordered fixes with help links, an ~10 second runtime, and 'never changes DNS'. It does not discuss rate limits or how the auto-selector discovery can fail, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the usage trigger, then the mechanics, return shape, timing and safety note. No filler and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: per-check statuses, an overall result, and prioritized fixes. Together with timing and the DNS-safety note, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning about dkim_selector by explaining that DKIM discovery happens automatically ('finds the selector on its own'), telling the agent the optional param can generally be omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (audits a domain) and enumerates exactly what it runs (SPF, DKIM, DMARC, blacklist, MX) 'in one call', which distinguishes it from the single-purpose siblings like spf_check and dkim_check. An agent can tell it is the aggregate deliverability tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit triggering contexts: 'when the user asks why their emails go to spam' or 'wants a full deliverability check'. It implies use of the aggregate over individual checks but never names a sibling or states when NOT to use it, so it falls short of a full when/when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about BIMI or showing a brand logo next to their emails in inboxes. Returns the live BIMI record, the logo URL it declares, and a fix suggestion.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain to check BIMI records for, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds the diagnostic behavior (returns a 'fix suggestion' alongside the live record), which is useful context, but says nothing about lookup latency, propagation caveats, or what happens when no BIMI record exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the trigger condition is front-loaded ahead of the return-value summary. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required param, no nested objects, and no output schema, the description usefully covers both invocation context and expected return content, which compensates for the absent output schema. It stops short of describing failure/empty-record behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single domain_name parameter, whose description already supplies the 'e.g. example.com' format. The description adds no syntax or constraint detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (check the live BIMI record for a domain) and even previews the return payload: the BIMI record, the declared logo URL, and a fix suggestion. It is clearly distinguishable from sibling DNS/auth tools by topic, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger in user-intent terms: 'when the user asks about BIMI or showing a brand logo next to their emails in inboxes.' That is a clear when-to-use condition, but there are no exclusions or pointers to sibling tools such as txt_lookup or dmarc_check for adjacent diagnoses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user suspects their domain is blacklisted or blocked. Checks the domain against major DNS blocklists and returns the result for each list.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain name or IP address to check against blacklists, e.g. example.com or 1.2.3.4 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the external-network nature is declared. The description adds that the check spans multiple "major" blocklists and returns per-list results, which is useful context, but it does not say which lists are queried, whether results are cached/authoritative, or how many lists to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the usage trigger is front-loaded ahead of the mechanics. Every clause earns its place by either telling the agent when to call the tool or what it produces.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only lookup with no output schema, the description supplies the trigger condition, the mechanism, and a one-line return summary. It stops short of describing the response fields or what a partial/error result looks like, but nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented with examples ("example.com or 1.2.3.4"), so the schema carries the load. The description adds no syntax or format detail beyond what is already in the schema, making 3 the correct baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Checks the domain against major DNS blocklists") and even summarizes the return shape ("returns the result for each list"). It implicitly distinguishes itself from DNS-record siblings like spf_check or mx_lookup by naming blocklists, but it never names an alternative explicitly, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when the user suspects their domain is blacklisted or blocked" gives a concrete triggering condition rather than a vague hint. There are no exclusions or named alternatives, however, so an agent facing a general "is my email setup healthy?" request gets no routing help among the many sibling check tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants to know whether a hostname is an alias of another one, for example to verify DKIM or tracking CNAMEs. Returns the live CNAME target.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain to look up CNAME records for, e.g. www.example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and idempotency profile is fully covered. The description adds minor context by saying it returns the live CNAME target, but says nothing about behavior when no CNAME exists or about resolution failures. Adequate but not rich 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste: the usage condition is front-loaded and the return statement is a single tight clause. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only lookup with full annotation coverage and no output schema, the description covers triggering and return intent. The only gap is what happens on a negative result (no CNAME present), which is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter count is 1 with 100% schema description coverage, so the schema already documents domain_name with an example. The description adds no format, normalization, or edge-case guidance for the parameter. Baseline 3 applies when the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: looks up whether a hostname is a CNAME alias and returns the live target. It is distinguishable from siblings like ptr_lookup, mx_lookup, or txt_lookup by naming the CNAME record type directly. It does not explicitly contrast with the broader dns_lookup sibling, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition ('when the user wants to know whether a hostname is an alias of another one') plus concrete examples (verifying DKIM or tracking CNAMEs). No explicit when-not or named alternative tool, so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants to verify DKIM for a domain. Pass the DKIM selector if known (for example google for Google Workspace, selector1 or selector2 for Microsoft 365). If the selector is unknown, omit it: mailX then tries common selectors and returns the ones it finds. Returns the published key and its status. A miss on common selectors does not prove DKIM is absent.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain to check DKIM records for, e.g. example.com | |
| dkim_selector | No | The DKIM selector, e.g. google (Google Workspace), selector1 or selector2 (Microsoft 365). Optional: omit it to try common selectors. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description still adds real value: the fallback behavior when the selector is omitted (tries common selectors and returns those found) and the important caveat that a miss does not prove absence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, front-loaded with the purpose and the key conditional, then the fallback behavior and the caveat. No filler; every sentence carries usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the return value ('the published key and its status') and the main limitation of a negative result, which is the critical completeness concern for this tool. Error handling beyond the miss caveat is unstated but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including the selector examples (google, selector1/selector2) and the omit-to-try-common behavior. The description largely restates what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'verify DKIM for a domain.' The resource (DKIM) inherently separates it from siblings like dmarc_check and spf_check, so an agent can route to it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit when-to-use ('when the user wants to verify DKIM for a domain') and adds conditional guidance for the selector known/unknown cases. It does not explicitly name alternative tools, but the DKIM-specific scope makes the distinction self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about DMARC, spoofing protection, or what happens to emails that fail authentication. Returns the live DMARC record, its policy and a fix suggestion.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain to check DMARC records for, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds behavior the annotations do not: that the record is fetched live and that the response includes a policy interpretation plus a remediation suggestion — meaningful for a no-output-schema tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the selection trigger is front-loaded ahead of the return-value summary. Nothing here could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with rich annotations and no output schema, the description covers both when to call it and what comes back. The only real omission is how a missing or absent DMARC record is reported, which matters for a DNS-lookup tool whose negative results are common.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter with 100% schema description coverage including an example, so the schema does the work. The description adds no syntax, format, or edge-case guidance (e.g. subdomains, IDN, or whether a bare domain is required). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific resource (DMARC record) with what it returns: the live record, its policy, and a fix suggestion. That is enough to separate it from dkim_check and spf_check in principle, but it never names those siblings, so the differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when the user asks about DMARC, spoofing protection, or what happens to emails that fail authentication" gives a clear trigger context, including the user-intent phrasings an agent will actually encounter. It stops short of exclusions or alternatives (e.g. route SPF questions to spf_check), so no score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user needs a DMARC record. Returns the record name, value and type ready to publish. mailX does not publish it.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to receive DMARC aggregate reports, e.g. dmarc@example.com | ||
| domain_name | Yes | The domain to generate a DMARC record for, e.g. example.com | |
| dmarc_policy | Yes | The DMARC policy: none (monitor only), quarantine (mark as spam), or reject (block entirely) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds two genuinely useful facts beyond them: the return shape (record name, value, type) and the explicit boundary that mailX does not publish the record. It stops short of describing validation behavior or record formatting details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, with the trigger condition front-loaded and the output/limitation facts following. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully names the returned fields and clarifies that publishing is out of scope, and annotations cover the safety profile. It leaves the practical question of how the returned record is applied somewhat open, hence not a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the three required parameters documented including the enum meanings for dmarc_policy and examples for domain_name and email. The description adds no parameter-level detail, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('generate a DMARC record') and distinguishes itself from the check-style tools by framing the trigger as 'the user needs a DMARC record'. It never names the obvious sibling (dmarc_check) or the analogous spf_generate, so the differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a use context ('when the user needs a DMARC record') but no when-not-to-use and no alternative named. An agent must infer that dmarc_check is for inspecting existing records while this one creates a new one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants every DNS record for a domain in one view (A, AAAA, CNAME, MX, NS, TXT, SOA). Returns the live records grouped by type.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain to look up all DNS records for, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds only the return shape ("live records grouped by type"), which is modest added value; it says nothing about failure behavior for nonexistent domains, caching, or latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no waste; the usage trigger is front-loaded ahead of the return description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only lookup tool with no output schema, the description covers purpose, when to use it, and the shape of the result. Minor gaps remain around behavior for domains with no records or partial results, but nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single domain_name parameter, including an example (example.com), so the schema does the heavy lifting. The description adds no format or edge-case detail (e.g., subdomain handling) beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (look up) and resource (DNS records for a domain), and enumerates the record types covered (A, AAAA, CNAME, MX, NS, TXT, SOA). This clearly separates it from the narrower siblings mx_lookup, txt_lookup, and cname_lookup, which an agent can distinguish without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when the user wants every DNS record for a domain in one view" gives a clear triggering condition. It does not, however, explicitly exclude the narrower siblings (mx_lookup, txt_lookup, cname_lookup) for single-type queries, so the agent must infer that routing itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this only when the user explicitly asks to test an IMAP login for a mailbox they control and provides its credentials. Connects to the IMAP server and reports whether connection, encryption and authentication succeed. Credentials are not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | The IMAP password or app-specific password | |
| username | Yes | The IMAP username for authentication | |
| imap_host | Yes | The IMAP server hostname, e.g. imap.gmail.com | |
| imap_port | Yes | The IMAP port number, e.g. 993 for SSL, 143 for unencrypted | |
| imap_encryption | Yes | The encryption protocol: ssl, tls, or none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent, non-destructive, open-world behavior, so the safety burden is lighter. The description still adds real value beyond them by disclosing exactly what is attempted (connection, encryption, authentication) and the credential-handling policy ('Credentials are not stored'), which an agent may need to reassure a user about.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler; the restrictive usage condition and the no-storage guarantee are both front-loaded and immediately actionable. Slightly unusual to lead with the constraint rather than the purpose, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter, all-required diagnostic tool with no output schema, the description covers what is tested and the outcome semantics (each of connection/encryption/auth either succeeds or not). It does not mention timeouts, network egress expectations, or failure modes, which are minor gaps given openWorldHint is annotated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter has its own description including examples (993 for SSL, enum values for encryption), so the schema does the heavy lifting. The description adds no parameter-level detail beyond that, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: connects to the IMAP server and reports whether connection, encryption and authentication succeed. This is functionally distinct from sibling imap_finder (which discovers settings) and smtp_check, so an agent can route correctly without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit gating condition - only when the user explicitly asks to test an IMAP login for a mailbox they control and supplies credentials - which functions as a when-not guard. It stops short of naming an alternative tool or describing what to do when the user only wants settings discovered, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user needs the incoming mail (IMAP) server settings for an email provider, such as Gmail, Outlook, Yahoo, iCloud or Zoho. Returns the host, ports with encryption and the provider's setup guide. Never asks for the user's credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| imap_provider_name | Yes | The email provider name to look up, e.g. gmail, outlook, yahoo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: it returns host, ports with encryption, and a provider setup guide, and it explicitly never asks for credentials. With no output schema present, disclosing the return shape is valuable; it does not mention error behavior for unknown providers, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, no filler. The trigger condition leads, followed by what is returned and the credential-safety note — correctly front-loaded for fast decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only lookup with no output schema, the description supplies everything an agent needs: the trigger, the return fields, and the assurance that no credentials are required. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, so the baseline is 3. The description adds a few provider examples (iCloud, Zoho) beyond the schema's list, but gives no guidance on name format, case sensitivity, or fallback when a provider is unrecognized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — retrieving incoming mail (IMAP) server settings — and names the provider category (Gmail, Outlook, Yahoo, iCloud, Zoho). It is clearly distinguishable from the sibling tools smtp_finder (outgoing) and imap_check (connectivity testing), so an agent can route correctly without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition ('when the user needs the incoming mail (IMAP) server settings for an email provider') plus concrete provider examples. It does not explicitly name the adjacent alternatives (smtp_finder for outgoing, imap_check for testing a live server) or state when not to use it, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants to know which mail servers receive email for a domain. Returns the domain's live MX records with their priorities.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain to look up MX records for, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered externally. The description still adds value beyond that by noting the records are "live" (fresh, real-time resolution rather than cached) and that priorities are included in the result, though it says nothing about failure behavior for nonexistent or unresolvable domains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: the first front-loads the usage condition, the second states the return content. No filler, no restating of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by naming what comes back (MX records with priorities), while the annotations carry the safety and open-world semantics. For a single-parameter read-only lookup, nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter and schema description coverage is 100%, so the schema already fully documents domain_name including an example. The description adds no syntax or format detail beyond the schema, which is the expected baseline at full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (look up / receive email for) and resource (MX records for a domain), framed from the user's intent ("which mail servers receive email for a domain"). It is clear on its own, but it does not distinguish itself from overlapping siblings such as dns_lookup or smtp_finder, which an agent might reasonably consider interchangeable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when the user wants to know which mail servers receive email for a domain" gives a concrete triggering condition, so the agent knows when this tool applies. It stops short of naming alternatives or exclusions (e.g. "use dns_lookup for general record types"), so there is no explicit routing guidance against its many sibling lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants the reverse DNS (PTR) of an IP address, for example to check a sending server's reverse DNS. Returns the hostname the IP resolves to.
| Name | Required | Description | Default |
|---|---|---|---|
| ip_address | Yes | The IP address to look up, e.g. 8.8.8.8 or 142.250.80.46 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety and idempotency profile is fully covered. The description adds value beyond them by stating what is returned (the resolved hostname). It does not mention the common failure case where no PTR record exists, which leaves a small gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the usage trigger front-loaded and the return value following. No filler, no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with no output schema, the description covers purpose, trigger, and return shape, and annotations cover the safety profile. Only the no-record/failed-resolution behavior is unaddressed, a minor omission for this tool type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented with example IPs in the schema. The description only restates that the input is an IP address, adding no format or edge-case detail (IPv4 vs IPv6, literal vs hostname). Baseline 3 is appropriate when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: reverse DNS (PTR) lookup of an IP address, and clarifies the output is the hostname the IP resolves to. This cleanly distinguishes it from siblings like dns_lookup, cname_lookup, and mx_lookup without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('when the user wants the reverse DNS of an IP address') plus a concrete scenario ('check a sending server's reverse DNS'), which strongly implies usage context. It stops short of naming when to prefer a sibling (e.g., dns_lookup for forward resolution) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this only when the user explicitly asks to test an SMTP login for a mail account they control and provides its credentials. Connects to the SMTP server and reports whether connection, encryption and authentication succeed. If from_email and to_email are both given, it also sends one test email. Credentials are not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | The SMTP server hostname, e.g. smtp.gmail.com | |
| port | Yes | The SMTP port number, e.g. 587 for TLS, 465 for SSL, 25 for unencrypted | |
| password | Yes | The SMTP password or app-specific password | |
| to_email | No | Optional recipient email address for sending a test email | |
| username | Yes | The SMTP username for authentication | |
| encryption | Yes | The encryption protocol: ssl, tls, or none | |
| from_email | No | Optional sender email address for sending a test email |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint=true and readOnlyHint=false, so the agent already knows this touches the network and is not a pure read. The description adds real value beyond that: it discloses the side effect of sending one test email when from_email and to_email are both supplied, and states credentials are not stored. It does not mention timeouts or failure semantics, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with the usage restriction front-loaded, followed by behavior and then the data-handling note. No filler and nothing redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey what comes back; it does so at a high level (success of connection, encryption, authentication). Combined with 100% param coverage and the credential non-storage note, an agent has enough to call it correctly, though error/timeout behavior is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description goes slightly further by stating the conditional logic the schema omits — that a test email is only sent when both from_email and to_email are given — which is genuinely new meaning for those two optional params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource (test an SMTP login) and enumerates exactly what is verified: connection, encryption and authentication, plus the optional test email. This is clearly distinguishable from the sibling smtp_finder (discovery) and imap_check (different protocol).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit precondition — only when the user explicitly asks to test an SMTP login for an account they control and supplies credentials. That is a strong when-to-use gate, but it does not name an alternative tool (e.g. smtp_finder) for the discovery case, so the routing guidance is one-sided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user needs the outgoing mail (SMTP) server settings for an email provider or sending service, such as Gmail, Outlook, Microsoft 365, Zoho, Amazon SES or SendGrid. Returns the host, ports with encryption, what to use to log in, and the provider's setup guide. Never asks for the user's credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| provider_name | Yes | The email provider name to look up, e.g. gmail, sendgrid, mailgun, outlook |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context: it enumerates what comes back (host, ports with encryption, login method, provider setup guide) and explicitly states it never asks for credentials, which is meaningful because sibling check tools do require creds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the usage trigger, then return contents, then the credential reassurance. No repetition of the title and no filler; every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns and does so concretely (host, encrypted ports, login method, setup guide). Combined with the credential note and provider examples, an agent has everything needed to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100% for the single provider_name parameter, so baseline is 3. The description adds value by enumerating valid providers including ones absent from the schema examples (Microsoft 365, Zoho, Amazon SES), helping the agent map user phrasing to a lookup value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: retrieving outgoing SMTP server settings for a named provider, with concrete provider examples (Gmail, Outlook, Microsoft 365, SendGrid). It does not however explicitly distinguish itself from the closely-named siblings smtp_check (live connectivity test) or imap_finder (incoming counterpart), leaving that inference to the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when the user needs the outgoing mail (SMTP) server settings..." gives a clear triggering condition. There are no explicit exclusions and no named alternatives despite strong sibling overlap with smtp_check and imap_finder, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether a domain's SPF record is valid, which servers may send email for a domain, or why SPF fails. Returns the live SPF record, a pass/fail status and a fix suggestion.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain to check SPF records for, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so safety and idempotency are covered. The description adds real value on top by disclosing what is returned — the live record, a pass/fail status, and a fix suggestion — confirming a live external lookup rather than a cached or local check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first front-loads the usage triggers, the second enumerates the return values. No repetition of the name/title and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description compensates by describing the three returned artifacts, and annotations cover the safety profile. For a single-parameter, read-only diagnostic this is fully sufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter exists, and schema description coverage is 100% with an example (example.com), so the schema fully documents it. The description adds no additional format or edge-case guidance (e.g., subdomains, domains without SPF), so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (the domain's SPF record) and the exact outcomes checked — validity, which servers may send for the domain, and why SPF fails. This makes it trivially distinguishable from parallel siblings like dmarc_check, dkim_check, and especially spf_generate, since it operates on a live record rather than producing one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit when-to-use clause keyed to user intents ('asks whether a domain's SPF record is valid', 'which servers may send email', 'why SPF fails'). It stops short of naming an alternative tool or stating when NOT to use it (e.g., use spf_generate to create a record instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user needs a new SPF record for their email provider. Returns a TXT record ready to publish, or explains what to set up instead when the provider does not need a root SPF include. mailX does not publish it.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Email provider identifier. Google Workspace or Gmail = google. Microsoft 365, Office 365 or Outlook = microsoft. Amazon SES = amazon-ses. Common provider names are also accepted. | |
| domain_name | Yes | The domain to generate an SPF record for, e.g. example.com | |
| hard_fail_boolean | Yes | If true, uses strict -all policy (reject unauthorized senders). If false, uses soft ~all (mark but deliver). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false. The description adds genuinely useful context beyond them: it returns a TXT record, it may instead return setup guidance when a root include isn't needed, and mailX does not publish the record – clarifying there are no DNS side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the usage trigger, followed by output behavior and the non-publishing caveat. Tight overall; the phrase 'Use this when the user needs' is slightly boilerplate but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries responsibility for describing returns and does so ('TXT record ready to publish' or alternative setup guidance). Combined with full schema coverage and safety annotations, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including a well-annotated enum for provider and an explanation of hard_fail's -all vs ~all behavior, so the schema carries the parameter semantics. The description adds no parameter-level detail, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('generate an SPF record') and scopes it to a new record for the user's email provider. It contrasts implicitly with spf_check (existing record validation) but never names the sibling, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening clause gives a clear trigger condition ('when the user needs a new SPF record'), which is enough to route correctly against spf_check/dmarc_generate. It does not state when-not-to-use it or name the alternative tool explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants to see a domain's TXT records, for example to find verification tokens or check what SPF or other policies are published. Returns all live TXT records.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain to look up TXT records for, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the bar is lower. The description still adds output-shaping context by saying it returns ALL live records (i.e., unfiltered), which the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the usage trigger front-loaded before the return behavior. Nothing needs trimming, though there is little beyond the minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description bears some responsibility for describing what comes back, and it only says 'all live TXT records' without indicating record format, count, or failure behavior (e.g., NXDOMAIN). Adequate for a one-parameter lookup, but thin given the absent output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single domain_name parameter, and the description adds no format, validation, or example detail beyond the schema's own 'e.g. example.com'. Baseline 3 is appropriate when the schema carries the full parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('see a domain's TXT records') and scopes the result set ('all live TXT records'). It does not, however, explicitly distinguish itself from the similarly generic sibling dns_lookup or from the policy-specific spf_check/dmarc_check tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use context ('when the user wants to see a domain's TXT records') plus concrete motivating examples such as verification tokens. It stops short of stating when NOT to use it, even though siblings like spf_check and dmarc_check overlap with one of the cited examples (checking SPF policies).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
audit_domaindkim_check2 fields changedInput schema / properties / dkim_selector / descriptionPrevious value: -"The DKIM selector to look up, e.g. google, default, selector1"New value: +"The DKIM selector, e.g. google (Google Workspace), selector1 or selector2 (Microsoft 365). Optional: omit it to try common selectors."Input schema / requiredPrevious value: -[
- "domain_name",
- "dkim_selector"
-]New value: +[
+ "domain_name"
+]spf_generate2 fields changedInput schema / properties / provider / descriptionPrevious value: -"The mail provider identifier, e.g. google, mailgun, sendgrid, postmark, amazon-ses"New value: +"Email provider identifier. Google Workspace or Gmail = google. Microsoft 365, Office 365 or Outlook = microsoft. Amazon SES = amazon-ses. Common provider names are also accepted."Input schema / properties / provider / enumAdded value: +[
+ "activecampaign",
+ "amazon-ses",
+ "aweber",
+ "bluehost",
+ "brevo",
+ "campaign-monitor",
+ "constant-contact",
+ "elastic-email",
+ "fastmail",
+ "freshdesk",
+ "gandi",
+ "getresponse",
+ "godaddy",
+ "google",
+ "hostgator",
+ "hostinger",
+ "hubspot",
+ "icloud",
+ "infomaniak",
+ "intercom",
+ "ionos",
+ "ionos-eu",
+ "kit",
+ "klaviyo",
+ "mailbox-org",
+ "mailchimp",
+ "mailersend",
+ "mailgun",
+ "mailjet",
+ "mandrill",
+ "microsoft",
+ "migadu",
+ "moosend",
+ "namecheap",
+ "ovh",
+ "postmark",
+ "protonmail",
+ "purelymail",
+ "rackspace",
+ "resend",
+ "salesforce",
+ "sendgrid",
+ "smtp2go",
+ "sparkpost",
+ "titan",
+ "yandex",
+ "zendesk",
+ "zeptomail",
+ "zoho"
+]bimi_hostbimi_checkbimi_hostblacklist_checkcname_lookupdkim_checkdmarc_checkdmarc_generatedns_lookupimap_checkimap_findermx_lookupptr_lookupsmtp_checksmtp_finderspf_checkspf_generatetxt_lookupCheck a domain's DMARC, SPF, DKIM, MX, BIMI and MTA-STS records. Generate SPF and DMARC records.
Email deliverability checks: SPF, DKIM, DMARC, BIMI, MTA-STS, blacklists, headers, spam words
Check a domain's DMARC, SPF and DKIM, build SPF records, explain bounces, read DMARC reports.
SPF, DKIM, DMARC, MTA-STS and domain-expiry checks for any domain, with SPF lookup counts.
Add one secure layer between your agents and this server.