Live DNS: dig any public resolver, audit a domain, walk a delegation, read the resolver board.
Score is being calculated.
The five-check DNS audit for a domain: parent and child nameservers agree, no open recursion, DNSSEC chain, TTL sanity, mail posture. A 0 to 100 score with a grade and each check explained.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The domain to audit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already convey read-only, idempotent, non-destructive behavior, so the description does not need to repeat those. It adds value beyond the annotations by specifying the output shape (0-100 score, grade, per-check explanation) and the behavioral scope of the audit, giving the agent a clear picture of what will happen when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and immediately starts with the tool's purpose and the full list of checks. Every sentence adds useful information, and the output format is clearly front-loaded. There is no fluff, repetition, or cryptic wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main inputs and outputs: it enumerates the checks and explicitly states scoring and grading. Given there is no output schema, mentioning score/grade/explanation is essential and present. It could have gone a little further on error conditions or input validation, but for a single-parameter read-only tool with this richness of description it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'name' parameter is clearly described as 'The domain to audit' in the schema. The description's mention of DNS checks adds some context to what the parameter will be used for, but it does not add meaning materially beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('audit') with the resource ('domain') and enumerates exactly five checks, giving a precise scope. It differentiates the tool from sibling tools like dig or trace by explaining it produces an aggregate score and grade rather than a raw DNS query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is a comprehensive DNS health audit by listing the five check categories, so an agent can infer when it would be used over a single-purpose tool. However, it does not explicitly state when-not-to-use it, name alternative tools, or mention scenarios where a simpler tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a public DNS resolver, or any public address, for a record, live, from the isitdns seat. Returns the answer, the flags, the rcode, Extended DNS Errors and the latency in the shape dig prints, plus the JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| cd | No | Checking disabled: ask the resolver not to validate | |
| ecs | No | EDNS Client Subnet in CIDR form, e.g. 192.0.2.0/24 | |
| name | Yes | The name to ask for, e.g. example.com or _dmarc.example.com | |
| nsid | No | Request NSID (RFC 5001) | |
| type | No | Record type: A, AAAA, MX, TXT, NS, SOA, CNAME, DS, DNSKEY, CAA, SRV, HTTPS, SVCB, PTR, or TYPE<n> | A |
| norec | No | Clear RD, like dig +norec, when asking an authoritative server directly | |
| dnssec | No | Set the DO bit and read AD | |
| family | No | Which address family to dial the resolver on | v4 |
| resolver | No | A board resolver id (cloudflare, google, quad9, opendns, adguard, cleanbrowsing, controld, quad9-unfiltered, adguard-family, cleanbrowsing-family, adguard-unfiltered, opendns-familyshield, nextdns, cloudflare-malware, cloudflare-family, mullvad-base, dns4eu-protective), a registry alias such as 8.8.8.8 or dns.google, "all" for every public resolver side by side, or any public IP address | cloudflare |
| transport | No | DoH (RFC 8484 wire format), DoT on 853, or Do53 over TCP | doh |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds value by disclosing the exact output components – answer, flags, rcode, Extended DNS Errors, latency, dig-style text, and JSON – which is especially useful given there is no output schema. There is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence front-loads the action and then lists the return payload, with no redundant or filler phrases. It is dense without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully documented parameters, robust safety annotations, and an output-shape summary together make the tool easy to invoke correctly. The absence of an output schema is compensated by the description's explicit mention of the dig-style response plus JSON, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each of the 10 parameters has descriptive text with defaults, enums, and examples, so the schema carries the semantic load. The description adds no parameter-level meaning beyond what the schema already provides, which is acceptable at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Ask ... for a record') on a specific resource (a public DNS resolver or any public address), and the output description ('in the shape dig prints, plus the JSON') clearly differentiates it from sibling tools like check_domain or dns_events. It is not a tautology and leaves no ambiguity about what operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'live, from the isitdns seat' implies this tool is for current DNS lookups, but the description never explicitly says when to prefer it over sibling tools or when not to use it. No alternatives are named, so the agent must infer use cases from the schema and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Days when several resolvers were unhealthy at once, as episodes: when each began, how long it ran, how many resolvers were affected at the peak, and which. This is the tool for "was there a DNS outage recently".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful detail about the episode-based aggregation, including temporal and impact fields. It does not mention time-range limits or ordering, but these are minor gaps for a zero-parameter read-only feed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences contain no filler. The first sentence front-loads the data model, and the second states the intended user question.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only feed, the description adequately explains the output structure and the intended use case. It could add explicit time-range or ordering details, but the description is otherwise sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%, so the description has no input semantics to document. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning DNS outage episodes with start time, duration, peak affected resolver count, and affected resolvers. It also explicitly positions itself as the answer to 'was there a DNS outage recently', distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear, concrete usage context: 'This is the tool for "was there a DNS outage recently".' It does not explicitly enumerate when to use alternatives, but the intended use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The RFC 8509 root key sentinel across the public resolvers: which resolvers trust which root KSK, and the root DNSKEY set as read now.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, openWorld, idempotent). The description adds useful context by specifying the scope 'across public resolvers' and the temporal qualifier 'as read now', suggesting a point-in-time snapshot. However, it does not disclose whether the data is cached, how recent it is, or what 'sentinel' means operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and fairly compact. It front-loads the domain and immediately specifies the data composition, though the phrasing is slightly dense and could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only board, the description names the main content but leaves out response format and how to interpret the 'sentinel' concept. Since there is no output schema, a bit more detail would make the tool more self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema requires no additional explanation. The baseline of 4 applies because there is no parameter semantic burden to address.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's domain (RFC 8509 root key sentinel across public resolvers) and enumerates the two data elements it exposes: resolver trust per root KSK and the root DNSKEY set. It is noun-heavy and lacks an explicit verb, but the content is specific enough to distinguish it from sibling tools like resolver_status or dig.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as resolver_status, dig, or dns_events. There are no criteria, prerequisites, or exclusions stated, leaving the agent to infer the appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The incident record for the public resolvers: start time, duration and severity of each. Notable incidents by default; all=true includes short degradations. Windows where several operators failed at once are excluded as our own seat's path, and the answer says how many.
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Include short degraded runs, not only notable incidents | |
| resolver | No | Limit to one resolver id; omit for all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: windows where several operators failed at once are excluded, and the answer includes a count. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste. The core purpose is front-loaded, and the behavioral caveats are stated efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 100% schema coverage and no output schema, the description covers the key behavioral details: default filtering, the all flag, exclusions, and the count in the answer. It doesn't describe the exact response format, but that's not required without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (all and resolver). The description adds context for 'all' (include short degraded runs) but doesn't add meaning beyond the schema for 'resolver'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns incident history for public resolvers, with start time, duration, and severity. It distinguishes itself from siblings by focusing on historical incident records rather than current status or DNS lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (for incident history) and notes the default behavior (notable incidents) plus the all=true option for short degradations. It doesn't explicitly name alternatives, but the sibling list makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The live board: is public DNS OK right now? Every public resolver isitdns watches, its latest reading (status, latency, DNSSEC), read every 3 minutes over DoT, with the time it was read. Give a resolver to get one card.
| Name | Required | Description | Default |
|---|---|---|---|
| resolver | No | One resolver by id (cloudflare, google, quad9, opendns, adguard, cleanbrowsing, controld, quad9-unfiltered, adguard-family, cleanbrowsing-family, adguard-unfiltered, opendns-familyshield, nextdns, cloudflare-malware, cloudflare-family, mullvad-base, dns4eu-protective), alias or address; omit for the whole board |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, open-world, and non-destructive, so the description only needs to add behavioral context. It adds that data is polled every 3 minutes over DoT and that each card carries the time it was read, which helps an agent understand freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler; the purpose is front-loaded and the useful caveat (optional resolver gives one card) is in the second sentence. Every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter read tool with no output schema, the description tells an agent what data to expect (status, latency, DNSSEC, read time), how fresh it is, and how to scope it. Nothing essential for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is already well-documented with accepted resolver ids, aliases, addresses, and the omit-for-whole-board behavior. The description adds only the 'one card' consequence of passing a resolver, which is minor added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'live board' and the question 'is public DNS OK right now?', naming a specific resource (public resolvers watched by isitdns) and the data returned (status, latency, DNSSEC, read time). The phrase 'live' differentiates it from the sibling resolver_history without needing any schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly frames when the tool is appropriate: for current resolver health, with freshness signaled by 'right now' and 'every 3 minutes.' It does not explicitly name a sibling alternative like resolver_history for historical queries, but the live-vs-history context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The DNS health of the top 100 domains as of the last DAILY snapshot: rcode, addresses, DNSSEC, nameservers and rank movement for each. One probe per day at 11:11:11 UTC, so this board does not move intraday. Ask for one domain to get its row, or omit to get the board and its summary. To check any domain right now rather than as of the snapshot, use check_domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | One domain to read from the board, e.g. github.com; omit for all 100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: the daily snapshot cadence, the exact probe time (11:11:11 UTC), and the fact that the board does not move intraday. It does not detail the output structure, but the listed fields and summary mention cover the main behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with no filler. The core purpose is front-loaded, snapshot behavior is explained, invocation is described, and the alternative tool is named at the end. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, strong read-only/idempotent annotations, and no output schema, the description is complete. It explains the data scope, the temporal snapshot semantics, how to request a subset, and when to use a different tool. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single optional domain parameter at 100% coverage. The description reinforces the same semantics by saying to ask for one domain to get its row or omit it for the board, but it does not add meaningfully new parameter details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: it provides DNS health data for the top 100 domains from a daily snapshot, listing the exact fields (rcode, addresses, DNSSEC, nameservers, rank movement). It also distinguishes itself from the real-time sibling check_domain, so an agent can select it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool versus the alternative: use check_domain for a current check, and top_domains for snapshot-based data. It also gives practical invocation guidance: provide a domain for a single row, or omit it for the full board and summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Walk the delegation from the root servers down to the authoritative server for a name, like dig +trace, and say in plain steps whether the delegation is healthy.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name to walk | |
| type | No | Record type for the final question | A |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool produces a step-by-step health assessment, but it does not disclose potential network dependence, partial results, or failure behavior. This is acceptable but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that front-loads the core action ('walk the delegation from the root servers down'), gives a helpful analogy, and specifies the expected output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is sufficiently complete for a read-only trace tool: it names the traversal path, the analogous command, and the output style. Annotations cover safety (readOnly, idempotent, non-destructive). Without an output schema, it could be slightly more explicit about the exact form of the health verdict, but the existing description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 mentions walking 'for a name', reinforcing the name parameter, but adds no new meaning for the 'type' parameter or any additional format/constraints. The schema already carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('walk') and a precise resource ('delegation from the root servers down to the authoritative server'), and immediately orients the agent with the dig +trace analogy. It also states the outcome ('say in plain steps whether the delegation is healthy'), which distinguishes it from a raw dig or a basic domain check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case—tracing and assessing delegation health for a name—but does not explicitly state when to choose it over alternatives like dig or check_domain, nor does it mention exclusions. The 'like dig +trace' analogy provides some context, but no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_domaindigdns_eventsksk_boardresolver_historyresolver_statustop_domainstraceLook up DNS information for any domain to troubleshoot issues and gather insights. Get fast, relia…
Live DNS lookups for agents: A/MX/TXT/SPF/CNAME/PTR with TTLs and DNSSEC, via Google Public DNS.
Signed internet telemetry, read-only: DNS, TLS, WHOIS, reachability. Every record Ed25519-signed.
Live DNS, email-auth and redirect checks, HTTP security headers, uptime history, PC hardware prices.
