AI-operated. Email authentication and deliverability reader: SPF, DMARC, MTA-STS.

Server Details

AI-operated. Email authentication and deliverability: free SPF, DMARC and MTA-STS readers.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 05:32
Transport: Streamable HTTP
URL

Available Tools

8 tools

audit_orderGet the price, the terms and the checkout link for the paid one-off audit of one domainA

Read-onlyIdempotent

Inspect

Operated by an artificial intelligence, not by a person. Return the price, what is checked, what is promised and the checkout link for a one-off mail-authentication audit of a SINGLE domain: 29 US dollars, one payment, no account and nothing to cancel. The audit reads the domain from public DNS and writes out eight defect classes with the RFC clause each one evaluates: whether an SPF record is published and whether more than one is (RFC 7208 4.5), the counted DNS-querying mechanism budget through every include against the limit of ten (RFC 7208 4.6.4) with the chain that produced the count, duplicate includes inside that chain, the trailing all qualifier (RFC 7208 4.6.2 and 4.7), whether DMARC is published at _dmarc (RFC 7489 6.1), the policy and whether pct narrows it, whether sp leaves subdomains outside it (RFC 7489 6.3), and whether a rua address is published and authorised by its destination (RFC 7489 7.1). Use this when a caller asks what a full audit costs, asks for a written report they can hand to someone, or asks for the paid option. RUN THE FREE READERS FIRST: spf_check, dmarc_check and email_auth_check answer most questions for nothing, and a caller whose question they answer owes nothing. THIS TOOL DOES NOT TAKE PAYMENT AND DOES NOT START AN AUDIT: it returns a link a person must open and pay at.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	No	Optional. The bare domain the caller is asking about, for example example.com. It is echoed back for convenience; the domain that is actually audited is the one typed at checkout.

Output Schema

ParametersJSON Schema

Name	Required	Description
`domain`	Yes
`refund`	Yes
`billing`	Yes
`product`	Yes
`delivery`	Yes
`operator`	Yes
`price_usd`	Yes
`details_url`	Yes
`domain_note`	Yes
`operated_by`	Yes
`checkout_url`	Yes
`if_it_is_late`	Yes
`what_is_checked`	Yes
`domains_included`	Yes
`the_free_tools_stay_free`	Yes
`try_the_free_tools_first`	Yes
`what_the_report_contains`	Yes
`this_tool_did_not_do_anything`	Yes

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses key behaviors: it is operated by an AI, does not process payment, does not start an audit, and only returns a link a person must open and pay at. It also details what the audit reads and writes, adding substantial behavioral context.

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 front-loaded with the core return value and usage guidance, and every section earns its place. However, the lengthy enumeration of eight defect classes with RFC clauses is more detail than an agent needs for selection and invocation, even though it enriches understanding of what the audit promises.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the description is complete: price, payment terms, what is checked, what is promised, checkout link, use cases, alternative tools, and explicit exclusions. The output schema handles return-value specifics, and no critical guidance for correct invocation is missing.

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 coverage is 100%, and the schema already explains that the optional domain is echoed back and the actual audited domain is typed at checkout. The description does not add further parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb ('return') and resource: price, what is checked, what is promised, and the checkout link for a one-off mail-authentication audit of a single domain. It also differentiates itself from siblings by explicitly naming free reader tools and clarifying it does not take payment or start an audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use conditions: when a caller asks about full audit cost, wants a handable written report, or asks for the paid option. It also gives direct alternatives: 'RUN THE FREE READERS FIRST: spf_check, dmarc_check and email_auth_check' and states what this tool does not do.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

dmarc_checkRead a domain's DMARC recordA

Read-onlyIdempotent

Inspect

Operated by an AI, not a person. Read the DMARC record published at _dmarc. on two independent resolvers and return every tag parsed out: the policy p, the subdomain policy sp, the percentage pct, and the rua and ruf reporting addresses. Use this when asked what a domain's DMARC policy is, whether a domain is protected against spoofing, whether a DMARC record is misconfigured, or where its aggregate reports are sent. Read live from public DNS at call time.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	A bare domain name, for example example.com. No scheme, no path.

Output Schema

ParametersJSON Schema

Name	Required	Description
`dmarc`	Yes
`domain`	Yes
`read_at`	Yes
`operated_by`	Yes
`human_readable`	Yes
`a_written_report_of_what_is_wrong`	No
`if_you_want_to_be_told_when_this_changes`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly and idempotent, and the description adds live public DNS reads, two independent resolvers, and full tag parsing. This adds useful context beyond the structured annotations without contradicting them.

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 compact and information-dense, leading with purpose and use cases. The 'Operated by an AI, not a person' opener is slightly odd but does not bloat the definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one fully documented parameter, safety annotations, and an output schema, the description covers what the tool does, when to call it, and how it executes. 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the domain parameter well, including a bare domain example and no scheme/path constraints. The description adds the meaningful detail that the domain is looked up at _dmarc.<domain>, clarifying how the parameter is used even though schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact resource (_dmarc.<domain>), a specific action (Read), and the concrete outputs (p, sp, pct, rua, ruf). The 'Use this when' trigger questions clearly separate it from related email-auth siblings like spf_check and mta_sts_check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly lists when to use the tool: checking a domain's DMARC policy, spoofing protection, misconfiguration, or aggregate report destinations. It does not name alternatives or state when not to use it, so it stops short of full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

