Why we built an MCP server for website health data instead of letting agents run the checks themselves

Tom Freeman — Wed, 29 Apr 2026 10:30:20 +0000

One thing we've been asked since we shipped our MCP server: why not just let the LLM do the checks directly? Give Claude a URL, let it fetch the page, parse the headers, run a Lighthouse audit, check the SSL cert. It's capable of all of that. So why build an entire monitoring infrastructure and then layer MCP on top?

The answer comes in two parts, and I think both of them are worth unpacking because they point at something more general about how to think about MCP as an architecture pattern rather than just a convenience wrapper around an API.

A bit of context first

We build and maintain websites. Have done for over 20 years, for clients ranging from sole traders through to the NHS and Aardman. A few years ago we started keeping a closer eye on the sites we were responsible for - uptime, SSL expiry, security headers, PageSpeed scores, that kind of thing. The tools for this were always fragmented. You'd have one tool for uptime, another for performance, something else for security. None of it talked to each other and none of it gave you a timeline.

So we built SiteVitals. It runs nine categories of checks continuously - uptime, SEO, security, performance, SSL and domain expiry, asset integrity, content changes, server metrics, and cron job monitoring - and plots everything on a single unified timeline including your own deployment notes. The idea is that when something goes wrong, you can see what was happening across all dimensions at that moment rather than trying to reconstruct it from memory.

That's the product. The MCP server came later, and the thinking behind it is what I actually want to talk about.

Why letting the LLM run checks itself doesn't work

The obvious alternative to what we've built is: just give the agent a set of tools that let it fetch a page, parse headers, call the PageSpeed API, check WHOIS records, and so on. It can do all of this. Claude is perfectly capable of fetching a URL and telling you whether the X-Content-Type-Options header is set.

The problem isn't capability. It's two things.

The first is cost. We launched at the end of 2025 and currently we're monitoring 449 sites. Each site gets uptime checks every minute, plus regular SEO, security, performance, integrity, content, and server checks. In the last 90 days that's been 5.1 million checks. If you ran each of those checks by asking an LLM to do it, you'd burn through tokens at a rate that would make the economics of a £19/month product completely untenable. Our rules-based engine runs these checks for a fraction of the cost. The LLM never needs to see the raw HTTP response - it just queries the results.

The second is history. This is the more interesting one. An LLM that fetches your site right now knows what your site looks like right now. It has no idea that your PageSpeed score was 91 three weeks ago and is now 74. It doesn't know that the drop happened the day after a WordPress plugin update. It can't tell you that your SSL cert has been renewing successfully for two years and this is the first time it's flagged. All of that context lives in the timeline, and you only have a timeline if something has been watching continuously.

This is the core architectural argument: MCP works best when the LLM is consuming structured, historically-rich data that would be expensive or impossible to generate on the fly. SiteVitals does the continuous observational work. The LLM does the reasoning work. Clean separation, sensible economics.

What we actually built

V1 of our MCP server exposes five tools:

list_sites          - returns all monitored sites with current health scores
get_site_health     - detailed health breakdown for a specific site
get_site_uptime     - uptime history and incident log
get_ssl_domain_status - SSL validity, expiry dates, domain expiry
get_latest_checks   - most recent check results across all categories

We use OAuth 2.1 for auth, scoped read-only to the user's account. The server is registered with Claude via a simple MCP config - users add it to their Claude Desktop settings and from that point they can ask questions like:

"Which of my sites has the worst security score?"
"Is SSL about to expire on any of my domains?"
"What happened to example.com's performance score last week?"
"Which sites have had uptime incidents in the last 30 days?"

And they get answers pulled from real, current, historically-contextualised data rather than a point-in-time fetch.

The implementation detail that surprised us

When we were building this, we assumed the main value would be the query interface - being able to ask natural language questions about site health. And that is valuable. But the thing that's actually most interesting in practice is what happens when you give the LLM access to the timeline data.

A health score of 74 isn't very useful on its own. But when the LLM can see that the score was 91 fourteen days ago, dropped to 83 after a deployment, recovered slightly, then fell again - it can start reasoning about causality rather than just reporting a number. It can correlate the performance drop with a content change logged on the same day. It can flag that the pattern looks like a caching issue rather than a code regression. That's the difference between monitoring and intelligence, and it's only possible because the data has temporal depth.

This is what we mean when we say SiteVitals is the technical backbone. The checks run whether or not anyone is interacting with the AI. The data accumulates. The timeline builds. And when an agent queries it, it's not just getting a snapshot - it's getting a record.

Where this is going

Right now the MCP server is read-only. The agent can tell you what's wrong but it can't do anything about it. That's a deliberate choice for a first iteration - we wanted to get the data layer right before thinking about action.

The next logical step is write access for specific, bounded operations. Things like: acknowledge an alert, add a note to the timeline, trigger a manual check on a specific site. We're being careful about this because the moment you give an agent write access to infrastructure data, you need to think hard about auditability and scope. But it's coming.

The longer play is portfolio management. If you're an agency responsible for 50 client sites, the dream is that an agent can scan the health data across all of them, surface the sites that need attention, and help you prioritise what to fix first. Not autonomously - the human is still making the decisions - but with dramatically better situational awareness than any dashboard can provide.

We're a small team and this is genuinely early days. But we think the pattern is right: rules-based continuous monitoring as the data layer, MCP as the interface for agents to consume it. It's cheaper than letting agents run checks themselves, richer than giving agents raw API access, and it means the intelligence lives in the agent rather than being baked into the monitoring system.

Happy to answer questions on the implementation, the OAuth flow, or anything else. And if you're building in the MCP space - particularly on the data provider side - I'd be interested to hear what patterns you're finding.