--- title: Built for humans and AI agents: now your assistant can investigate, not just read description: An AI model can reason about your website all day. It still has no machine in Singapore — we do. WatchFor now lets an AI agent run live diagnostics (DNS, TLS, headers, ping, Core Web Vitals) from 20 locations in 7 regions, over the REST API, MCP and A2A. canonical: https://watchfor.io/blog/monitoring-for-humans-and-ai-agents --- # Built for humans and AI agents: now your assistant can investigate, not just read 2026-09-07 · WatchFor Team · Monitoring · ai, mcp, monitoring, automation An AI model can reason about your website all day. It still has no machine in Singapore — we do. WatchFor now lets an AI agent run live diagnostics (DNS, TLS, headers, ping, Core Web Vitals) from 20 locations in 7 regions, over the REST API, MCP and A2A. *"My website feels slow in Asia."* Type that to an AI assistant today and it will do its best. It will explain what could cause it, ask you a few clarifying questions, maybe hand you a checklist. What it cannot do is **find out**. The model is running in a data centre somewhere, answering from what it has read. It has no machine in Singapore, no machine in São Paulo, and no way to see your site the way a customer in Jakarta sees it. That is the gap we just closed. We *do* have machines there — 20 locations across 7 world regions — and an AI agent connected to WatchFor can now borrow them. ## Four words in plain English If some of the vocabulary below is new, this is all you need: | Word | What it means | | --- | --- | | **AI agent** | An AI assistant — Claude, ChatGPT, Copilot, Cursor — that can *do* things rather than only talk: it calls software on your behalf and reports back what it found. | | **API** | The way one piece of software asks another for something. Your dashboard is the door for people; the API is the door for programs. | | **MCP** (Model Context Protocol) | An open standard for plugging tools into an AI assistant — think of it as USB for AI. WatchFor runs an *MCP server*; your assistant is the client that plugs into it. | | **A2A** (Agent2Agent) | The same idea one level up: instead of calling tools one at a time, one agent hands another agent a whole task — "diagnose what's broken" — and gets a finished answer back. | Everything else in this post is explained where it first appears. ## The dashboard and the agent get the same product Most monitoring tools grew up human-first: a dashboard, and then an API added later for the handful of things customers asked to automate. That is a perfectly reasonable way to build a product. It just means a program — or an agent acting for you — gets a thinner version than a person does. We took the other rule, and we took it early: **if it is in the dashboard, it is in the API.** The [REST API](/docs/api) is the whole product. The [MCP server](/docs/api/mcp) and the [A2A agent](/docs/api/a2a) are thin layers over that same API — same credentials, same permissions, same per-plan limits, same validation. There is no "agent edition" that lags a release behind, and nothing an agent can do that you cannot do yourself in a browser. Which is the honest framing of this whole post. An agent does not get a special power here. It gets *the same one*. ## Reading is not investigating Up to now, an agent connected to WatchFor could **read**: list your monitors, pull the last check, summarise an incident, tell you last month's uptime. All useful. All about things you had already set up, and all about the past. Three questions it could not answer: - Has our DNS change finished spreading yet? - What does the server actually return, right now, to someone in Frankfurt? - Is port 443 open from Singapore? Those are not reasoning problems. They are *measurement* problems, and the measurement has to happen somewhere real. So we opened the WatchFor **Toolbox** — the same one-off checks you can run by hand from the dashboard and from our [free tools](/free-tools) — to the API, to MCP and to A2A, one for one: - **Name resolution** — a [DNS lookup](/dns-checker) against a specific resolver, and a [DNS propagation check](/dns-propagation-checker) across public resolvers worldwide. - **Reachability** — [ping](/ping-test), [traceroute](/traceroute-online) and a [TCP port check](/port-checker) from the region you pick. - **The web layer** — [HTTP headers](/http-header-checker) and the redirect chain, [CDN behaviour](/cdn-checker), [compression](/brotli-checker), [sitemap validity](/sitemap-checker) and a real [API request](/api-tester) with the response body. - **Certificates and reputation** — an [SSL check](/ssl-checker), a full [TLS grade](/ssl-grade-checker), and [blocklist](/blacklist-checker) status. - **Email** — the SPF, DKIM, DMARC and MX [policy of a domain](/email-policy-checker). - **Experience** — [Core Web Vitals](/core-web-vitals-checker) measured in a real browser, plus a whole-site [audit](/smart-website-audit). - **MCP servers** — the handshake and tool inventory of an [MCP endpoint](/mcp-server-checker), for the growing number of teams who now run one. And a line we drew deliberately: nothing an AI model can already work out on its own. No subnet maths, no timestamp conversion, no uptime percentage calculator. Those exist as [free tools for people](/free-tools) and they always will, but handing them to an agent only spends its attention on arithmetic it is perfectly capable of doing itself. **The value here is the fleet, not the tools.** ## Three conversations This is easier to see than to describe. ### "Customers in Germany say the site is down. It works fine for me." Your agent stops guessing and starts measuring. It fetches your homepage from **Frankfurt** and from **Ashburn, Virginia**, pings the host from both, and looks up your DNS record from a German resolver. Frankfurt returns `403 Forbidden` in 90 milliseconds. Ashburn returns `200 OK`. The host answers ping from both. DNS is identical in both places. What you see is a short answer, not a data dump: *the site is up, but it is being refused for German visitors, quickly and deliberately — that pattern is a firewall or bot-protection rule, not an outage. Here are the two responses side by side.* The agent can still be wrong about the *cause* — a `403` from one region has more than one explanation. What changed is that it is now arguing from measurements taken in Germany instead of from general knowledge about websites. ### "My website feels slow in Asia." The agent runs the timing checks from **Singapore, Tokyo and Mumbai**, then the same page from **Frankfurt** for comparison, then a CDN check and a Core Web Vitals audit in a real browser from Singapore. Time to first byte from Singapore: around 600 milliseconds. From Frankfurt: around 60. The CDN check comes back `MISS` in Asia and `HIT` in Europe — the edge is not serving Asian visitors from a nearby cache. Traceroute shows the path leaving the region entirely. The conclusion writes itself: Asian visitors are being served from Europe, on almost every request, and the largest element on the page is waiting for that round trip. That is a caching and routing problem with a known shape, and now you know it in two minutes rather than after a week of "it feels slow". ### "We moved hosting last night. Did it finish?" First, the thing everyone means by the wrong word. "DNS propagation" is not a wave spreading across the internet — it is thousands of independent resolvers around the world, each still holding your **old** answer until its own timer runs out. (We wrote a whole post on [why that distinction matters](/blog/dns-propagation-myths).) So the agent asks a lot of resolvers at once: 41 of them return the new address, 4 still return the old one. Then it fetches the site from three regions to see which server actually answers, and checks the certificate on the new host. Its answer: *the move is nearly done. The new server is answering and its certificate is valid. Four resolvers are still handing out the old address, so keep the old server running a little longer — one of them has an unusually long cache timer.* That is an operational decision made from evidence, by something that was, an hour ago, an assistant with opinions. ## One call, one verdict An agent that has to choose seven checks, run them one by one and stitch the results together is slow, and every step is a chance to pick the wrong tool. So there is also a single call. Give it a domain and WatchFor runs a sensible bundle — DNS, propagation, TLS, HTTP headers and reachability from up to three regions — and returns one structured verdict instead of seven raw results. This is the piece an agent genuinely cannot assemble for itself, and it is worth being precise about why: not because the logic is hard, but because the logic is useless without machines in the right places. Because it is several probes in one call, each one counts against your allowance. ## Connecting your assistant Skippable if you are not the person who sets these things up — but it really is this short. **Claude, in the browser:** Settings → Connectors → Add custom connector → `https://watchfor.io/api/mcp`. Claude opens a WatchFor consent screen, you approve, and you are done. No key is ever copied anywhere. **Claude Code, or any command-line client:** ```bash claude mcp add --transport http watchfor https://watchfor.io/api/mcp ``` **Cursor, VS Code and other clients that take a JSON config:** ```json { "mcpServers": { "watchfor": { "url": "https://watchfor.io/api/mcp" } } } ``` That is the whole integration. From then on, "check whether our DNS move finished" is a sentence you say, not a tab you open. ### And if you would rather see the plumbing For anyone building their own automation, the same checks are one HTTP request on the [uptime monitoring API](/docs/api): ```bash curl -X POST https://watchfor.io/api/v1/diagnostics/dns-propagation \ -H "Authorization: Bearer wf_live_YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{"target": "example.com"}' ``` ```json { "tool": "dns-propagation", "target": "example.com", "success": true, "location": { "city": "Frankfurt", "country": "DE" }, "result": { "...": "the answers each resolver returned" }, "remaining": 47 } ``` `GET /api/v1/diagnostics` lists every available check, what question it answers, the parameters it takes and how much of your allowance is left — so an agent can discover the catalogue instead of being told about it. ## The version with no account at all Everything above assumes you have a WatchFor account and connect it once. There is also a version that needs neither. **WebMCP** is a way for a website to hand an AI assistant a set of buttons it can press, instead of making it guess from the HTML. watchfor.io registers nine of them the moment a page loads: a site overview, a search across our documentation, read a page, the API quickstart, list the free tools, open one, and start a free website audit. So picture someone browsing with an agent-capable browser who asks, *"what does WatchFor cost, and can it check my SSL certificate?"* Their assistant does not scrape the page and hope. It presses the site's own buttons: it asks for the overview, searches our docs for certificate monitoring, and answers with the plans and the capability. *"Run it on my domain, then"* starts a free [Smart Website Audit](/smart-website-audit) — uptime, SSL/TLS, DNS, security headers and performance in one scan — and puts the browser on the running audit. No key, no signup, no account, and nothing typed into a form. The honest caveat: this only works in browsers that implement the Web Model Context draft, which is still a short list. In every other browser the registration is a silent no-op that costs the page nothing. We shipped it anyway, because it is the same principle as everything else here — make the product operable, rather than making software guess. ## The guardrails, and why they exist Handing live network probes to a program deserves more care than handing it a read-only report, so: - **The same allowance as the dashboard.** A check your agent runs costs exactly what the same check costs when you click it yourself. There is no separate agent pricing and no separate quota to reason about. - **Every response says what is left.** Agents pace themselves well when they are given a budget and badly when they are not, so `remaining` comes back on every single call. - **Public targets only, and a ceiling on breadth.** We refuse private and internal addresses, and we cap how many *different* targets one account can probe in an hour. Someone debugging their own estate touches a handful of hosts; a scanner touches hundreds. Our probes run from a fixed, published set of addresses that thousands of customers rely on — that reputation is part of the product, and we would rather be boring about protecting it. ## What two independent scanners say There are now third-party services that crawl a domain the way an agent would and grade how usable the product is for one. At the time of writing: - **[ora.ai](https://ora.ai/score/watchfor.io)** rates watchfor.io **96/100, grade A+, "Leading"** — with a perfect 100/100 on Integration, Build Quality, Production Readiness, Authentication and Transactions. - **[is-agentic.com](https://is-agentic.com/scan/watchfor.io)** rates it **100/100** — Essential 80/80, Recommended 19.4/20, plus bonus points from 66 positive signals. Both are outside measurements that can move, and both re-scan over time, so treat those numbers as a snapshot rather than a trophy. They also measure how *reachable* a product is for an agent, not whether the product is any good — a distinction worth keeping. We quote them because they are the only independent read on the thing this post is about. If you want the engineering log behind those scores, we wrote [what it actually took](/blog/what-it-took-to-make-monitoring-agent-ready). ## What we are not claiming - **Not a world first.** Other monitoring companies ship MCP servers, some of them well made, and more will. The claim we will defend is narrower and more useful: full parity between the human dashboard and the agent surfaces — including live diagnostics from a global fleet — is still rare. - **Not omniscience.** An agent with these checks can still misread a result or reach for the wrong explanation. It is arguing from measurements now instead of from priors. That is an upgrade, not a diagnosis. - **Not a replacement for monitoring.** Diagnostics answer *"what is true right now, from there."* Knowing at 03:00 that something broke is still the job of a [monitor](/docs/monitors) running around the clock, with confirmed alerting so a single unlucky packet never wakes anyone. ## The bottom line An AI model can reason about your website all day. It can read your code, guess at your architecture and write a very confident paragraph about CDN caching. It still cannot ping Singapore. That part — [20 locations across 7 regions](/docs/reference/probe-locations), running checks every minute of every day — is the part we own, and it is now one sentence away from whatever assistant you already talk to. The same product, for whoever is asking. Related reading: [what it took to make a monitoring platform agent-ready](/blog/what-it-took-to-make-monitoring-agent-ready), [why DNS propagation is a myth](/blog/dns-propagation-myths), and [why checking from many places matters](/blog/global-monitoring-locations). --- Canonical page: https://watchfor.io/blog/monitoring-for-humans-and-ai-agents · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt