Debugging DNS, SSL and mail with an AI agent: a worked example

An agent that can run real lookups is more useful than one that can only describe how to debug. This post walks through three realistic questions and shows what the toolhq MCP server actually returns, so you know what the agent is working from. All of the output below was captured on 4 November 2026 against example.com, a domain set aside for documentation. Live values change, so treat the numbers as an illustration of the shape of the data.

Setup

In Claude Code, one command adds the server:

claude mcp add --transport http toolhq https://toolhq.io/api/mcp

Other clients take the same URL in a configuration file, and the MCP page lists the exact form for several of them. There is no key or account. For the background on why this matters, see what MCP is and why an agent needs real network tools.

Question 1: did my DNS change land?

You changed an A record and want to know whether the world can see it. A single lookup from one place cannot answer that, because resolvers cache independently. The right question is whether several unrelated resolvers agree.

A prompt that gets this done:

Check whether the A record for example.com has propagated. Show me what each resolver returned and tell me whether they agree.

The agent calls dns_propagation, which asks Cloudflare, Google, OpenDNS, AdGuard, DNS.SB and AliDNS at once. Trimmed, the answer looks like this:

{
  "domain": "example.com",
  "type": "A",
  "results": [
    { "resolver": "Cloudflare", "records": ["104.20.23.154", "172.66.147.243"], "ms": 65, "status": "ok" },
    { "resolver": "Google",     "records": ["104.20.23.154", "172.66.147.243"], "ms": 58, "status": "ok" },
    { "resolver": "AliDNS",     "records": ["104.20.23.154", "172.66.147.243"], "ms": 148, "status": "ok" }
  ],
  "verdict": "propagated",
  "consistent": true,
  "agreement": { "responded": 6, "total": 6, "distinctAnswers": 1 }
}

Two fields do the work. distinctAnswers: 1 means every resolver returned the same set. If it were 2, some resolvers still held the old value, and the agent can compare the two sets against the record you intended and against the TTL you set. That turns "wait a bit" into "the old value should expire by this time". For planning a change in the first place, DNS TTL: planning a migration and DNS propagation explained are worth reading.

Question 2: is the certificate healthy?

Check the TLS certificate on example.com. Tell me who issued it, when it expires, whether the name matches, and which protocol version it negotiated.

The agent calls ssl_check. The fields that answer that prompt come back as:

{
  "host": "example.com",
  "authorized": true,
  "protocol": "TLSv1.3",
  "hostnameMatch": true,
  "certificate": {
    "subject": "CN=example.com",
    "issuer": "C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3",
    "validTo": "Dec 25 22:56:35 2026 GMT",
    "daysRemaining": 52,
    "subjectAltNames": ["example.com", "*.example.com"]
  }
}

An agent can say something specific and checkable from this: the certificate is trusted, the name matches, it negotiated TLS 1.3, it covers the apex and a wildcard, and it expires in 52 days. That last number is the one worth acting on. A certificate with a few weeks left deserves a look at whether renewal is automatic, which is the subject of monitoring SSL certificate expiry.

Question 3: why is this serving plain HTTP?

Fetch http://example.com and tell me what happens. Does it redirect to HTTPS, and which security headers are set?

The agent calls http_headers. The relevant parts of the reply:

{
  "inputUrl": "http://example.com/",
  "finalUrl": "http://example.com/",
  "status": 200,
  "redirects": [{ "url": "http://example.com/", "status": 200 }],
  "security": [
    { "name": "strict-transport-security", "present": false },
    { "name": "content-security-policy", "present": false },
    { "name": "x-content-type-options", "present": false }
  ]
}

Read carefully, this says three things: the plain HTTP address answers directly with a 200 and no redirect to HTTPS, there is only one request in the chain, and none of the security headers in the list are set. That is a finding, and an agent that quotes these fields gives you something to verify. The same job by hand is the HTTP header checker, and the redirect tracer shows the full chain with timing.

Prompting for evidence, not conclusions

The difference between a useful answer and a confident one is whether the agent shows its work. A few habits help.

• Ask it to quote what it looked up. "Show me the records you checked" makes a wrong conclusion visible, because you can see the data it was based on.
• Ask for the next check, not just the verdict. A good answer ends with what to look at next, such as "the SPF record includes a host that no longer resolves, check that next".
• Cross check across tools. A mail problem is rarely one record. Ask the agent to combine mx_lookup, the TXT records from dns_lookup, and ip_reputation on the sending address before it concludes.
• State what you expected. "I expect this to point at 203.0.113.10" gives the agent something concrete to compare against.

Reading the results critically

An agent with tools is better than one without, not infallible.

• Each result is a snapshot. It describes the moment of the query. A cached resolver or an in flight change can differ a minute later.
• A correct record can still be misread. The data is real, but the model can draw a wrong conclusion from it. This is why quoting the evidence matters.
• The lookups are bounded. Requests are limited to 60 per minute per address, private and local addresses are refused, and only these eight checks are exposed. For anything else, an agent can drive the browser versions you run yourself.

Where to go next

If you want the same checks by hand first, use DNS Lookup, DNS Propagation, the SSL checker and the HTTP header checker. If you are building an MCP server of your own, test it before agents use it. For the wider picture of how the site fits into AI work, see how toolhq helps you work with AI.