IntoDNS.ai DNS & Email Security Scanner

Check DNS propagation

check_dns_propagation

Read-onlyIdempotent

Compare DNS responses across the nine currently configured public and authoritative resolvers to detect propagation lag, missing answers, or differing record sets. Each resolver's answer is compared as a whole RRset (order, case of names and trailing dots ignored; TXT case kept; TTLs ignored, as caches count them down). Defaults to record type A and region 'all'. Returns every resolver response, how many resolvers were queried, answered and failed, and percentage = share of the answering resolvers that agree on the most common answer; that is agreement, not coverage, and a failed resolver was not measured. Use when records were just changed and you suspect staleness; for a single DNS-over-HTTPS lookup use lookup_dns instead. Read-only HTTP, no auth, and no destructive actions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "check_dns_propagation"
  }
}

Input Schema

Name	Required	Description	Default
`type`	No	DNS record type to check	A
`domain`	Yes	DNS name, e.g. example.com, _spf.google.com or _dmarc.example.com (no URL, path, or port)
`region`	No	Resolver region	all

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026

changedInput schema / properties / domain / description

Previous value: -"Domain name only, e.g. example.com (no URL, path, or port)"New value: +"DNS name, e.g. example.com, _spf.google.com or _dmarc.example.com (no URL, path, or port)"

First observedAug 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/no-destructive, but the description adds substantial non-obvious context: the exact comparison model (whole RRset, case/trailing dots ignored, TXT case kept, TTLs ignored), the meaning of `percentage` as agreement rather than coverage, and the caveat that failed resolvers were not measured. That last point is a genuine behavioral caveat an agent could otherwise misread.

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?

Dense but front-loaded: purpose and detection targets come first, then comparison semantics, then the return summary, then routing to lookup_dns. The `percentage` explanation is a long clause, but given there is no output schema it carries real weight. Minor redundancy in restating defaults.

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?

With no output schema, the description fully compensates by describing what is returned (every resolver response, queried/answered/failed counts, `percentage`) and flagging the interpretive trap. Nothing an agent needs to call it correctly or interpret results is missing.

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 both enums and the domain format are already documented. The description restates the defaults (type A, region 'all'), which the schema already declares, and adds no new format or constraint detail beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (compare) and resource (DNS responses across nine public and authoritative resolvers) with the outcome it detects (propagation lag, missing answers, differing RRsets). It also names the sibling it is not (lookup_dns for a single DoH lookup), so an agent can route confidently.

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?

Explicit trigger — 'Use when records were just changed and you suspect staleness' — paired with a named alternative and its selecting condition ('for a single DNS-over-HTTPS lookup use lookup_dns instead'). Nothing is left to inference.

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

All IntoDNS.ai DNS & Email Security Scanner 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.