Making Your Site Agent-Ready: WebMCP, Structured Data, and the Agent Tool Surface
An agent that lands on your page still has to find your prices, your availability, and a way to act - the same way a human does, except it's parsing markup instead of reading a screen.
Landscape as of September 2026
A site is agent-ready when the facts an agent needs (prices, availability, policies) are exposed as clean structured data rather than buried in visual layout, and when the actions an agent might take (search, add to cart, check a status) are exposed as a declared tool surface it can call - via emerging standards like WebMCP - instead of something it has to infer by scraping the DOM and guessing which button does what. Automated, agent-driven requests already make up the majority of HTML web traffic (57.5% per Cloudflare Radar / HUMAN Security, 2026), so this is a present, not future, integration surface.
Two layers, not one: facts and actions
"Agent-ready" collapses two separate jobs that are easy to conflate:
- The facts layer (structured data). Product, Offer, FAQPage, and similar schema.org markup, plus a clean, complete llms.txt, tells an agent what's true about the page without forcing it to infer price or availability from CSS layout. This is the same machinery that already helps with GEO citation - see our explainer on event tracking schemas for the adjacent discipline of documenting what a page or event means.
- The actions layer (the tool surface). WebMCP is the newer piece: the site itself declares in-page tools (search this catalog, check this order status, add this item) that an agent calls directly, the way it would call any other tool in an MCP-style integration, instead of scraping the DOM to find and click a button. It sits in a stack alongside MCP (agent-to-tool, Anthropic), A2A, and the commerce-specific protocols (ACP, AP2) - each doing a related but distinct job.
Why this is a tracking problem, not just a build problem
Every one of these surfaces changes what "a visit" looks like on your server. A tool call through WebMCP or an API-driven ACP/AP2 transaction may never render your page or execute your analytics script at all - which is exactly the invisibility problem covered in our piece on what agentic traffic is. Building the tool surface and building the instrumentation to see it used are the same project split into a front door and a back door: expose the actions, then make sure something logs when they're called.
The identity question underneath both layers
Exposing a tool surface raises an obvious follow-up: which agents get to call it, and how do you know it's really them? Web Bot Auth is the mechanism the industry is converging on - a bot signs each request with a key and publishes the public half at a well-known URL, so your server verifies a cryptographic proof rather than trusting a spoofable user-agent string. It's still an individual IETF draft as of August 2026, not a ratified standard, but it already ships in Cloudflare Verified Bots and AWS WAF - our assessment (not yet a settled fact) is that any tool surface built without an identity layer in mind will need to retrofit one within the next year or two as this standardizes further.
Where to start, in order
- Audit your structured data first. An agent that can't parse a price cleanly won't get further no matter how good the tool surface is.
- Publish and maintain llms.txt so agents and crawlers alike have a canonical, current summary of what your site does and where.
- Decide whether you should block or measure the agent traffic you're about to expose more surface to - a business decision that comes before the technical build, not after.
- Instrument the tool surface server-side so a call to it produces an event, the same way a client-side click would - otherwise you've built a door with no logging on the other side of it.
Agent-ready sites - common questions
▸Is making a site agent-ready the same thing as SEO or GEO?
Related but not the same job. SEO and GEO are about getting found and cited in search results and AI answers. Agent-readiness is about what happens after an agent lands on your page or calls into it - whether it can find your prices, availability, and actions in a structured form, or has to scrape and guess like a crawler would.
▸Do I need WebMCP if my site already has structured data (schema.org)?
They solve different problems. Structured data (Product, Offer, FAQPage schema) tells an agent what's on the page - the facts. WebMCP is a newer, separate mechanism for exposing what the page can do - callable tools an agent invokes directly instead of parsing the DOM to find a button and click it. A fully agent-ready page eventually wants both.
▸Does this mean I should stop agents from scraping my pages the old way?
Not necessarily - most agents today still work by parsing rendered HTML, and that will stay true for a while. Building a tool surface is additive: it gives well-behaved agents a faster, more reliable path, it doesn't require blocking the DOM-scraping path other agents still depend on.
Want your site's tool surface and the tracking underneath it built together?
A data audit maps what an agent can currently see and do on your site, and what's still invisible to it.