What MCP is, and why an AI agent needs real network tools
Ask a language model whether a domain's SPF record is valid and it will answer. The answer will be well formatted, technically literate, and describe a record it has never seen. The model has no network access, so it produces the most plausible SPF record for a domain of that shape, which is a different thing from the truth.
The Model Context Protocol exists to close that gap. It is an open standard, published by Anthropic in late 2024 and since adopted well beyond it, for connecting assistants to real tools and real data.
The shape of the protocol
MCP separates three roles.
The host is the application the user interacts with: a desktop assistant, an editor, a coding agent. The host runs one or more clients, and each client maintains a connection to one server. A server exposes some capability: a filesystem, a database, an API, a set of network lookups.
Messages are JSON-RPC 2.0. A client asks a server what it offers, the server returns a list with schemas, and the client can then call any of them with arguments. The model sees the descriptions and schemas and decides what to call.
Two transports are in common use. stdio runs the server as a local subprocess and speaks over standard input and output, which suits anything that needs local machine access. Streamable HTTP connects to a remote server over ordinary HTTPS, which suits a hosted service that many people use without installing anything.
Servers can expose three kinds of thing:
- Tools are actions the model may choose to invoke. This is the part most people mean when they say MCP.
- Resources are data the application can read and place into context, controlled by the app rather than chosen by the model.
- Prompts are reusable templates a user can invoke deliberately.
The distinction matters for safety. Tools are model controlled, so a server that exposes destructive actions is handing the model the ability to take them.
Why network diagnostics are the sharp case
Plenty of tasks tolerate an approximate answer. Network diagnostics do not, for three reasons.
The answer is a fact about right now. What a domain's MX records are, whether a certificate has expired, whether an IP is on a blocklist. These change. There is no correct answer to memorise, only a correct answer to look up.
Training data is stale by construction. Any fact about a live host was true at some point before the model was trained, if it was ever in the data at all. A certificate expiry date from the training set is worse than no answer, because it looks like a real one.
The failure is confident and shaped correctly. A hallucinated SPF record has valid syntax. A hallucinated certificate chain names real certificate authorities. Nothing about the output signals that it was invented, which is precisely what makes it dangerous in a debugging session where you are already unsure what is wrong.
Give the same model a real lookup and the character of the work changes. It can check a claim, notice a mismatch between two records, and follow the evidence. The reasoning was never the weak part. The inputs were.
The toolhq MCP server
toolhq exposes its network tools over Streamable HTTP at:
https://toolhq.io/api/mcp
Eight tools are available:
| Tool | What it does |
|---|---|
dns_lookup | Records for a domain, by type |
dns_propagation | The same query against several public resolvers |
mx_lookup | Mail exchanger records |
reverse_dns | PTR record for an IP address |
ip_lookup | Network and location detail for an address |
ip_reputation | VPN, proxy and hosting classification |
ssl_check | Live certificate and chain for a host |
http_headers | Response headers for a URL |
They are read only lookups against public data. There is no key and no account. Requests are limited to 60 per minute per address, private and local address ranges are refused, and the surface is deliberately small rather than a wrapper around everything on the site. The browser tools, the ones that parse and format data locally, are not exposed here because they do not need a server to run.
Adding it to Claude Code is one command:
claude mcp add --transport http toolhq https://toolhq.io/api/mcp
Other clients take a URL in a configuration file. The MCP page lists the exact form for several of them.
What this looks like in use
The value shows up in multi step problems, where each answer determines the next question.
Take a report that mail to a domain is bouncing. An agent with these tools can look up the MX records, resolve each mail host, check the certificate on the ones that advertise TLS, read the SPF and DMARC records from DNS, and check whether the sending address appears on a blocklist. Each step is a real query, and the conclusion rests on what came back rather than on what a plausible configuration usually looks like.
Without tools, the same model produces a competent description of how to debug the problem, addressed to you, containing no information about your domain.
The same pattern applies to a certificate that works in one place and fails in another, or a DNS change that appears to have taken effect locally and not elsewhere. These are exactly the problems where a single observation point misleads, and where a handful of cheap lookups settles the question.
Being clear about the limits
Three things are worth stating plainly, because agent tooling invites overstatement.
Tool access does not make the model correct. It removes one failure mode. A model can still misread a correct record, or draw a wrong conclusion from accurate data. What changes is that the raw material is now real, so its reasoning can be checked against it.
The lookups are queries, not privacy neutral. Asking about a domain sends that domain to a server, which queries public DNS, blocklists or the host itself. That is inherent to what a network check is. The values are used to make the lookup and are not stored, and this is the same behaviour as the browser versions of these tools, which say so on their own pages.
A small surface is the point. Exposing eight read only lookups is a deliberate choice over exposing everything. Tools are model controlled, so the safest server is one that cannot do much.
Where to start
If you already run an agent, add the endpoint and try it on a domain you know well, so you can check the answers against what you already believe. Discrepancies are informative in both directions.
If you would rather see the same checks by hand first, the browser versions are the same lookups: DNS Lookup, SSL checker, MX lookup and HTTP headers. For the background on what those records mean, DNS records explained and how to read an SSL certificate are the places to start.