Skip to main content
Glama
Sign In
dnsdoctor

DNS Doctor

by dnsdoctor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

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.

Instructions

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

NameRequiredDescriptionDefault
hostNoOptional 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.
kindYesWhich 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.
domainYesThe 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_valueNoOptional: 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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • 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"
+}
  2. Changed3 schema fields changedv1.2.1
    • 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."
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent safety, and the description goes well beyond them: discloses the authoritative-plus-two-resolver sampling, the full verdict vocabulary (done/wait/edit/not_registered/cant_tell), and a sampling caveat that prevents the agent from over-claiming coverage.

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 when-to-use, then dense technical detail. Long but nearly every clause carries operational weight (kind mapping, verdict values, error semantics). Slight redundancy with the schema keeps it off a 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?

No output schema, yet the description fully documents return semantics (verdict states, found_at, not_registered, cant_tell), which is exactly what an agent needs for a lookup tool whose annotations already handle safety.

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%, so the baseline is 3. The description restates kind-derived query names, host applicability, and expected_value behavior — all already documented in the schema — so it adds little beyond the structured fields.

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 (look up) and resource (DNS record) with precise scope: reads from the domain's own nameservers cache-free plus two public caching resolvers. The 'never describe this as worldwide or propagation coverage' line implicitly distinguishes it from a propagation-check sibling.

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?

Clear when-to-use triggers are given (change landed, lookup, verify just-published, or answering needs the live value). No explicit alternative tool name or when-not-to-use exclusion is stated, though the propagation caveat hints at a boundary.

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

Deploy Server

Other Tools