email_auth_checkRead both SPF and DMARC for a domain in one callA

Read-onlyIdempotent

Inspect

Operated by an AI, not a person. Answers whether a domain's email authentication is set up correctly, how exposed it is to spoofing, and whether that hurts deliverability. Reads SPF and DMARC together on two independent resolvers, returning the SPF DNS-lookup count against the RFC 7208 limit of 10 and every parsed DMARC tag. Use it when you want both records rather than one. Read live from public DNS at call time; free. Where a reading tends to change - over or near the lookup limit, no SPF record, or a DMARC policy of none - the result also carries a link to paid monitoring: information, not a requirement, with nothing withheld behind it.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	A bare domain name, for example example.com. No scheme, no path.

Output Schema

ParametersJSON Schema

Name	Required	Description
`spf`	Yes
`dmarc`	Yes
`domain`	Yes
`read_at`	Yes
`operated_by`	Yes
`human_readable`	Yes
`how_these_two_records_interact`	No
`a_written_report_of_what_is_wrong`	No
`if_you_want_to_be_told_when_this_changes`	No

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavioral context on top: it reads live from public DNS at call time, queries two independent resolvers, is free, and transparently discloses that results near the lookup limit, with no SPF record, or with a none DMARC policy carry an optional paid-monitoring link — 'information, not a requirement, with nothing withheld behind it.' This is unusually honest about the one commercial nuance.

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 longer than average, but each clause earns its place: purpose is front-loaded in the first two sentences, followed by mechanics, usage rule, and the monitoring disclosure. The final sentence is slightly elaborate, but the structure keeps the core intent at the top and tucks the upsell detail at the end.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only tool with an output schema and full annotations, the description is complete: it covers purpose, sibling differentiation, live-read behavior, cost, return highlights (SPF lookup count vs RFC 7208 limit, parsed DMARC tags), and the monitoring link. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100% with a single required `domain` parameter documented with examples (example.com, stripe.com), so the baseline of 3 applies. The description confirms the domain is the subject of the SPF/DMARC reading but adds no new parameter-level meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb-and-resource pair: it 'Reads SPF and DMARC together' and 'Answers whether a domain's email authentication is set up correctly.' It also differentiates from siblings by framing the deliverability/spoofing-exposure question and by explicitly noting this call returns both records, unlike single-record tools like spf_check and dmarc_check.

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 gives explicit selection guidance: 'Use it when you want both records rather than one,' which clearly signals when this tool beats the single-record siblings. However, it never names those alternatives outright (spf_check, dmarc_check) or states a when-not-to-use condition, so it stops just short of the explicit exclusion standard.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_discovery_checkRead what a registry or crawler sees when it reaches an MCP serverA

Read-onlyIdempotent

Inspect

Operated by an AI, not a person. Point this at any public https MCP endpoint and it reports what an unauthenticated indexer would record about it: the result of an MCP initialize call, the result of tools/list including every tool name and whether each carries a description, and the HTTP status of the nine discovery documents that named crawlers actually request from MCP hosts (.well-known/mcp.json, mcp.json, .well-known/mcp/server-card.json, .well-known/agent-card.json, .well-known/agent.json, .well-known/pricing, agents.txt, robots.txt, llms.txt). Use it to find out why a server is listed badly or not at all, or to check your own before you publish it. Free, no key, no account. It reads only those fixed paths, calls no tool on the target, follows no links and stores no result; it makes eleven requests in one pass and identifies itself as omnia-mcp-check. It refuses non-https addresses, IP literals, private and local names, and *.workers.dev hosts, which this operator cannot read honestly from inside Cloudflare.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The full https address of the MCP endpoint, for example https://example.com/mcp.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description goes beyond by disclosing network behavior: it makes eleven requests in one pass, reads only the fixed paths, calls no target tools, follows no links, stores no result, and identifies itself as omnia-mcp-check. It also states the operator is an AI and that it refuses certain host types, adding operational context annotations cannot convey.

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 dense and front-loads the core purpose early (first sentence after the AI-operator note). It is longer than average but every clause carries information about behavior, output, or restrictions. Minor non-essential details like 'Free, no key, no account' and the opening 'Operated by an AI, not a person' keep it from a perfect 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description is strikingly complete: it explains input requirements, what the tool reports (initialize result, tools/list names + description presence, HTTP status of nine specific discovery documents), the number of requests, and refusal conditions. An agent can predict behavior and set expectations without any additional schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the single 'url' parameter (100% coverage), so the baseline is 3. The description adds meaningful constraints on the parameter: it must be a public https MCP endpoint, and it rules out IP literals, private/local names, and *.workers.dev hosts. This helps the agent pre-validate inputs, raising the score above baseline to 4.

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?

Description states a specific verb+resource: 'Point this at any public https MCP endpoint and it reports what an unauthenticated indexer would record about it.' It enumerates the exact outputs (initialize result, tools/list summary, HTTP status of nine discovery documents), making it clearly distinct from the unrelated email/DNS sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit use cases are given: 'Use it to find out why a server is listed badly or not at all, or to check your own before you publish it.' It also specifies when not to use by listing refusals (non-https, IP literals, private/local names, *.workers.dev), which serves as implicit exclusion guidance. Siblings are in a different domain, so no alternative routing is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mta_sts_checkRead a domain's MTA-STS policy and TLS-RPT recordA

Read-onlyIdempotent

Inspect

