An MCP endpoint for websites: why we're putting one on every site we host
Agents are starting to visit websites, not just people. Why an MCP endpoint for websites matters, what it should expose, and how we're building one.
Someone asks an assistant whether the dental practice down the road is open on Saturdays and takes new patients. The assistant goes to the practice's website, fetches the homepage, follows a link to "Contact", reads past a cookie banner and a navigation menu, and finds the hours in a footer. Then it guesses about new patients, because that's on a different page it didn't open.
That visit was made by an agent, on behalf of a person, and it went badly for everyone. This post is about what we think should replace it, and what we're building. It's a statement of direction. We'll be precise about what's live and what isn't.
The shift
For most of the web's life, a visit meant a person with a browser, or a search engine crawler indexing for later. A growing share of visits are now neither. They're agents fetching a page because someone asked a question, or because someone asked them to do something.
Nobody knows yet how large that share will be for a typical small-business site. It's already visible in server logs, under user agents like ChatGPT-User and Claude-User. The direction is clear even if the size isn't.
What an agent needs from a site
An agent visiting a site on someone's behalf wants three things.
What's here. The pages, the services, the locations, the people. A map, not a maze.
The facts. The opening hours, the prices, the address, whether they take new patients. As values, not as words buried in a paragraph.
Later, the actions. Make an enquiry. Book an appointment. Check availability. Those come later, and they need much more care, but they're where this goes.
Crawling HTML is a poor way to get any of that. The agent has to guess which page holds the answer, strip out the layout and infer meaning from formatting. It gets things wrong, and when it does, it's the site that looks wrong in the answer.
What a site-level MCP endpoint would be
MCP is the protocol agents already use to call tools. What is MCP covers it from the start. An agency connecting Claude or Cursor to Contentive today uses an MCP server to build and manage sites. That one is private, authenticated and able to change the site.
A site-level endpoint would be something different: a public MCP endpoint on the client's own website, for any visiting agent. We think it should have four properties.
Anonymous. No sign-in, no key. An agent visiting the dentist's site shouldn't need an account any more than a person does.
Read-only. It answers questions. It changes nothing.
Generated from the site's own content types. If the site has locations, there's a tool to list locations. If it has services, a tool to list services. There'd be a search tool and a tool to get a page. Nobody would write these by hand, because the content model already says what the site contains. That's the same idea that drives our generated GraphQL API.
Discoverable. An agent arriving at the site should be able to find out that the endpoint exists, from a file at a predictable address, without guessing.
What it must never do
The rules here matter more than the features.
It must never expose drafts. It must never expose member-only content, or anything a logged-out person couldn't see in a browser. It must never accept a write of any kind. If actions come, they should belong to the apps that own them, such as bookings, with their own checks, not be bolted onto a read-only endpoint.
The endpoint should serve exactly what the public website serves, in a form an agent can use. Nothing more. The same principle runs through how we built the private agent surface, described in building a CMS an AI agent can actually drive.
What's live today, and what isn't
Live today, on every site we host: a robots.txt with an AI-crawler policy, where search and user-triggered agents are allowed, training crawlers are blocked by default and a blocked crawler is refused at the edge. A Content-Signal line stating how the content may be used. A sitemap.xml, an llms.txt and an llms-full.txt, all generated from published content, with member-only pages left out. What an AI-ready website actually means covers each one.
Not live: the public MCP endpoint described in this post, and the discovery file that would announce it. We're building them. We're not putting a date on it.
The cost, and the open question
The honest open question is demand. Nobody knows how much agent traffic a site-level endpoint will carry, or how quickly assistants will learn to look for one. It may become the normal way agents read sites. It may stay a niche that a few clients use. We think the bet is cheap because the endpoint is generated from content that already exists, but cheap isn't free: every public surface has to be secured, rate-limited and kept honest.
There's also a cost for clients. A clean, machine-readable view of their facts makes them easier to quote without a visit. For most small businesses that's what they want. For some it isn't, and the policy should be theirs to set.
What to ask any platform
Whoever hosts your client sites, ask them four questions. What do agents see when they visit today? Is any of it generated from content, or does it rely on someone maintaining it? Can drafts or member-only pages ever leak into a machine-readable view? And who decides the policy, you, the client or the platform? The answers will tell you more than any announcement.