AI-operated. Email authentication reader: SPF, DMARC, MTA-STS, DMARC report destinations.

Server Details

AI-operated. Free SPF, DMARC, MTA-STS and DMARC report-destination (RFC 7489 7.1) 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 07:31
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.6/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that the tool is operated by an AI, reads live public DNS at call time, is free, checks two independent resolvers, and includes contextual paid-monitoring links without withholding results. This is rich behavioral transparency with no contradiction.

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 every sentence contributes: purpose, behavior, usage, and monetization transparency. It is front-loaded with the core value proposition and uses plain language, though it could be slightly tightened.

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

Completeness5/5

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

Given the presence of a rich output schema, complete parameter schema, and strong annotations, the description fully rounds out what an agent needs: what the tool checks, how it behaves, when to choose it over siblings, and what to expect in the response.

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 documents the single parameter fully, including format guidance and an example. The description adds broader context about what the parameter affects but not much beyond the schema, so the baseline score of 3 is appropriate.

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

Purpose5/5

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

The description names a specific verb and resource: it reads both SPF and DMARC together and answers concrete questions about spoofing exposure and deliverability. It also distinguishes itself from siblings like spf_check and dmarc_check by explicitly being the combined version.

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 states when to use the tool: 'Use it when you want both records rather than one.' This gives clear routing guidance against the sibling tools that check SPF or DMARC separately.

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 description goes well beyond the annotations by disclosing live public DNS reads, two independent resolvers, a one-minute cache limit, and the RFC-based lookup counting behavior. The annotations already declare read-only, idempotent, and open-world hints, and the description adds valuable operational detail without contradicting any of 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 front-loaded and information-dense, covering purpose, use cases, return behavior, and execution context. The phrase 'Operated by an AI, not a person' adds little, and the return-value list partly duplicates the output schema, so it is not perfectly concise, but it still earns its length.

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 read-only DNS tool, the description covers purpose, validity rules, return contents, live-data behavior, caching, and use cases. The output schema handles the return structure, so the description is complete for an agent to select and invoke this 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 schema already fully documents the single 'domain' parameter with an example and constraints. The description does not materially expand parameter semantics beyond calling it the domain an SPF record is read from, so the baseline of 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb and resource: 'Read the SPF record a domain publishes in DNS' and 'count the DNS lookups'. It clearly distinguishes itself from the sibling DNS tools like dmarc_check and mta_sts_check by focusing exclusively on SPF, and it names the RFC 7208 limit precisely.

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 concrete triggers: when asked whether an SPF record is valid, why mail fails SPF, whether the ten-lookup limit is exceeded, or what the record contains. It does not name sibling tools as alternatives, but the provided use cases are clear enough to route an agent correctly.

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.8/5.0

Behavior5/5

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

The description discloses substantial behavior beyond the annotations: it is operated by AI, returns a link instead of starting the service, does not take payment, and details the watch cadence, alert triggers, and alert format. It also clearly states refund/cancellation terms. There is no contradiction with the readOnly/idempotent/destructive annotations.

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

Conciseness4/5

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

The description is long but front-loads the core purpose and price, then covers usage and exclusions. It is slightly repetitive—the fact that it does not start a watch appears more than once—but the extra detail is generally purposeful and earns its place.

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

Completeness5/5

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

For a tool with one optional parameter and an output schema, the description is complete: it states what is returned, the cost, the terms, when to use it, what triggers alerts, and what it does not do. An agent has enough context to call this tool correctly and to route user intents appropriately.

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 only parameter at 100% coverage, so a baseline of 3 applies. The description adds value by clarifying the domain is optional, echoed back for convenience, and does not start anything, which prevents the agent from over-interpreting its side effects.

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 and resource: it returns the price, terms, and checkout link for a paid watch on ONE domain. It also explicitly distinguishes what this tool does not do (take payment or start a watch), which removes ambiguity about its role compared to the free reading 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?

The description gives explicit when-to-use guidance: use it when a caller asks to be told if a domain record changes, to monitor or watch a domain, or asks what the paid product costs. It also contrasts this with the free reading tools, implying it is not for one-off checks, which orients the agent toward the correct sibling tool.

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
MailX Email Deliverability A
com.themailx
Check SPF/DKIM/DMARC/BIMI, blacklists, SMTP/IMAP; DNS lookups; generate email DNS records.
Email Security Networking & Infrastructure
163

Related MCP Servers

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
DMARKOFF MCP
Monitoring Security
dmarcoff
F
license
Not graded
quality
D
maintenance
Connects DMARC monitoring data to AI assistants, enabling natural language queries about domain compliance, sender analysis, and email authentication issues.
Updated 17 days ago (2026-08-20 16:45 UTC)
8
-
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
Dechonet MCP
Security Networking & Infrastructure Penetration Testing
node-man
A
license
A
quality
A
maintenance
Domain security reconnaissance for AI agents — 13 tools (DNS+DNSSEC, SSL/TLS, HTTP security headers, SPF/DKIM/DMARC email auth, port scan, ASN, RDAP/WHOIS) plus a one-shot security_scan returning a 0–100 Health Score (A–F). Free, no API key.
Updated 3 months ago (2026-06-17 08:09 UTC)
13
56
1
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 reader targets a distinct DNS record—SPF, DMARC, combined SPF/DMARC, and MTA-STS—while the paid tools are clearly separated into single-domain audit, multi-domain roster, and subscription watch. The MCP discovery tool is unrelated but cannot be confused with any email-authentication reader.

Naming Consistency4/5

Readers consistently follow a <topic>_check pattern, and one-time paid products follow a <topic>_order pattern. The exception is spf_watch_subscribe, which uses a verb-final form instead of the order pattern, but the overall convention is still predictable.

Tool Count4/5

Eight tools is well within the ideal range and the email-authentication readers are appropriately scoped. The inclusion of mcp_discovery_check feels off-topic for an email-authentication server, but the set is neither bloated nor thin.

Completeness3/5

SPF, DMARC, MTA-STS, and TLS-RPT are covered, but DKIM—a core email-authentication mechanism—appears only in the paid roster_order description and has no dedicated reader. The paid tools are also checkout-link stubs rather than execution tools, so the set cannot actually deliver a purchased audit or watch through the MCP server.

Resources

Need Help?