dns-doctor

Scan Domain

scan_domain

Use this when the user asks to check, audit, diagnose or troubleshoot SPF, DKIM, DMARC, email authentication, email deliverability DNS, why their mail lands in spam, MX, DNS health, blacklist status, or domain/SSL expiry for a domain, or wants to fix what a scan finds (fix records for DMARC and DNS; SPF is diagnose-only) — or whenever a conversation turns to a specific domain's email or DNS setup. It needs the user's real domain: if they have not said which domain, ask them first; never scan a placeholder such as example.com. Force a fresh scan of a domain and return its full report: seven deterministic checks — SPF, DKIM, DMARC, MX, DNS hardening, domain/TLS expiry and blacklist listing — each with a status (pass/warn/fail/info/temperror), the observed record, and a fixengine-generated fix_record where one exists. It also carries sender_requirements: the rules Gmail, Yahoo, Microsoft Outlook and Apple publish for senders, each with what DNS shows (pass, fail or unknown; email_test where only a real message can show it; not_visible where only the provider can), not a compliance verdict. Explanations are cache-first. A repeat scan of the same domain within the dedup window (about a minute) reuses the stored report rather than re-reading DNS, so scanned_at may predate a DNS change you just made — when you are verifying an edit, check scanned_at and call again after the window rather than treating an unchanged report as the new state. Use this when you need current state; use get_report when a recent cached answer will do.

Input Schema

Name	Required	Description	Default
`domain`	Yes	The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJul 29, 2026

addedInput schema / properties / domain / description

Added value: +"The domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode."

First observedJul 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the dedup window, the scanned_at caveat when verifying edits, cache-first explanations, fixengine-generated fix_record behavior, and the status vocabulary used by the report. These details materially affect how an agent should interpret and re-run the scan, and they are consistent with the non-readOnly, non-destructive, open-world 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 important use-case and the distinction from get_report are front-loaded, and nearly every sentence carries operational value. It is dense and somewhat long, but the length is justified by the number of checks, caveats, and delivery rules it needs to convey.

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?

The tool has an output schema, so the description does not need to fully enumerate return values, but it still gives enough context about statuses, fix records, sender_requirements, and caching to set correct expectations. For a one-parameter scan tool with annotations and an output schema, the definition is complete.

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?

Schema coverage is 100%, so the parameter format is already documented. The description still adds useful semantic guidance about the domain value: it must be the user's real domain, placeholders must be avoided, and the agent should ask if the domain has not been stated.

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 verb and resource: force a fresh domain scan and return a full report with seven named checks. It clearly distinguishes this tool from get_report by framing this as current-state scanning versus cached answers, so an agent can identify it without opening the schema.

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

Usage Guidelines5/5

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

It gives explicit triggers such as checking SPF, DKIM, DMARC, MX, DNS health, blacklist status, or expiry, and it names the alternative get_report when a recent cached answer will do. It also specifies the prerequisite that the user must provide a real domain, including asking first and never scanning placeholders.

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

All dns-doctor tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.