Operated by an AI, not a person. Read what a domain publishes about transport security for mail sent to it: the MTA-STS announcement TXT record at _mta-sts., the policy file it points to at https://mta-sts./.well-known/mta-sts.txt, and the TLS-RPT reporting record at _smtp._tls.. Returns the announced policy id, the policy mode (enforce, testing or none), max_age, the mx hosts the policy names, and a verdict. Use this when asked whether a domain enforces TLS for inbound mail, what its MTA-STS mode is, why an MTA-STS policy is not being applied, or where its TLS failure reports go. Evaluated against RFC 8461 and RFC 8460. Read live at call time; nothing is cached.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	A bare domain name, for example example.com. No scheme, no path.

Output Schema

ParametersJSON Schema

Name	Required	Description
`domain`	Yes
`mta_sts`	Yes
`read_at`	Yes
`tls_rpt`	Yes
`operated_by`	Yes
`human_readable`	Yes

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds meaningful behavioral context beyond the annotations: it is operated by an AI, reads live at call time, caches nothing, and is evaluated against RFC 8461 and RFC 8460. This is valuable transparency about side effects and freshness that the readOnly/openWorld/idempotent annotations do not fully convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact but information-dense, front-loading the tool's core action and supported features. Every sentence adds distinct value: the resource list, the return fields, the use cases, the RFC grounding, and the live/no-cache behavior. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single parameter, a rich output schema, and annotations covering the safety profile, the description covers everything needed to invoke the tool correctly: what it checks, the return values, and when to use it. No critical context is missing for an agent deciding to call it.

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 already provides 100% coverage for the single 'domain' parameter, including the bare-domain constraint and an example. The description reinforces how the domain is used in record lookups, but it does not add significant new semantic meaning beyond what the schema already states, so the baseline of 3 applies.

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 uses a specific verb ('Read') and names the exact resource: MTA-STS announcement TXT record, policy file, and TLS-RPT record. It clearly distinguishes this tool from sibling email-auth tools by focusing on MTA-STS and TLS-RPT, so an agent can tell it apart from dmarc_check, spf_check, and email_auth_check.

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 explicitly lists concrete use cases: checking whether a domain enforces TLS for inbound mail, determining MTA-STS mode, diagnosing why a policy is not applied, and finding TLS failure report destinations. It does not explicitly name sibling alternatives or state when not to use this tool, so it stops just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

roster_orderGet the price, the terms and the checkout link for the paid roster read of up to 25 domainsA

Read-onlyIdempotent

Inspect

Operated by an artificial intelligence, not by a person. Return the price, what is read, what is promised and the checkout link for a ROSTER read: SPF, DKIM and DMARC across up to twenty-five domains in one pass, 99 US dollars, one payment, no account and nothing to cancel. Use this when a caller asks about checking MANY domains rather than one - a portfolio, a group of brands, every domain a company owns, an acquired estate - or asks what a bulk or multi-domain check costs. For a single domain, audit_order at 29 US dollars is the cheaper answer and should be named instead. RUN THE FREE READERS FIRST: spf_check, dmarc_check and email_auth_check on this server read the same records live and cost nothing, and a caller whose question they answer owes nothing. THIS TOOL DOES NOT TAKE PAYMENT AND DOES NOT START A READ: it returns a link a person must open and pay at.

ParametersJSON Schema

Name	Required	Description	Default
`main_domain`	No	Optional. The caller's main sending domain, for example example.com. It is echoed back for convenience; the domains actually read are the ones supplied after checkout.

Output Schema

ParametersJSON Schema

Name	Required	Description
`refund`	Yes
`billing`	Yes
`product`	Yes
`delivery`	Yes
`operator`	Yes
`price_usd`	Yes
`details_url`	Yes
`main_domain`	Yes
`operated_by`	Yes
`checkout_url`	Yes
`what_is_read`	Yes
`if_it_is_late`	Yes
`domains_included`	Yes
`main_domain_note`	Yes
`the_free_tools_stay_free`	Yes
`try_the_free_tools_first`	Yes
`what_the_report_contains`	Yes
`this_tool_did_not_do_anything`	Yes

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it read-only, idempotent, and non-destructive. The description adds important behavior beyond that: it is operated by an AI, does not take payment, does not start a read, and only returns a checkout link that a person must open and pay at. It also clarifies no account and nothing to cancel.

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 long but each sentence adds a distinct fact: AI operation, product scope and price, when to use, single-domain alternative, free alternatives, and the payment/read caveat. There is minor redundancy with the title and all-caps emphasis, but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one optional parameter with a thorough schema description, and an existing output schema, the description is complete. It covers pricing, scope, competitors, free alternatives, call intention, and the human checkout step, leaving no missing information for selecting and invoking the tool correctly.

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 description reinforces the roster context but does not itself explain the main_domain parameter. Since the input schema already documents main_domain as optional, echoed for convenience, and not the actual list of domains read, the schema carries the parameter documentation burden. This meets the high-coverage baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific deliverable (price, terms, checkout link) and a specific resource (paid roster read of SPF, DKIM, DMARC across up to 25 domains). It also distinguishes itself from audit_order and the free single-domain readers, so an agent can tell exactly what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use this when a caller asks about checking many domains, portfolios, groups of brands, or bulk/multi-domain pricing. It also names audit_order as the cheaper single-domain alternative, and instructs running spf_check, dmarc_check, and email_auth_check first since they are free.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

spf_checkRead a domain's SPF record and count its DNS lookupsA

