WebMCP Gives AI Agents Actions. Who Gives Them Knowledge?

WebMCP is solving the right problem: letting AI agents call structured functions on a website instead of scraping HTML. Chrome 149 launched an origin trial. Microsoft Edge followed. The W3C Community Group has it in scope. This is genuinely going to change how agents interact with the web.

But there's a gap the standard doesn't address. Before an agent can decide which action to call, it has to know what your site offers. WebMCP handles the "how to act" layer. Nobody has standardised the "what to know" layer — and that gap is where most agent failures happen today.

What WebMCP actually does

WebMCP annotates your website's HTML so that agents understand its interactive surface. A checkout button, a search field, a booking form — WebMCP gives agents a structured way to call these without reverse-engineering the DOM. The @mcp-b/webmcp-local-relay package bridges those tools into Claude Desktop and other MCP clients.

Concretely: a WebMCP-enabled hotel site can expose a check_availability tool. An agent calling that tool gets structured availability data back instead of parsing a table of HTML.

That's a real improvement. But watch what has to happen before the check_availability call:

1. The agent has to know the hotel exists
2. The agent has to know what room types are offered
3. The agent has to know the cancellation policy before recommending a booking
4. The agent has to know whether the property is pet-friendly, airport-adjacent, etc.

None of those come from WebMCP. They come from reading the site's content — the pages, the FAQs, the pricing table. That's the knowledge layer. And without it, the agent either hallucinates answers from training data or refuses to act at all.

The two layers every agent-ready site needs

Think of agent access to a website as having two distinct layers:

Layer 1 — Knowledge: What does this site offer? What are the rules, prices, policies, and facts? This is answered by indexing the site's content, chunking it, embedding it, and making it queryable via RAG. The output is a cited natural-language answer grounded in real page content.

Layer 2 — Action: How does the agent interact with the site? Which buttons exist, which forms are available, what parameters do they take? This is answered by WebMCP — annotated tools that agents can discover and call.

WebMCP is Layer 2. It's shipping in browsers now. But Layer 1 still doesn't exist for most websites.

Why Layer 1 can't come from Layer 2

You might assume that an agent with access to a site's WebMCP tools could just call a search tool to answer knowledge questions. Sometimes that works. But most sites don't expose a search tool. And even the ones that do return lists of links, not synthesised answers.

More importantly: an agent shouldn't have to act on a site to learn about it. The knowledge phase and the action phase are distinct. An agent planning a hotel booking should be able to read and reason about options before touching any transactional tool. Conflating discovery with action is what leads to agents that hallucinate availability, book the wrong room type, or confidently recommend a property that discontinued the feature the user asked about.

What the knowledge layer looks like in practice

For a documentation site, the knowledge layer is a RAG endpoint that accepts natural-language questions and returns cited answers grounded in the site's actual pages. When an AI coding assistant asks "how do I authenticate with this API?", it gets back the answer plus a citation, not a list of links to search through.

For a product site, it's the same endpoint answering "what's included in the Pro plan?" or "what's the cancellation window?" before any checkout tool is called.

AgentReady builds this layer automatically. Submit a URL, and within minutes the site has:

• A POST /ask endpoint — natural-language queries, cited answers
• An MCP ask_site tool — queryable from Claude, Cursor, any MCP client
• An llms.txt — a map of the site's content for agents to orient themselves
• An agent.json — machine-readable capability manifest

WebMCP + AgentReady together

The two layers complement each other cleanly. A site that has both is fully agent-ready:

1. Agent queries AgentReady: "What room types does this hotel offer and what's the pet policy?"
2. AgentReady returns a cited answer from the hotel's indexed pages
3. Agent decides on a room type based on the user's preferences
4. Agent calls the hotel's WebMCP check_availability tool to confirm dates
5. Agent calls book_room — with full knowledge of what it's booking and why

Without Layer 1, step 1–3 are either hallucinated or skipped. The agent goes straight to action with incomplete context. That's how you get bookings for the wrong room, confident recommendations that contradict the cancellation policy, and support tickets that trace back to an agent that didn't know what it was doing.

The timeline

WebMCP's origin trial in Chrome 149 is live now. Edge support landed in March 2026. The W3C process is moving. Within 12 months, browser-native WebMCP will be widespread.

The knowledge layer is available today, without waiting for browser adoption. Any site can have a queryable RAG endpoint right now. Sites that add it before WebMCP becomes mainstream will have an advantage: agents querying them will already have grounded, cited answers to work from the moment they can also call actions.

WebMCP and the knowledge layer aren't competing standards. They're two layers of the same stack. Both need to exist for agents to reliably do useful things on the web.