Instantly AI-Agent-Ready with WebMCP on Demand

Fastly has built a proof of concept on Fastly Compute that automatically injects WebMCP attributes into HTML forms at the edge, enabling AI agents to interact with web forms without developer changes. The heuristic engine classifies forms based on field names, input types, placeholders, labels, and action URLs, generating tool names and parameter descriptions. This addresses the adoption problem of the proposed WebMCP standard, which is currently in an origin trial in Chrome 149 through 156.

AI agents are getting good at browsing the web, but the web isn't ready for them. When a browser agent tries to interact with a standard HTML form, it's working from pixels and best guesses. Text inputs are usually fine, but as you can see in the demo, agents fumble with elements like date pickers and multi-select dropdowns. This is the core tension with agentic browsing right now. The agents are capable, but they're operating without context. A flight search form with two airport fields and a date picker is obvious to a human, but an agent has no semantic signal telling it "this is a departure airport, it wants a three-letter IATA code." So it guesses, and sometimes it gets it right, but often it doesn't and soils the experience for the end-user. WebMCP https://developer.chrome.com/docs/ai/webmcp , a proposed web standard, addresses this. It started as an early preview in Chrome Canary, and it's now in a running from Chrome 149 through 156, with a local dev flag https://developer.chrome.com/origintrials/ /register trial/4163014905550602241 public origin trial chrome://flags/ enable-webmcp-testing for anyone who wants to try it without a token. It gives websites two ways to expose functionality to agents: an imperative API where developers register tools via JavaScript, and a declarative API where they annotate existing HTML forms with a few attributes. The imperative path is powerful but requires real development work. The declarative path is where things get interesting for us. Developers add attributes like toolname , tooldescription , toolparamdescription , and optionally toolautosubmit to their forms, and the browser's agent knows exactly what each form does, what each field expects, and how to fill it out correctly.The problem as ever is adoption. Most site developers won't add these attributes anytime soon, if they even know WebMCP exists. The spec is early, the standard is still being finalized, and there are millions of existing sites with forms that work fine for humans but remain opaque to agents. What if the Edge Did It for Them? We built a proof of concept https://github.com/fastly/webmcp-on-demand-proto/tree/main on Fastly Compute that answers that question. The idea is to intercept HTML responses at the edge, detect forms in the markup, classify what they do using heuristics, and inject the right WebMCP attributes before the HTML ever reaches the browser. No changes required from the developer, Fastly handles the transformation in flight. The browser receives enriched HTML where every form has the semantic context an agent needs. Chrome discovers the tools natively through its WebMCP API, and the agent can interact with the page reliably instead of guessing. How the Heuristic Engine works There's no LLM in the request path. Classification is purely heuristic, based on signals already present in the HTML. When a form streams through the edge, the Compute service examines the field name attributes, input types, placeholder text, labels, the form's action URL, and the combination of fields that appear together. Two inputs named "origin" and "destination" with placeholders like, ex. "SFO" and "JFK" next to a date field signal a flight search. An "email" and "password" field together is likely an auth form. From that classification, the service generates the appropriate toolname like search flights , a tooldescription explaining what the form does, and per-field toolparamdescription values that tell the agent what each input expects. It also decides whether toolautosubmit is safe: yes for a search form, no for a checkout. Chrome does have a fallback when toolparamdescription is missing: it reads the field's <label or aria-description . That helps well-built forms, but the messy reality of the web is that a lot of forms have no labels at all, or labels like "From" that don't tell an agent much. Those are exactly the forms where injecting a real description at the edge makes the biggest difference. This is the same kind of pattern recognition you'd do if someone showed you a form and asked "what does this do?" You wouldn't need an AI model to figure out that two airport fields plus a date equals flight search, you'd just recognize the pattern. Streaming, Not Buffering The Compute service uses HTMLRewritingStream to process the response as it flows through the edge, element by element. It attaches handlers to <form and <input tags and injects attributes inline as they pass through the stream. The full HTML response is never held in memory. The browser starts receiving content almost immediately, and the added latency from classification and injection is minimal since there are no network calls involved, just pattern matching against what's already in the markup. Here's what a plain form on the origin looks like this: <form action="/search" method="POST" <input type="text" name="origin" placeholder="e.g. SFO" required / <input type="text" name="destination" placeholder="e.g. JFK" required / <input type="date" name="departure date" required / </form After flowing through the edge, the browser receives: <form action="/search" method="POST" toolname="search flights" tooldescription="Search for available flights between two airports on a specific date" toolautosubmit <input type="text" name="origin" placeholder="e.g. SFO" required toolparamdescription="Departure airport. Three-letter IATA code e.g. SFO " / <input type="text" name="destination" placeholder="e.g. JFK" required toolparamdescription="Arrival airport. Three-letter IATA code e.g. JFK " / <input type="date" name="departure date" required toolparamdescription="Departure date in YYYY-MM-DD format required " / </form It’s the same form, but now any WebMCP-capable agent knows exactly what it's looking at. Why the Edge is the Right Place for This Chrome reads WebMCP attributes to discover tools, but it doesn't generate them. The browser is the consumer, not the author. If the attributes aren't on the page, Chrome doesn't do anything with the form. That's by design, the spec is an opt-in authoring model. And the attributes are only half of what a site needs to opt in. During the origin trial, a page needs a valid origin trial token before Chrome will enable WebMCP at all. The API is also gated by a tools Permissions Policy and only works in origin-isolated documents. All of that is header and markup plumbing, which is to say, exactly the kind of thing an edge platform handles every single time a response passes through. The same Compute service that injects the form attributes can inject the trial token and verify the headers are agent-ready. The gap here is that very few sites will opt in anytime soon, leaving Fastly in a unique position to bridge it. We're already in the request path for millions of sites, handling TLS termination, caching, and compute at the edge. Adding WebMCP injection is a natural extension of that same role: we're making the response better on the way through, just like we do with security headers, image optimization, or any other edge transformation. What's Next This proof of concept covers form detection and WebMCP attribute injection using heuristics, but there's definitely a clear path beyond that. Chrome's WebMCP schema synthesis algorithm reads standard HTML attributes like required, min, max, type, and pattern to build the tool's input schema. A lot of real-world forms are sloppy with these, a date field set as type="text", a required field missing the required attribute, that kind of thing. A natural follow-on is enriching those standard attributes at the edge too, so Chrome generates better schemas from more correct HTML. Still heuristic and the same architecture, just producing higher-quality tool definitions. WebMCP is still early, with a W3C Draft Community Group Report published in February 2026. But the trajectory is clear: as browser agents become a real way people interact with the web, site readiness for those agents becomes an infrastructure problem. We'd love to hear how you're thinking about agentic browsing and what readiness looks like for your sites. Join the conversation on the Fastly Community forum https://community.fastly.com , or . https://www.fastly.com/contact-sales/ reach out to talk to an expert