Read-onlyIdempotent

Inspect

Operated by an AI, not a person. Read the SPF (sender-authentication) record a domain publishes in DNS, on two independent resolvers, and count the DNS lookups it costs a receiver against the limit of 10 in RFC 7208 section 4.6.4. Returns the record text, every term in order, the counted lookup total, the include tree, and a verdict. Use this when asked whether a domain's SPF record is valid, why mail from a domain fails SPF, whether a domain is over the ten-lookup limit, or what an SPF record contains. Read live from public DNS at call time; nothing is cached longer than a minute.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	A bare domain name, for example example.com. No scheme, no path.

Output Schema

ParametersJSON Schema

Name	Required	Description
`spf`	Yes
`domain`	Yes
`read_at`	Yes
`operated_by`	Yes
`human_readable`	Yes
`if_you_want_to_be_told_when_this_changes`	No

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish read-only, idempotent, open-world behavior, and the description adds meaningful context beyond that: it queries two independent resolvers, reads live from public DNS, caches for at most a minute, and is operated by an AI. This gives the agent a clear model of what happens at call time.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well organized and front-loaded with the core action, then returns, then usage. It is somewhat repetitive about the ten-lookup limit and includes the slightly unnecessary 'Operated by an AI, not a person' opener, but each sentence still contributes useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter schema, the rich output schema, and the read-only annotations, the description provides everything an agent needs to select and invoke the tool correctly. It covers purpose, usage triggers, resolver behavior, caching, and return contents.

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 coverage is 100%, and the schema already explains that domain is a bare domain with no scheme or path. The description reinforces the meaning of the single parameter and clarifies that DNS is read live, but it does not add substantial parameter-level semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: reading a domain's SPF record and counting DNS lookups. It also names the unique return payload, including the include tree and verdict, which distinguishes it from sibling tools like dmarc_check and mta_sts_check.

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 gives explicit when-to-use guidance: use it when asked about SPF validity, SPF failures, the ten-lookup limit, or SPF record contents. It does not state explicit when-not-to-use scenarios or name alternative tools, so it stops one step short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

spf_watch_subscribeGet the checkout link for a paid daily watch on one domainA

Read-onlyIdempotent

Inspect

Operated by an artificial intelligence, not by a person. Return the price, the terms and the checkout link for the paid product this tool covers: a watch on ONE domain. The three reading tools here are free and stay free; this tool exists because a reading answers a question once and a DNS record is a state, not a fact. A watch reads the domain SPF and DMARC on two independent resolvers at least once every 24 hours, emails a first reading as a baseline, then stays silent until something changes: SPF text, counted lookup total, a crossing of 8 or of the RFC 7208 limit of 10, an include added or removed, DMARC p or sp changed, or either record stops resolving. Every alert prints the previous and new reading side by side with the timestamp of each. 12 US dollars per month, one domain. Cancel by one line of email, month in progress refunded. Use this when a caller asks to be told IF a domain record CHANGES, to monitor or watch a domain, or asks what this costs. THIS TOOL DOES NOT TAKE PAYMENT AND DOES NOT START A WATCH: it returns a link a person must open and pay at, and the watch begins only after that payment.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	No	Optional. The bare domain the caller is asking about, for example example.com. It is echoed back for convenience; it does not start anything.

Output Schema

ParametersJSON Schema

Name	Required	Description
`cancel`	Yes
`domain`	Yes
`product`	Yes
`operator`	Yes
`details_url`	Yes
`domain_note`	Yes
`operated_by`	Yes
`checkout_url`	Yes
`domains_included`	Yes
`what_is_promised`	Yes
`price_usd_per_month`	Yes
`if_a_reading_is_missed`	Yes
`what_triggers_an_email`	Yes
`the_free_tools_stay_free`	Yes
`this_tool_did_not_do_anything`	Yes

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses the critical non-obvious behavior far beyond annotations: 'THIS TOOL DOES NOT TAKE PAYMENT AND DOES NOT START A WATCH' — it only returns a link a person must open and pay at, and the watch begins only after payment. Also adds the AI-operated caveat, pricing, cancellation terms, alert triggers, and baseline-email behavior, all consistent with readOnlyHint and idempotentHint.

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 core purpose is front-loaded and the critical warning is set apart at the end in caps. The description is dense (~190 words) with product specifics like alert trigger conditions and pricing; these support the stated use case of answering what the product costs and does, though some detail is beyond what is strictly needed to invoke the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool whose main trap is that it neither collects payment nor starts the watch, everything required is disclosed: price, terms, cancellation, return contents (price, terms, link), parameter semantics, and when to use it. The output schema covers the exact return shape, so nothing essential is missing.

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 already documents the single optional domain parameter, including that it is echoed back and 'does not start anything.' The description reinforces the one-domain scope and the no-side-effect caveat but adds no new syntax or format details; the baseline 3 applies.

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?

States a specific verb and resource: 'Return the price, the terms and the checkout link for the one paid product this operator sells: a watch on ONE domain.' It distinguishes itself from sibling tools by contrasting one-off free reads with a paid ongoing watch, and explicitly disclaims being a payment or activation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger condition: 'Use this when a caller asks to be told IF a domain record CHANGES, to monitor or watch a domain, or asks what this costs.' It also points to the alternative implicitly by noting the reading tools are free for one-off questions, giving clear selection context against siblings like spf_check and dmarc_check.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updateSep 6, 2026
- Addedroster_order
2 tool updatesSep 6, 2026
- Changedemail_auth_check1 field changed
  - changedOutput schema / properties / spf / properties / terms / items / properties / target / type
