WebMCP: Teaching Your Website to Talk to AI Agents

Picture an AI agent trying to book you a table on a restaurant’s website. Today, it works like a very patient, slightly confused intern. It loads the page, reads the raw HTML, tries to figure out which of the forty <div> elements is the date picker, guesses that the green button probably means “confirm,” clicks it, waits, and re-reads the whole screen to see if anything happened. Move that button next week and the agent breaks. Rename a CSS class and it breaks. Add a cookie banner on top and it clicks the wrong thing entirely. This is how almost all “agents using websites” works right now: screen-scraping and hoping. It’s the automation equivalent of operating a computer by describing screenshots over the phone. WebMCP proposes something much saner. Instead of the agent guessing what your site can do by staring at it, your site declares what it can do, as a set of clean, structured tools the agent can call directly. “Here’s a book_table tool. It takes a date, a time, and a party size. Call it.” No pixel-reading. No guessing. And the best part: it already runs in Chrome behind a trial, and adding your first tool takes about ten minutes. Let me show you the whole thing. The core shift: from scraping to declaring The entire idea fits in one comparison. Same task, two worlds. Today: the agent scrapes 1Read the entire DOM 2Guess which element is the date field 3Simulate typing and clicking 4Re-read the whole page to check 5Break when the layout changes WebMCP: the site declares 1Page registers a book_table tool 2Agent reads the tool's schema 3Agent calls it with structured args 4Tool runs your real JS, returns a result 5Survives redesigns: the tool is the contract The left column is brittle because the agent is reverse-engineering your UI every time. The right column is stable because you gave it a real interface. The layout can change freely underneath a tool whose name and schema stay the same. If you’ve read my earlier post on MCP, the port that let AI touch the world, this will feel familiar, and it should. MCP gave AI a standard way to call tools on a server. WebMCP brings that same idea into the browser: the web page itself becomes a place that offers tools, running in the tab you already have open, with the session you’re already logged into. What it actually is WebMCP is a proposed web standard, developed jointly by Google (Chrome) and Microsoft (Edge) in the W3C Web Machine Learning Community Group, that gives a web page a small JavaScript API to register tools that an AI agent can discover and call. Google describes it plainly in the Chrome docs: a way to “build and expose structured tools for AI agents,” where the site annotates its own features so agents “know exactly how to interact” with them. To be precise about maturity, it’s a Community Group draft, not a finished W3C standard and not yet on the standards track, which is exactly why now is the moment to learn it and shape it. Three things make it click into place: Discovery. A standard way for a page to say “I offer these tools,” like checkout or filter_results, so an agent can list them. Schemas. Each tool declares its inputs and outputs as JSON Schema, so the agent knows exactly what to pass and there’s far less room to hallucinate or misread. State. A shared understanding of what’s on the page right now, so the agent knows what it can actually act on. Where it stands today WebMCP is real and runnable, but early. It's available as a Chrome origin trial from Chrome 149, and you can switch it on locally with the flag chrome://flags/#enable-webmcp-testing. The proposal lives at github.com/webmachinelearning/webmcp, Angular already has experimental support, and Chrome ships demo sites (a pizza maker, travel search, a restaurant booking). Google's own words: it's "under active discussion and subject to change." So this is a "try it and shape it" moment, not a "ship it to production" one, and that's exactly why it's worth learning now. How a call actually flows Here’s the whole loop, page to agent and back. Nothing exotic happens: the page registers tools, the agent lists them, picks one, calls it with structured arguments, and your own JavaScript does the work in the page. pageRegister toolsYour JS declares book_table, search, etc. → agentDiscoverLists the page's tools and their schemas → agentCall with argsStructured JSON matching the schema → pageexecute() runsYour real JS, in the logged-in page → agentGets resultA structured answer, visibly, in the tab The tool's execute function runs inside your actual page, using your existing JavaScript, state, and the user's own logged-in session. It happens visibly in the tab, not in some invisible headless browser, so the user can watch it and trust it. That “runs in the page you’re already logged into” detail is a big deal. The agent isn’t a separate bot logging in with stolen credentials somewhere. It’s calling a function in your open, authenticated tab, using the session you already have. The site keeps control of what it exposes, and the user can see it happen. Watch one call happen Concretely, when you ask an in-browser agent to do something on a WebMCP-enabled site, it looks like this: your request, the agent picking the declared tool, the tool running, the result. you › book a table for 4 tonight at 8 agent › found tool book_table on this page agent › calling book_table({ date: "today", time: "20:00", party: 4 }) page › Booked. Table for 4 at 8:00 PM, confirmation #A17. No DOM guessing anywhere in that exchange. The agent called a named function with typed arguments, and the page did the rest with its own code. This is the difference between an agent operating your site and an agent operating a photograph of your site. The code is genuinely tiny This is the part that makes people want to try it. Registering a tool is one call. Using the current imperative API from the Chrome docs, a to-do site adding an “add item” tool looks essentially like this: register a WebMCP tool (imperative API) await document.modelContext.registerTool({ name: 'add_todo', description: 'Add an item to the to-do list', inputSchema: { type: 'object', properties: { text: { type: 'string' } }, required: ['text'] }, execute: async ({ text }) => { addTodoToPage(text); // your own existing function return `Added to-do: ${text}`; } }); That's the whole thing. You give the tool a name, a description, an input schema, and an execute function that calls code you already wrote. The agent discovers it with getTools(), and you can pull a tool back with an AbortController if it stops being relevant. There's also a declarative flavor where you annotate an HTML form instead of writing JS. Notice what execute does: it calls addTodoToPage, a function that already exists on your site. WebMCP isn’t asking you to rebuild anything. You’re wrapping the actions your site can already do in a thin, declared interface so an agent can reach them cleanly. That’s why the ten-minutes claim is real. One accuracy note, because the API is young and moving: the entry point recently moved from navigator.modelContext (the original name, now deprecated) to document.modelContext, since tools really belong to a document, not the whole browser. If you follow an older tutorial showing navigator, that’s why. A one-line shim (const mc = document.modelContext || navigator.modelContext) bridges both while the change rolls out. Expect a few more edges like this to shift; it’s a draft. A real one, worked all the way through The official WebMCP demos are all “call one tool and you’re done”, order a pizza, book a table. Useful, but they undersell the idea, because the interesting part of WebMCP isn’t one tool call. It’s an agent chaining tools to do real work, with a human gate on the part that matters. So instead of a toy, I built and deployed a real one to go with this post, and this section is the honest walk-through of it, because it teaches the whole model better than any abstract example. Career Copilot is an experimental agentic career portal. You give it a resume; it reads real job descriptions from live company boards, scores your true fit, tells you your skill gaps, and prepares a batch of applications you approve in one click. Nothing is faked: the jobs are real, the matching is computed from real job-description text, and it applies nothing without your explicit OK. Career Copilot, a live WebMCP career portal Open it, tap "See it work instantly", and watch an agent run a full job-search mission over live data: read a resume, pull real openings from GitLab, Stripe and Databricks, read each job description, score your fit, surface your skill gaps, and propose a batch of applications for you to approve. It registers 13 real WebMCP tools on the page. Open the live demo → Deployed and validated. With chrome://flags/#enable-webmcp-testing on, the page reports "WebMCP live, 13 tools registered" and they show up in the DevTools WebMCP panel. No flag needed to try it: one button runs the whole mission anyway. It never really submits an application, it prepares them and stops for you. The workflow: what the agent actually does Here’s the real mission, step by step. Each row is a WebMCP tool the page exposes; the agent chains them. Notice the shape: a run phase, then a consequential act phase that stops for a human. parse_resumeReads any resume into a real profile: skills, seniority, focus arearead aggregate_openingsPulls live roles from three real company job boardsread match_profileFetches each real job description and scores your true fit + gapsread find_gapsAggregates the gaps into a learning signal: "learn X to unlock more roles"read shortlistAdds the strongest fits to your pipeline. Reversibleact prepare_applicationsTailors a summary per role, ready to reviewact submit_batchOpens a human approval panel: review the set, uncheck any, then applygate