dns-doctor

Check Domain Verification

check_domain_verification

Idempotent

Use this only for DNS Doctor's own ownership TXT challenge on a domain the user already added to their DNS Doctor account (add_monitored_domain). For a TXT record another service asked for (Google Workspace, Microsoft 365, Shopify or any site verification), use check_record instead. Check whether the ownership TXT record for a domain the user has added is visible yet, and mark it verified when it is. The result says WHICH outcome occurred and which nameservers were asked, so you can tell 'not published yet' from 'published with the wrong value' from 'our lookup did not complete' — a lookup that did not complete is TRANSIENT, never a verdict about their DNS. On success the result also carries the DMARC reporting record that turns monitoring on. Print every record host and value EXACTLY as returned — never rewrite, reformat or improve a record string. Nothing here is applied to anyone's DNS: a human publishes every record, and you must show them what you are about to add and get their approval before using any DNS tool of your own. When guidance.note is present, relay it as given: it covers edge cases such as a domain on Automatic DMARC.

Input Schema

Name	Required	Description	Default
`domain`	Yes	The domain, e.g. example.com. For add_monitored_domain: any registrable domain the linked account owns (re-adding one it already monitors returns that row). For check_domain_verification and get_domain_records: a domain this account already monitors, verified or still pending. Any other name — another account's, or one nobody monitors — is refused as not found; ownership is never disclosed.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 16, 2026

changedInput schema / properties / domain / description

Previous value: -"One of the token account's VERIFIED monitored domains, e.g. example.com. Any other name — another account's, or one nobody monitors — is refused as not found; ownership is never disclosed."New value: +"The domain, e.g. example.com. For add_monitored_domain: any registrable domain the linked account owns (re-adding one it already monitors returns that row). For check_domain_verification and get_domain_records: a domain this account already monitors, verified or still pending. Any other name — another account's, or one nobody monitors — is refused as not found; ownership is never disclosed."

AddedSep 16, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false but destructiveHint=false and idempotentHint=true; the description reconciles this by disclosing the mutation is only an internal 'mark it verified' state change and that nothing touches the user's DNS. It also distinguishes transient lookup failures from real verdicts and mandates human approval before any DNS write. Slightly less than perfect only because it doesn't say what happens when verification flips to verified (side effects, monitoring start).

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 when-to-use rule and the alternative, which is the right ordering. The tail of the paragraph (exact record printing, approval workflow, guidance.note relay) is behaviourally load-bearing but dense; a couple of clauses could be tightened without loss.

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 shape needn't be restated, and the description still explains the outcome taxonomy and nameserver attribution an agent must interpret. Combined with the transient-vs-verdict rule and the approval guardrail, nothing needed to call and interpret this tool correctly 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?

Only one parameter at 100% schema coverage, so the schema already carries the 'must be an already-monitored domain' constraint. The description reinforces it in prose ('a domain the user already added to their DNS Doctor account'), adding modest emphasis rather than new syntax.

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 and resource ('check whether the ownership TXT record ... is visible yet, and mark it verified') and immediately scopes it to DNS Doctor's own TXT challenge, differentiating it from check_record and add_monitored_domain by name.

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?

Gives an explicit 'use this only for X' rule plus a named alternative (check_record) with the exact condition that selects it (TXT record requested by Google Workspace, Microsoft 365, Shopify, or any site verification). No inference required.

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.