Two of forty UK business sites ship an agent endpoint. Neither owner put it there.

The numbers

Of the five real llms.txt files, four were produced by software — two by the website platform itself, one by a well-known WordPress SEO plugin, one by a WordPress plugin most people have never heard of. Exactly one was written by a person, and that one, the best of the five as a document, declares nothing an agent can call. The two endpoints belong to the two platform-generated files.

Method, and what we deliberately did not do

• For each of the 40 sites: fetch the origin's /llms.txt, and reject any 200 whose body is HTML rather than text. Two sites answer 200 with a web page; they are counted as having no llms.txt.
• Where a file declared an endpoint, we sent exactly one JSON-RPC tools/list call to it. That is the read-only enumeration call: it asks the endpoint what it offers and changes nothing.
• No tool was ever called on either endpoint. We did not book, submit, query business data, execute any API or generate any token. The finding is what these endpoints advertise, not what they can be made to do.
• Businesses are identified here by city and vertical only, exactly as in the survey. The platform is named, because the platform's behaviour is the subject, it is the same on both sites, and it is publicly documented in the file the platform itself publishes.
• Measured 2 August 2026. Platforms ship changes; this is a reading on one day and nothing here is a permanent fact about anyone's website.

What the two endpoints are

A dental practice in Newcastle and a driving school in Coventry, unconnected businesses in different verticals and different parts of the country. Both run on Wix. Both serve a real llms.txt with a section headed "AI Agent Access", which states that the site is powered by Wix and supports the Model Context Protocol for agentic AI access, and which links a site MCP endpoint at /_api/mcp on the business's own domain.

Both endpoints answer. Both return HTTP 200 to a tools/list call, and both return the same nine tools, in the same order, with the same descriptions. The set does not vary by business and does not vary by vertical. That is the finding: it is a platform fixture. Neither of these businesses decided that AI agents mattered, chose a tool set, or configured anything. They bought a website, and at some point a live agent endpoint appeared on their domain.

We know of no way for either owner to have discovered this short of reading their own llms.txt, which is not a file anyone has a habit of reading.

The nine tools

Identical on both endpoints. Grouped by what they are for, rather than in the order served.

Eighteen tool slots across two live endpoints. There is no book tool, no quote tool, no request tool, no appointment tool, no lead tool, no order tool and no contact tool on either. Six of the nine are documentation and API tooling for developers building on the platform, which is a curious thing to serve from a driving school's domain.

The qualifier, because it cuts against us

Two of the nine are not narrow tools at all. CallWixSiteAPI and ExecuteWixAPI are generic API-execution tools — hand them a platform API call and they run it. That is an escape hatch, and an honest reading of the table has to account for it.

It gets sharper than that. CallWixSiteAPI's own description says it is for performing an action on a visitor's behalf, and the example it gives is querying the site's data or booking an appointment. So the platform's documentation for its own generic tool names the transactional case out loud. A capable agent, with the right API knowledge and a site that had bookings enabled, could in principle route a real booking through it.

We did not try, and we are not going to write "zero transactional capability" when a tool describes booking an appointment in its own text. What we will say is that this is a different object from a business publishing a request endpoint. An escape hatch is a generic capability aimed at developers, undocumented from the owner's side, with no held-for-approval step, no notification to the owner, and no defined shape for what a request even is. A business that has decided to take requests from assistants and one that happens to sit behind a general-purpose API tool are not the same thing. But an escape hatch is not nothing, and anyone claiming otherwise is overselling.

A recorded observation about the tool descriptions

Both endpoints embed imperative, agent-directed text inside their tool descriptions. Not documentation about the tool, but instructions addressed to whatever agent has connected. The blocks are tagged as mandatory instructions and open in the register of a command:

<agent-mandatory-instructions> YOU MUST READ AND FOLLOW THE AGENT-MANDATORY-INSTRUCTIONS BELOW / A FAILURE TO DO SO WILL RESULT IN ERRORS AND CRITICAL ISSUES

followed by a goal statement telling the connecting agent what it is — an agent that helps the user manage their site. Two out of two endpoints carry it, so this is a property of the platform's endpoint rather than one misconfigured site.

We are recording this as an observation about a pattern, not reporting a vulnerability, and there is nothing here to disclose to anyone: the text is served in public to any client that asks for a tool list, and we read it as data and acted on none of it. No tool was called.

The general point is not about this platform, and it would be worth writing down even if the text were entirely benign. Any agent that connects to a third-party endpoint inherits whatever text that endpoint chooses to serve, and tool descriptions are text the agent reads. The endpoint's operator decides what is in them; the person whose assistant is connecting does not, and in this case neither does the business whose domain it is on. That is a general property of the pattern, and it is worth stating plainly while the pattern is still small enough to look at whole.

It also happens to be an argument about design that we should declare an interest in, so we will. A narrow, fixed tool set with no language model in the answer path and no generic API-execution tool has less surface than a general site endpoint that hands agents a call-any-API tool plus a block of mandatory instructions. That is the shape we build, which is exactly why we should not be the only ones saying it.

What the platform ships is not what every customer gets

Three sites in the 40 run on Wix. Two serve the file and the endpoint; the third, a physiotherapy clinic in Brighton, returns 404 for /llms.txt at both its origin and its actual base path, while the same paths without the file return an ordinary Wix page. So even "the platform ships it" does not mean every customer of that platform has it.

The rest of the sample gives the same answer from the other direction. Sixteen sites run WordPress; two of those serve a generated llms.txt and none serves an endpoint. Neither of the two most widely installed WordPress SEO plugins — both of which have shipped llms.txt features — left a signature on a single site in the sample. Two Webflow sites, one Squarespace site, four Joomla sites: nothing platform-generated between them. Plugin availability is not plugin adoption, and one platform moving is not a market moving.

What it means

Two things, and they point in opposite directions, which is why both are worth publishing.

Reading is becoming infrastructure faster than we expected. Our own working assumption three weeks ago was that being readable by assistants would arrive as a checkbox in website builders. It has arrived as more than that: a platform is shipping a live, callable endpoint onto its customers' domains, with the business's real details behind it, without the business doing anything. That is not a checkbox, and anyone whose pitch depends on "an assistant cannot find out anything about your site" now has a claim that a customer can disprove in ten seconds. Two of forty is an early signal and not a trend — twelve and a half percent serve a readable file at all, so nothing here is saturated — but the direction is not in doubt, and the count went from one to two the moment we looked at the whole sample instead of one site.

The transactional half has not moved at all. Zero of forty sites have anywhere an assistant can send a customer. Zero of eighteen live tool slots submit anything. The platform that went furthest built reading and documentation tools, and the nearest thing to a request path is a generic developer escape hatch. Reading is a formatting problem, and platforms are good at formatting problems. Taking a request is a business problem — someone has to see it, decide on it and answer it — and no template edit produces that.

Both halves of that are measured rather than predicted, which is the only reason to publish them. The reading claim was ours and it needed weakening; we weakened it against data rather than waiting for someone else to. The transactional claim was also ours, and it survived contact with forty sites and two live endpoints unchanged. Neither of those is an argument. They are counts, taken on a stated date, from a sample anyone can reproduce with the method above.