Skip to main content
Glama

AI-operated. Email authentication reader: six free tools, no key, no signup.

by dev.workers.rjhsignaltech.ai

Get the price, the terms and the checkout link for the paid roster read of up to 25 domains

roster_order
Read-onlyIdempotent

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: the six free readers here - spf_check, dmarc_check, email_auth_check, mta_sts_check, dmarc_report_destination_check and mcp_discovery_check - 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
main_domainNoOptional. 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

TableJSON Schema
NameRequiredDescriptionDefault
refundYes
billingYes
productYes
deliveryYes
operatorYes
price_usdYes
details_urlYes
main_domainYes
operated_byYes
checkout_urlYes
what_is_readYes
if_it_is_lateYes
domains_includedYes
main_domain_noteYes
the_free_tools_stay_freeYes
try_the_free_tools_firstYes
what_the_report_containsYes
this_tool_did_not_do_anythingYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark the tool readOnly, idempotent, and non-destructive. The description adds substantial behavioral context beyond that: it is AI-operated, does not take payment, does not start a read, and returns a link a human must open and pay at. Pricing and non-committal terms are also disclosed. No contradiction with annotations.

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

Conciseness4/5

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

The description is longer than average but every sentence carries routing or behavioral information that an agent needs. It front-loads the core return value and then covers alternatives, pricing, and exclusions. Slightly dense, but not wasteful.

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 an output schema exists and annotations cover safety, the description is complete for correct invocation: it explains purpose, scope, price, terms, alternatives, and that no read or payment occurs at this step. Nothing material is missing for an agent to decide when and how to call this tool.

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 single optional parameter already has 100% schema description coverage. The description adds valuable nuance by stating the domain is only echoed back for convenience and is not used to determine which domains get read, clarifying an otherwise potentially confusing parameter.

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

Purpose5/5

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

The description clearly states the tool returns the price, read scope, terms, and checkout link for a paid ROSTER read of up to 25 domains. It explicitly disambiguates this from actually running a read and from single-domain audit_order, making its function unmistakable even without opening the schema.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: callers asking about MANY domains, portfolios, groups of brands, or bulk/multi-domain costs. It also names the alternative audit_order for single domains and instructs to run the six free readers first, providing clear routing against every sibling.

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

All AI-operated. Email authentication reader: six free tools, no key, no signup. toolsInspect
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