dns-doctor

Look Up DNS Record

check_record

Read-onlyIdempotent

Use this when the user asks whether a DNS change has landed, wants a DNS record looked up, or wants to verify a record they just published — or whenever answering needs the live value of a record. Reads the record from the domain's OWN nameservers (cache-free) and from two public caching resolvers. kind is one of spf|dmarc|txt|mx|cname|a|aaaa — pass the kind, not a query name: dmarc reads TXT at _dmarc. and spf reads apex TXT, each filtered to the matching record. host prepends a label (txt, cname, a and aaaa only). Pass expected_value when checking an edit. Relay verdict: done (the nameservers serve it and both caches agree), wait (served, caches catching up — check again after check_again_after_seconds), edit (the domain's nameservers do not serve it; found_at names where the value was seen instead, if anywhere). not_registered: true means the domain does not exist (usually a typo). An error starting cant_tell is a lookup fault, never evidence the record is missing. Two resolvers is the whole sample, so never describe this as worldwide or as propagation coverage.

Input Schema

Name	Required	Description
`host`	No	Optional label to prepend to the domain (e.g. 'mail' to check mail.<domain>) — honored for txt, cname, a and aaaa only; spf, dmarc and mx derive their own query name.
`kind`	Yes	Which record to read; the right query is derived from it — 'dmarc' reads TXT at _dmarc.<domain> filtered to v=DMARC1, 'spf' reads the apex TXT filtered to v=spf1, so don't prefix the domain yourself.
`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.
`expected_value`	No	Optional: the exact value just published (e.g. the DMARC record text, a verification token, '10 mx.example.com'). Given it, the verdict tests for that value and an 'edit' also checks the names a misplaced edit usually lands on (found_at).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / expected_value

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 1024,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional: the exact value just published (e.g. the DMARC record text, a verification token, '10 mx.example.com'). Given it, the verdict tests for that value and an 'edit' also checks the names a misplaced edit usually lands on (found_at).",
+  "title": "Expected Value"
+}

Changed3 schema fields 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."

addedInput schema / properties / host / description

Added value: +"Optional label to prepend to the domain (e.g. 'mail' to check mail.<domain>) — honored for txt, cname, a and aaaa only; spf, dmarc and mx derive their own query name."

addedInput schema / properties / kind / description

Added value: +"Which record to read; the right query is derived from it — 'dmarc' reads TXT at _dmarc.<domain> filtered to v=DMARC1, 'spf' reads the apex TXT filtered to v=spf1, so don't prefix the domain yourself."

Changed1 schema field changedJul 27, 2026

addedInput schema / properties / kind / enum

Added value: +[
+  "spf",
+  "dmarc",
+  "txt",
+  "mx",
+  "cname",
+  "a",
+  "aaaa"
+]

AddedJul 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, but the description goes well beyond them: it discloses that lookups are cache-free, enumerates the full verdict vocabulary (done/wait/edit/not_registered), explains what not_registered and cant_tell mean, and warns that two resolvers is the entire sample. This is exactly the behavioral context an agent needs.

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?

Front-loaded with the use-when trigger and information-dense throughout, with each clause carrying distinct guidance. It is on the long side and a few clauses could be tightened, but there is little genuine 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?

An output schema exists so return values need not be restated, yet the description still covers the pieces an agent must interpret: verdict semantics, not_registered, found_at, and cant_tell as a fault rather than absence. Nothing essential to calling or interpreting the tool 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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning beyond the schema: it stresses passing `kind` rather than a query name, notes that dmarc/spf derive their own query name and must not be prefixed, and ties `expected_value` to the edit/found_at behavior.

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 (read/look up) and resource (a DNS record), plus the mechanism that defines it: reading from the domain's own nameservers cache-free and two public resolvers. This distinguishes it clearly from siblings like check_propagation, get_domain_records, and validate_dmarc_record.

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?

Explicitly names when to use it (verifying a change landed, looking up a record, verifying a just-published record, or whenever the live value is needed), and adds a negative scope note that it is not worldwide propagation coverage. Alternative routing to check_again_after_seconds is implied via the 'wait' verdict.

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.