Why AI Agents Interact With Websites Badly — and What Changes That

The AI assistant that helps you plan a trip, book a table, or check whether a contractor is available in your suburb is operating against a web that was designed for humans.

Every website it visits was built for a human to read — with visual hierarchy, navigation menus, and prose descriptions that humans understand but that automated systems must interpret. When an AI agent needs to know whether a restaurant has a table available on Saturday night, it does not access a clean data feed. It loads the page, parses the HTML, finds what looks like a booking form, tries to understand what each field means, and attempts to interact with it as a human would — by clicking, typing, and submitting. This process is slow, fragile, and frequently wrong.

The web has a structural problem for AI agents. WebMCP is an attempt to fix it at the infrastructure level.

How agents currently interact with websites

There are three mechanisms AI agents use today when they visit a website:

DOM parsing — the agent reads the HTML source of the page and attempts to extract information from it. This works reasonably well for simple, structured content. It breaks down when information is embedded in nested elements, when JavaScript must execute to render the content, or when the same information is described differently on different pages.

Screenshot and visual interpretation — the agent takes a screenshot of the rendered page and uses vision models to understand what is displayed, then maps that understanding back to clickable elements. This is even more fragile: button positions shift with viewport size, tooltips and overlays obscure content, and the agent must make its best guess at which element corresponds to which function.

Conventional scraping — the agent fetches the page’s raw text and processes it through its language model to extract information. This is what most AI search tools do for content-type queries. For action-type queries — booking, submitting, transacting — it does not work at all.

None of these approaches is what you would design if you were building a system from scratch. They are workarounds for a web architecture that predates AI agents by decades.

What WebMCP does differently

WebMCP (developed through the W3C Web Machine Learning Community Group, co-authored by Google and Microsoft) inverts the architecture.

Instead of the agent trying to extract information from a website by analysing how it looks, the website declares what it contains in terms the agent can directly use. The site owner defines named tools — JavaScript functions with explicit inputs, descriptions, and return values — that the agent can call through the browser’s model context API.

A hotel website might register a tool called checkRoomAvailability that takes a check-in date, a check-out date, and a room type, and returns structured availability data. An e-commerce site might register searchProducts that takes a query and filters, and returns matching items with prices and stock status. A local service business might register getServiceAreas that returns the list of suburbs they operate in, and requestQuote that accepts a job description and contact details.

These tools are not page content the agent reads and interprets. They are named functions the agent calls and receives structured data from. The interaction is precise, reliable, and entirely controlled by the site owner.

The critical architectural advantage is that WebMCP operates within the user’s authenticated browser session. An agent using WebMCP tools on a bank’s website can access account information the user is already logged into — without the agent ever seeing the credentials, without re-authentication, without the bank needing to build a separate API. The session that the human opened is the session the agent uses.

How this fits with the other AI standards

WebMCP is one layer in a stack of AI infrastructure that well-prepared websites implement together:

llms.txt is the simplest layer — a plain text file at the site root that tells AI crawlers and language models what the site contains. It is read-only, passive, and requires no engineering. It is the AI equivalent of a site map: a structured guide to what exists. About 8.7% of the top 1,000 global websites have implemented it as of mid-2026. Despite this, server log evidence shows that very few AI systems are actually reading these files yet — but the implementation cost is essentially zero, so there is no reason not to have it.

Structured schema markup is the established layer. JSON-LD declarations embedded in page HTML tell Google and other systems what type of business the site belongs to, where it is located, what it offers, and how to contact it. This feeds the knowledge graphs that Google’s AI Overviews and AI Mode draw from when generating answers. It is not AI-agent-specific — schema has existed for over a decade — but its importance increases as AI systems become the primary interface for information discovery.

Anthropic MCP (Model Context Protocol) is the backend layer. It connects AI assistants running server-side — Claude Desktop, Claude in enterprise environments, ChatGPT with plugins — to external data sources and tools. A business could run an MCP server that gives an AI assistant access to their inventory system, their calendar, their CRM. This operates in the agent’s server environment, not in the browser. It requires deploying a separate server that speaks the MCP protocol.

WebMCP is the browser-native layer. It operates in the user’s live browser session, requires no server deployment beyond the website itself, and is the mechanism designed for real-time, in-session AI agent interaction with websites.

These are not competing standards. A site can and should implement all four.

Where this is right now

The honest assessment, which not all coverage provides, is that no mainstream AI assistant is currently calling WebMCP tools on live websites. Chrome has the API available in its origin trial. No consumer AI product has shipped a feature that consumes those tools at scale.

This means there is no measurable return on WebMCP implementation today. A plumbing business that registers its service area and booking tools in WebMCP format will not see more calls tomorrow because of it.

The case for implementing it now rests on a different kind of logic: the infrastructure cost is low, the trajectory is clear (Google and Microsoft co-authored this standard; Google’s flagship AI search product is intended to be the first consumer), and the businesses that have their tools registered when the consuming software ships will be ready to engage. The ones that have not registered anything will be scrambling to catch up on a standard that has already matured.

TVS implements WebMCP registration on every site we build. Not because it drives rankings today — it does not — but because every TVS site is built to remain relevant as the web’s infrastructure evolves. The cost of being ready early is low. The cost of being caught unprepared, in any technology shift, is not.

---

TVS implements the full AI infrastructure stack — llms.txt, structured schema, WebMCP tool registration — on every website we build. Run a visibility check to see where your current site stands, or speak to us about what an AI-ready build looks like.