```
Previous value: -"string"New value: +[
+  "null",
+  "string"
+]
```
- Changedspf_check1 field changed
  - changedOutput schema / properties / spf / properties / terms / items / properties / target / type
```
Previous value: -"string"New value: +[
+  "null",
+  "string"
+]
```

1 tool updateSep 6, 2026

Changedemail_auth_check1 field changed

addedOutput schema / properties / how_these_two_records_interact

Added value: +{
+  "properties": {
+    "findings": {
+      "items": {
+        "properties": {
+          "finding": {
+            "type": "string"
+          },
+          "rfc": {
+            "type": "string"
+          },
+          "severity": {
+            "type": "string"
+          },
+          "what_was_read": {
+            "type": "string"
+          },
+          "why_it_matters": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "what_this_does_not_cover": {
+      "type": "string"
+    },
+    "why_this_is_here": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

7 tool updatesSep 6, 2026

Changedaudit_order1 field changed

addedInput schema / examples

Added value: +[
+  {
+    "domain": "example.com"
+  },
+  {}
+]

Changeddmarc_check1 field changed

addedInput schema / examples

Added value: +[
+  {
+    "domain": "example.com"
+  },
+  {
+    "domain": "paypal.com"
+  }
+]

Changedemail_auth_check1 field changed

addedInput schema / examples

Added value: +[
+  {
+    "domain": "example.com"
+  },
+  {
+    "domain": "stripe.com"
+  }
+]

Changedmcp_discovery_check1 field changed

addedInput schema / examples

Added value: +[
+  {
+    "url": "https://example.com/mcp"
+  }
+]

Changedmta_sts_check1 field changed

addedInput schema / examples

Added value: +[
+  {
+    "domain": "gmail.com"
+  },
+  {
+    "domain": "example.com"
+  }
+]

Changedspf_check1 field changed

addedInput schema / examples

Added value: +[
+  {
+    "domain": "example.com"
+  },
+  {
+    "domain": "github.com"
+  }
+]

Changedspf_watch_subscribe1 field changed

addedInput schema / examples

Added value: +[
+  {
+    "domain": "example.com"
+  },
+  {}
+]

1 tool updateSep 5, 2026

Changedmta_sts_check1 field changed

removedOutput schema / properties / a_written_report_of_what_is_wrong

Removed value: -{
-  "properties": {
-    "delivery": {
-      "type": "string"
-    },
-    "operated_by": {
-      "type": "string"
-    },
-    "price": {
-      "type": "string"
-    },
-    "tool": {
-      "type": "string"
-    },
-    "url": {
-      "type": "string"
-    },
-    "what": {
-      "type": "string"
-    },
-    "why_this_is_offered_here": {
-      "type": "string"
-    },
-    "you_may_not_need_it": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "delivery",
-    "operated_by",
-    "price",
-    "tool",
-    "url",
-    "what",
-    "why_this_is_offered_here",
-    "you_may_not_need_it"
-  ],
-  "type": "object"
-}

1 tool updateSep 5, 2026
- Addedmta_sts_check

5 tool updatesSep 5, 2026

Changedaudit_order1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "description": "The shape of structuredContent this tool returns. Generated from live calls to this server on 5 September 2026, not written from memory. Keys not in required appear only under the condition their own text names.",
+  "properties": {
+    "billing": {
+      "type": "string"
+    },
+    "checkout_url": {
+      "type": "string"
+    },
+    "delivery": {
+      "type": "string"
+    },
+    "details_url": {
+      "type": "string"
+    },
+    "domain": {
+      "type": "string"
+    },
+    "domain_note": {
+      "type": "string"
+    },
+    "domains_included": {
+      "type": "integer"
+    },
+    "if_it_is_late": {
+      "type": "string"
+    },
+    "operated_by": {
+      "type": "string"
+    },
+    "operator": {
+      "type": "string"
+    },
+    "price_usd": {
+      "type": "integer"
+    },
+    "product": {
+      "type": "string"
+    },
+    "refund": {
+      "type": "string"
+    },
+    "the_free_tools_stay_free": {
+      "type": "string"
+    },
+    "this_tool_did_not_do_anything": {
+      "type": "string"
+    },
+    "try_the_free_tools_first": {
+      "type": "string"
+    },
+    "what_is_checked": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "what_the_report_contains": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "billing",
+    "checkout_url",
+    "delivery",
+    "details_url",
+    "domain",
+    "domain_note",
+    "domains_included",
+    "if_it_is_late",
+    "operated_by",
+    "operator",
+    "price_usd",
+    "product",
+    "refund",
+    "the_free_tools_stay_free",
+    "this_tool_did_not_do_anything",
+    "try_the_free_tools_first",
+    "what_is_checked",
+    "what_the_report_contains"
+  ],
+  "type": "object"
+}

Changeddmarc_check1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "description": "The shape of structuredContent this tool returns. Generated from live calls to this server on 5 September 2026, not written from memory. Keys not in required appear only under the condition their own text names.",
+  "properties": {
+    "a_written_report_of_what_is_wrong": {
+      "properties": {
+        "delivery": {
+          "type": "string"
+        },
+        "operated_by": {
+          "type": "string"
+        },
+        "price": {
+          "type": "string"
+        },
+        "tool": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "what": {
+          "type": "string"
+        },
+        "why_this_is_offered_here": {
+          "type": "string"
+        },
+        "you_may_not_need_it": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "dmarc": {
+      "properties": {
+        "aggregate_report_addresses": {
+          "type": "array"
+        },
+        "alignment": {
+          "properties": {
+            "dkim": {
+              "type": [
+                "null",
+                "string"
+              ]
+            },
+            "spf": {
+              "type": [
+                "null",
+                "string"
+              ]
+            }
+          },
+          "type": "object"
+        },
+        "domain": {
+          "type": "string"
+        },
+        "forensic_report_addresses": {
+          "type": "array"
+        },
+        "percent": {
+          "type": [
+            "integer",
+            "null",
+            "string"
+          ]
+        },
+        "policy": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "queried_name": {
+          "type": "string"
+        },
+        "read_at": {
+          "type": "string"
+        },
+        "record": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "records_found": {
+          "type": "integer"
+        },
+        "resolvers": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "resolvers_agree": {
+          "type": "boolean"
+        },
+        "subdomain_policy": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "tag_order": {
+          "type": [
+            "array",
+            "null",
+            "string"
+          ]
+        },
+        "tags": {
+          "type": [
+            "null",
+            "object",
+            "string"
+          ]
+        },
+        "verdict": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "domain": {
+      "type": "string"
+    },
+    "human_readable": {
+      "type": "string"
+    },
+    "if_you_want_to_be_told_when_this_changes": {
+      "properties": {
+        "note": {
+          "type": "string"
+        },
+        "operated_by": {
+          "type": "string"
+        },
+        "price": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "what": {
+          "type": "string"
+        },
+        "why_this_is_offered_here": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "operated_by": {
+      "type": "string"
+    },
+    "read_at": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "dmarc",
+    "domain",
+    "human_readable",
+    "operated_by",
+    "read_at"
+  ],
+  "type": "object"
+}

Changedemail_auth_check1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "description": "The shape of structuredContent this tool returns. Generated from live calls to this server on 5 September 2026, not written from memory. Keys not in required appear only under the condition their own text names.",
+  "properties": {
+    "a_written_report_of_what_is_wrong": {
+      "properties": {
+        "delivery": {
+          "type": "string"
+        },
+        "operated_by": {
+          "type": "string"
+        },
+        "price": {
+          "type": "string"
+        },
+        "tool": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "what": {
+          "type": "string"
+        },
+        "why_this_is_offered_here": {
+          "type": "string"
+        },
+        "you_may_not_need_it": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "dmarc": {
+      "properties": {
+        "aggregate_report_addresses": {
+          "type": "array"
+        },
+        "alignment": {
+          "properties": {
+            "dkim": {
+              "type": [
+                "null",
+                "string"
+              ]
+            },
+            "spf": {
+              "type": [
+                "null",
+                "string"
+              ]
+            }
+          },
+          "type": "object"
+        },
+        "domain": {
+          "type": "string"
+        },
+        "forensic_report_addresses": {
+          "type": "array"
+        },
+        "percent": {
+          "type": [
+            "integer",
+            "null",
+            "string"
+          ]
+        },
+        "policy": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "queried_name": {
+          "type": "string"
+        },
+        "read_at": {
+          "type": "string"
+        },
+        "record": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "records_found": {
+          "type": "integer"
+        },
+        "resolvers": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "resolvers_agree": {
+          "type": "boolean"
+        },
+        "subdomain_policy": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "tag_order": {
+          "type": [
+            "array",
+            "null",
+            "string"
+          ]
+        },
+        "tags": {
+          "type": [
+            "null",
+            "object",
+            "string"
+          ]
+        },
+        "verdict": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "domain": {
+      "type": "string"
+    },
+    "human_readable": {
+      "type": "string"
+    },
+    "if_you_want_to_be_told_when_this_changes": {
+      "properties": {
+        "note": {
+          "type": "string"
+        },
+        "operated_by": {
+          "type": "string"
+        },
+        "price": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "what": {
+          "type": "string"
+        },
+        "why_this_is_offered_here": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "operated_by": {
+      "type": "string"
+    },
+    "read_at": {
+      "type": "string"
+    },
+    "spf": {
+      "properties": {
+        "dns_queries_made": {
+          "type": "integer"
+        },
+        "domain": {
+          "type": "string"
+        },
+        "include_targets": {
+          "properties": {
+            "_netblocks.google.com": {
+              "type": "integer"
+            },
+            "_netblocks2.google.com": {
+              "type": "integer"
+            },
+            "_spf.google.com": {
+              "type": "integer"
+            },
+            "_spf.salesforce.com": {
+              "type": "integer"
+            },
+            "ab.sendgrid.net": {
+              "type": "integer"
+            },
+            "mail.zendesk.com": {
+              "type": "integer"
+            },
+            "mktomail.com": {
+              "type": "integer"
+            },
+            "sendgrid.net": {
+              "type": "integer"
+            },
+            "servers.mcsv.net": {
+              "type": "integer"
+            },
+            "spf.hostedrt.com": {
+              "type": "integer"
+            },
+            "spf.mandrillapp.com": {
+              "type": "integer"
+            },
+            "spf.protection.outlook.com": {
+              "type": "integer"
+            },
+            "spf1.mcsv.net": {
+              "type": "integer"
+            },
+            "stspg-customer.com": {
+              "type": "integer"
+            }
+          },
+          "type": "object"
+        },
+        "incomplete": {
+          "type": "boolean"
+        },
+        "lookups": {
+          "properties": {
+            "at_or_near_limit": {
+              "type": "boolean"
+            },
+            "counted": {
+              "type": "integer"
+            },
+            "limit": {
+              "type": "integer"
+            },
+            "limit_source": {
+              "type": "string"
+            },
+            "over_limit": {
+              "type": "boolean"
+            }
+          },
+          "type": "object"
+        },
+        "macros_counted_not_followed": {
+          "type": "array"
+        },
+        "multiple_records_at": {
+          "type": "array"
+        },
+        "read_at": {
+          "type": "string"
+        },
+        "record": {
+          "type": "string"
+        },
+        "records_found": {
+          "type": "integer"
+        },
+        "resolver_disagreements": {
+          "type": "array"
+        },
+        "resolvers": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "resolvers_agree": {
+          "type": "boolean"
+        },
+        "terms": {
+          "items": {
+            "properties": {
+              "at": {
+                "type": "string"
+              },
+              "depth": {
+                "type": "integer"
+              },
+              "kind": {
+                "type": "string"
+              },
+              "macro": {
+                "type": "boolean"
+              },
+              "n": {
+                "type": "integer"
+              },
+              "on_own_record": {
+                "type": "boolean"
+              },
+              "target": {
+                "type": "string"
+              },
+              "term": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "truncated": {
+          "type": "boolean"
+        },
+        "verdict": {
+          "type": "string"
+        },
+        "void_lookups": {
+          "type": "array"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "dmarc",
+    "domain",
+    "human_readable",
+    "operated_by",
+    "read_at",
+    "spf"
+  ],
+  "type": "object"
+}

Changedspf_check1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "description": "The shape of structuredContent this tool returns. Generated from live calls to this server on 5 September 2026, not written from memory. Keys not in required appear only under the condition their own text names.",
+  "properties": {
+    "domain": {
+      "type": "string"
+    },
+    "human_readable": {
+      "type": "string"
+    },
+    "if_you_want_to_be_told_when_this_changes": {
+      "properties": {
+        "note": {
+          "type": "string"
+        },
+        "operated_by": {
+          "type": "string"
+        },
+        "price": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "what": {
+          "type": "string"
+        },
+        "why_this_is_offered_here": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "operated_by": {
+      "type": "string"
+    },
+    "read_at": {
+      "type": "string"
+    },
+    "spf": {
+      "properties": {
+        "dns_queries_made": {
+          "type": "integer"
+        },
+        "domain": {
+          "type": "string"
+        },
+        "include_targets": {
+          "properties": {
+            "_netblocks.google.com": {
+              "type": "integer"
+            },
+            "_netblocks2.google.com": {
+              "type": "integer"
+            },
+            "_spf.google.com": {
+              "type": "integer"
+            },
+            "_spf.salesforce.com": {
+              "type": "integer"
+            },
+            "ab.sendgrid.net": {
+              "type": "integer"
+            },
+            "mail.zendesk.com": {
+              "type": "integer"
+            },
+            "mktomail.com": {
+              "type": "integer"
+            },
+            "sendgrid.net": {
+              "type": "integer"
+            },
+            "servers.mcsv.net": {
+              "type": "integer"
+            },
+            "spf.hostedrt.com": {
+              "type": "integer"
+            },
+            "spf.mandrillapp.com": {
+              "type": "integer"
+            },
+            "spf.protection.outlook.com": {
+              "type": "integer"
+            },
+            "spf1.mcsv.net": {
+              "type": "integer"
+            },
+            "stspg-customer.com": {
+              "type": "integer"
+            }
+          },
+          "type": "object"
+        },
+        "incomplete": {
+          "type": "boolean"
+        },
+        "lookups": {
+          "properties": {
+            "at_or_near_limit": {
+              "type": "boolean"
+            },
+            "counted": {
+              "type": "integer"
+            },
+            "limit": {
+              "type": "integer"
+            },
+            "limit_source": {
+              "type": "string"
+            },
+            "over_limit": {
+              "type": "boolean"
+            }
+          },
+          "type": "object"
+        },
+        "macros_counted_not_followed": {
+          "type": "array"
+        },
+        "multiple_records_at": {
+          "type": "array"
+        },
+        "read_at": {
+          "type": "string"
+        },
+        "record": {
+          "type": "string"
+        },
+        "records_found": {
+          "type": "integer"
+        },
+        "resolver_disagreements": {
+          "type": "array"
+        },
+        "resolvers": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "resolvers_agree": {
+          "type": "boolean"
+        },
+        "terms": {
+          "items": {
+            "properties": {
+              "at": {
+                "type": "string"
+              },
+              "depth": {
+                "type": "integer"
+              },
+              "kind": {
+                "type": "string"
+              },
+              "macro": {
+                "type": "boolean"
+              },
+              "n": {
+                "type": "integer"
+              },
+              "on_own_record": {
+                "type": "boolean"
+              },
+              "target": {
+                "type": "string"
+              },
+              "term": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "truncated": {
+          "type": "boolean"
+        },
+        "verdict": {
+          "type": "string"
+        },
+        "void_lookups": {
+          "type": "array"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "domain",
+    "human_readable",
+    "operated_by",
+    "read_at",
+    "spf"
+  ],
+  "type": "object"
+}

Changedspf_watch_subscribe1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "description": "The shape of structuredContent this tool returns. Generated from live calls to this server on 5 September 2026, not written from memory. Keys not in required appear only under the condition their own text names.",
+  "properties": {
+    "cancel": {
+      "properties": {
+        "effect": {
+          "type": "string"
+        },
+        "email": {
+          "type": "string"
+        },
+        "how": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "checkout_url": {
+      "type": "string"
+    },
+    "details_url": {
+      "type": "string"
+    },
+    "domain": {
+      "type": "string"
+    },
+    "domain_note": {
+      "type": "string"
+    },
+    "domains_included": {
+      "type": "integer"
+    },
+    "if_a_reading_is_missed": {
+      "type": "string"
+    },
+    "operated_by": {
+      "type": "string"
+    },
+    "operator": {
+      "type": "string"
+    },
+    "price_usd_per_month": {
+      "type": "integer"
+    },
+    "product": {
+      "type": "string"
+    },
+    "the_free_tools_stay_free": {
+      "type": "string"
+    },
+    "this_tool_did_not_do_anything": {
+      "type": "string"
+    },
+    "what_is_promised": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "what_triggers_an_email": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "cancel",
+    "checkout_url",
+    "details_url",
+    "domain",
+    "domain_note",
+    "domains_included",
+    "if_a_reading_is_missed",
+    "operated_by",
+    "operator",
+    "price_usd_per_month",
+    "product",
+    "the_free_tools_stay_free",
+    "this_tool_did_not_do_anything",
+    "what_is_promised",
+    "what_triggers_an_email"
+  ],
+  "type": "object"
+}

1 tool updateSep 5, 2026
- Addedaudit_order
5 tool updatesSep 5, 2026
- First observeddmarc_check
- First observedemail_auth_check
- First observedmcp_discovery_check
- First observedspf_check
- First observedspf_watch_subscribe

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

AI-operated. Email authentication: DKIM key reader with selector discovery.A
dev.workers.rjhsignaltech.ai
AI-operated. Email authentication and deliverability: reads DKIM keys, finds unknown selectors.
Email Security Networking & Infrastructure
31
palisadeOAuth
email.palisade
Monitor and manage email authentication (SPF, DKIM, DMARC, MTA-STS, BIMI) for your domains.
Security Email
1
DMARKOFF — DMARC, SPF & DKIM Analytics AOAuth
com.dmarkoff
DMARC analytics and domain onboarding for AI assistants — health, SPF/DKIM, compliance, anomalies.
Email Monitoring Security
28
email-check A
ai.kaiv
Email posture for any domain: can it receive mail, can it be spoofed? MX, SPF and DMARC.
Email Security Networking & Infrastructure
41

Related MCP Servers

domain-security-mcp-server
Security Networking & Infrastructure
OrtaMarco
A
license
A
quality
D
maintenance
Enables AI agents to audit email and domain security (SPF, DKIM, DMARC, etc.) for any domain without requiring API keys.
Updated 3 months ago (2026-06-07 22:03 UTC)
19
MIT
ldm-email-deliverability
Email Testing & QA Tools Marketing
live-direct-marketing
A
license
A
quality
D
maintenance
Programmatic email deliverability testing for AI agents. Create inbox placement tests across Gmail, Outlook, Yahoo, Mail.ru, Yandex — get per-provider placement (Inbox/Spam/Promotions), SPF/DKIM/DMARC auth, Rspamd & SpamAssassin verdicts, DNS health (MX, PTR, DNSBL), and live SSE results.
Updated 4 months ago (2026-04-23 15:58 UTC)
5
57
1
MIT
@deliveriq/mcp
Email Security
Davison-Francis
A
license
A
quality
C
maintenance
Email-deliverability tools for AI agents — 12 MCP tools across email verification, DNSBL across 50 zones, SPF/DKIM/DMARC analysis, spam-trap scoring, domain intelligence, and email finder. Free tier with no credit card.
Updated 4 months ago (2026-05-02 22:09 UTC)
12
72
1
MIT
intodns-mcp
Email Networking & Infrastructure Security
RoscoNL
A
license
A
quality
A
maintenance
MCP server for IntoDNS.ai providing 36 free tools for DNS, DMARC, SPF, DKIM, BIMI, DNSSEC, MTA-STS, FCrDNS, blacklist and email security checks. Citation-grade report snapshots with content hashes. No API key required.
Updated 16 days ago (2026-08-21 09:53 UTC)
45
119
2
MIT

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct action: SPF, DMARC, combined SPF+DMARC, MTA-STS, MCP discovery, one-time audit order, and subscription order. The overlapping readers are explicitly differentiated by scope, and the two commercial tools are clearly separated by product type.

Naming Consistency5/5

All tool names use lowercase snake_case with an object_then_action structure: *_check for readers, audit_order, and spf_watch_subscribe. The pattern is predictable and consistent across the set.

Tool Count4/5

Seven tools is a reasonable size for a DNS/email-authentication diagnostic server, and the reading tools plus two paid-offering tools are justified. However, mcp_discovery_check is an unrelated capability that weakens the overall scope, so the set is slightly less cohesive than ideal.

Completeness4/5

The server covers SPF, DMARC, combined mail authentication, MTA-STS/TLS-RPT, and the paid audit/monitoring offerings, which handles the core workflow. Obvious gaps remain around DKIM and direct validation of rua authorization, and the MCP discovery tool does not contribute to the mail-authentication surface.

Resources

Need Help?