dns-doctor

Build DMARC Upgrade Record

build_dmarc_upgrade

Use this when the user asks how to move DMARC on from p=none, whether it is safe to tighten DMARC, or what the next DMARC policy step is for a domain (a scan can justify quarantine at most; reject needs monitoring evidence) — and after any report showing DMARC below enforcement. Return a validated DMARC enforcement-upgrade record for a domain. A scan can justify p=quarantine at MOST: the alignment signal (valid aligned SPF and a DKIM selector) is derived server-side — a caller can never assert it — and p=reject is unlocked only by aggregate-report evidence over a full reporting window (monitoring), never by a scan. record is null when there is no honest upgrade to offer (the domain does not exist; the DMARC lookup itself hit NXDOMAIN while the existence probe did not resolve; the DMARC lookup temp-failed; no alignment signal was observed at all, so a non-enforcing domain is told to publish rua= reporting first and an enforcing one is left alone; the domain is on Automatic DMARC, where DNS Doctor serves its record and the owner applies each step from the dashboard; or the domain already applies a policy at least as strong as this scan justifies): a null record is the ANSWER, not a fault — relay rationale and never compose a record to fill the gap. A returned record also carries np=reject (the DMARCbis tag covering non-existent subdomains, which can have no legitimate aligned mail) unless the domain already publishes an np tag, which is preserved as-is. Present a returned record verbatim; a human must approve before publishing.

Input Schema

Name	Required	Description	Default
`domain`	Yes	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.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJul 29, 2026

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."

First observedJul 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare the generic safety profile; the description adds the substantive behavior: the alignment signal is derived server-side and cannot be asserted by the caller, np=reject is appended unless already published, and null is a legitimate answer with a full enumeration of null-producing conditions. It also warns against composing a record to fill a gap and mandates verbatim presentation plus human approval.

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?

Usage conditions are front-loaded in the first sentence and every clause carries behavioral information — no filler. It is dense and parenthetical-heavy, running long for a single-parameter tool, which keeps it just short of 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?

An output schema exists, so return-shape explanation is not owed, yet the description still covers the one thing the schema cannot: that null is the answer rather than an error and why. For a single-parameter, evidence-gated tool this leaves nothing an agent needs unanswered.

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?

The single parameter has 100% schema description coverage covering bare names, subdomains, rejected schemes/ports, and punycode normalization, so the schema carries the load. The description adds no domain-format detail beyond the schema, which is the expected baseline of 3.

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 — return a validated DMARC enforcement-upgrade record for a domain — and scopes it against the neighboring build/generate/validate DMARC tools by naming exactly what it produces (an upgrade record justified by evidence). An agent can tell it apart from generate_dmarc_record and validate_dmarc_record from the description alone.

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?

Explicitly enumerates triggering situations ('how to move DMARC on from p=none', 'whether it is safe to tighten', 'what the next policy step is', 'after any report showing DMARC below enforcement') and states the evidentiary ceiling (scan justifies quarantine at most; reject requires monitoring). This is a model of when-to-use guidance.

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.