SiteCheck Web Intel

Asks two independent public DNS resolvers for the same name

security_dns_propagation

Read-only

Asks two independent public DNS resolvers (AdGuard DNS and NextDNS) for the same name and record type right now and reports whether they agree, with each answer set and its lowest TTL. It shows cache and geo-DNS differences between resolvers; it is two vantage points, not a worldwide propagation survey. Related tools on this server, for a different need: security_dns_records when you need DNS records of a domain resolved live through the public; security_dns_caa_records when you need to list the CAA records published on a domain: which CAs may. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": {
      "name": "<name>"
    },
    "name": "security_dns_propagation"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Host or domain name, e.g. example.com (required)
`type`	No	A, AAAA, MX, NS, TXT or CNAME (default A)

Output Schema

Name	Required	Description	Default
`name`	No
`type`	No
`agree`	No
`source`	No
`checkedAt`	No
`resolvers`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful disclosure beyond that: it reports each answer set with its lowest TTL, exposes cache and geo-DNS divergence, and states pricing of $0.002 USDC per successful call via x402 with failed calls uncharged. It still omits error behavior, timeouts, and rate limits, so 3 is appropriate.

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 purpose and its limitation are front-loaded in the first two sentences, with alternatives and pricing following in a logical order. There is minor garble in the fragment 'which CAs may' and slightly repetitive framing ('Related tools on this server, for a different need'), but no wasted substantive sentences.

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 is simple (two params, one required), annotations cover the safety profile, and an output schema exists so return values need not be described. The description nonetheless covers scope, limitations, alternatives, and payment mechanics, leaving nothing an agent needs in order to call it correctly.

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 description coverage is 100%, so both 'name' and 'type' are already documented with examples and the allowed record types. The description adds only 'right now,' implying an uncached live query, which is minor meaning beyond the schema. Baseline 3 applies.

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 names a specific action and resource — querying two named public resolvers (AdGuard DNS and NextDNS) for the same name and record type and reporting agreement — and immediately bounds the scope with 'two vantage points, not a worldwide propagation survey.' That scope statement alone separates it from generic DNS lookup siblings.

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?

It explicitly routes the agent to alternatives with conditions: security_dns_records for live DNS records and security_dns_caa_records for CAA records. It also states a when-not implicitly by clarifying this is not a propagation survey, though it never says when a propagation check would be the better choice or when a single-resolver lookup suffices.

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

All SiteCheck Web Intel 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.

Resources

Need Help?