MCP Server

Claude Code — Run in your terminal:

claude mcp add --transport http dnsisbeautiful https://dnsisbeautiful.com/api/mcp

Claude (desktop and web) — Settings → Connectors → Add custom connector, then paste the URL:

https://dnsisbeautiful.com/api/mcp

Cursor — Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "dnsisbeautiful": {
      "url": "https://dnsisbeautiful.com/api/mcp"
    }
  }
}

VS Code — Add to .vscode/mcp.json:

{
  "servers": {
    "dnsisbeautiful": {
      "type": "http",
      "url": "https://dnsisbeautiful.com/api/mcp"
    }
  }
}

dns_lookup — DNS lookup

Look up one DNS record type for a name across 38 public resolvers worldwide (Google, Cloudflare, Quad9, regional ISPs) and return each resolver's answer, TTL and response time, plus related records (e.g. AAAA/CAA presence) and typo warnings. Use it to see what a record currently resolves to and whether resolvers agree (propagation). Takes a few seconds.

caa_check — CAA check

Check which certificate authorities may issue TLS certificates for a domain. Walks the CAA tree (the name, then each parent up to the registrable domain) to find the effective CAA record set, summarizes allowed issuers (including wildcard rules) and iodef reporting targets, and flags problems. No CAA records means any CA may issue.

dns_security_scan — DNS security scan

Run a DNS security audit for a domain and return a 0–100 score, a letter grade and per-check pass/warn/fail details. Checks DNSSEC and its algorithm, SPF, DMARC, common DKIM selectors, CAA, dangling CNAMEs, lame delegation, SOA serial consistency, TTLs, nameserver diversity, information leakage and encrypted DNS support. Takes up to ~15 seconds.

nameserver_health — Nameserver & DNSSEC health

Diagnose a zone's delegation and DNSSEC by querying the parent registry and each authoritative nameserver directly. Reports parent vs. zone NS mismatches, missing glue, lame or unreachable servers, SOA serial drift, and the DNSSEC chain (DS at the parent vs. DNSKEY, signature validity), each finding with a suggested fix. Takes up to ~10 seconds.

dns_infrastructure — DNS infrastructure detection

Identify the providers behind a domain from its DNS: DNS host (from NS records), CDN and reverse proxy (from CNAME chains and A records), and email provider (from MX records), each with a confidence level and the record value that matched.

dns_check_rules — Verify expected DNS records

Verify that DNS matches a declaration: entries saying which records should exist (add) and which should not (remove: true). An add is judged by DNS conflict rules for its type: A, AAAA and CNAME must be the only value of their type at the name; an SPF TXT ("v=spf1 …") or DMARC TXT ("v=DMARC1; …" at _dmarc) must be the one policy record there; other TXT and MX values only need to be present beside others. An A or AAAA add fails while a CNAME holds the name; TXT and MX are judged through a CNAME (DKIM and ACME delegation). A removal verifies the value ("*": any record of the type) is gone. A CNAME add at the zone root (the domain, or its registrable domain when domain is omitted) is a root alias (ALIAS/ANAME/flattening): verified when the root's A and AAAA answers are among the target's from the same resolver (no AAAA at the root when the target has none), or exactly the entry's optional fallback addresses. A CNAME removal at the root (with a target, not "*") is a root-alias removal: still present while any root A or AAAA address is among the target's (addresses a root A/AAAA entry in the same declaration adds don't count) or the root holds a CNAME to the target. Each declared name is also checked for a dangling CNAME (one whose target every selected public resolver reports as NXDOMAIN, a subdomain-takeover risk), listed in dangling; names whose entries are all TXT or MX (ACME/DKIM delegations) are not checked. Entries are judged independently against public resolvers and, informationally, the zone's authoritative nameservers. Returns verified: true only when every entry matches on the public resolvers and no declared name holds a dangling CNAME. Up to 20 entries; takes up to ~15 seconds.

global_probe — Global probe

Check a domain from up to 14 probe locations worldwide (North and South America, Europe, Africa, Asia, Australia). kind "dns" resolves its A record via 8.8.8.8 from each region; "http" fetches https://<domain> and reports status, headers and redirects; "tls" reads the certificate on port 443 (issuer, validity, SANs); "full" does all three. Use it to spot geographic differences (GeoDNS, CDN edges, regional outages). Regions run in parallel; expect 5–20 seconds, longer for "full". Sends progress notifications per region when the client provides a progressToken.

traceroute — Traceroute

Run a TCP traceroute (3 probes per hop, up to 25 hops) to a host from up to 14 probe locations worldwide and return the hops with addresses and latencies per region. Use it to diagnose routing, latency or reachability problems toward a server. Each region can take up to 35 seconds; all regions run in parallel, so expect 10–40 seconds. Sends progress notifications per region when the client provides a progressToken.