blog

WebMCP: Teaching Your Website to Talk to AI Agents

August 4, 2026 · #ai #webmcp #mcp #agents #web #browser

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.

I built a live one you can try

The official demos are all “call one tool and you’re done”, order a pizza, book a table. Useful, but they undersell the idea. So I built something more agentic to go with this post: Career Copilot, an experimental agentic career portal where you hand the agent your resume and it runs a whole mission: parse your profile, pull openings from several sources, match each against you, tailor applications, and apply, with your approval.

Career Copilot, a live WebMCP career portal

Paste your resume and the agent parses it into a real profile, sets your preferences, then registers eight WebMCP tools: parse_resume, set_preferences, aggregate_openings, match_profile, tailor_resume, shortlist, pipeline_status, and a consequential submit_application that asks before applying in your name. Tell an agent "match my profile across the sources, shortlist the top two, tailor my resume, and ask before applying", and it chains all of them, live. A walkthrough button runs the same mission if you don't have an in-browser agent handy.

Open the live demo →
Deployed and confirmed working: with chrome://flags/#enable-webmcp-testing enabled, the page reports "WebMCP live, 8 tools registered" and the tools appear in the DevTools WebMCP panel. No flag? The walkthrough runs the same flow anyway. It's the Phase 0/1 slice of a real product idea: automate the whole job hunt, keep a human on the one action that matters, pressing apply.

Why this shows off WebMCP better than a form-filler: the agent has to reason across tools, using a profile it parsed from your actual resume. It aggregates roles from several sources, scores each against your real skills and salary preferences (logic a DOM scraper could never run), tailors a resume per role, then pauses for human approval on the one action that applies in your name. Here’s an actual tool-call log from a run, the agent working, not a mockup:

tool activity · 15 calls
→ toolparse_resume(…)
✓ resultprofile: Senior Backend Engineer, 9 skills, 8y
→ toolset_preferences(…)
✓ resultremote, $150,000+, staff
·Agent mission: match my profile across sources, shortlist top 2, tailor, ask before applying.
→ toolaggregate_openings(remote, $150,000+)
✓ result6 roles from Greenhouse, Lever, Ashby
→ toolmatch_profile(j2)
✓ result99% fit, no gaps
→ toolmatch_profile(j4)
✓ result98% fit, gaps: Kafka
→ toolshortlist(j2)
✓ resultshortlisted Staff Platform Engineer
→ tooltailor_resume(j2)
✓ resultresume tailored for Lumen Cloud
→ toolsubmit_application(j2)
⏸ gateawaiting your approval to apply to Lumen Cloud…
✓ resultapplied to Lumen Cloud ✓
·Mission complete.
A real run. It parsed a resume into a profile, set preferences, aggregated roles from three sources, then scored each differently (99%, 98%) against that profile with distinct skill gaps, logic scraping the page can't do. Change the seniority preference and the ranking changes; here "staff" pushed the Staff Platform role to the top. And the apply step stopped for a human. That's the whole WebMCP thesis in one screen.

The full source is a single self-contained HTML file, and I wrote up the product thinking behind it (candidate side, employer side, the honest limits of auto-applying into ATS portals) as a design note in the repo. The short version: automate the entire job hunt, keep a human on the one consequential action, applying as you.

The trust model, because this is the scary part

The obvious worry: if a page can hand tools to an agent, can a malicious page trick the agent into doing something awful? The design takes this seriously, and it’s worth knowing the guards.

  • It runs visibly, in the tab. No headless, background execution. A browsing context has to be open, so actions happen where the user can see them.
  • Origin-isolated only. Tools can only be registered in origin-isolated documents, and it’s gated by a tools Permissions Policy that defaults to self, so a random cross-origin iframe can’t quietly register tools.
  • Sensitive actions can demand a human. For things like making a purchase, a tool can require an explicit user confirmation dialog before it proceeds. Human-in-the-loop is built into the pattern, not bolted on.
  • Untrusted content is flagged. Tools carry annotation hints like readOnlyHint and untrustedContentHint, so the agent can treat a tool that returns third-party content with appropriate suspicion, which matters given everything we know about prompt injection.

None of this makes it magically safe, the standard is young and the security model is still being worked out, but the shape is right: visible, same-origin, consent-gated, and honest about untrusted data.

Honest pros and cons

Why it's exciting
Structured tool calls instead of brittle DOM scraping
Runs in the user's real, logged-in session, no separate bot auth
The site stays in control of what it exposes
Survives redesigns: the tool contract outlives the layout
Reuses code you already have, tiny to adopt
A real standard direction, not one vendor's lock-in
Why it's early
Experimental: origin trial only, subject to change
Chrome-first today; broad browser support isn't here yet
Needs site adoption to matter; agents can't call tools that don't exist
Discoverability gap: a client must visit a site to learn its tools
Security model still maturing (malicious tools, injection)
Complex sites may need real refactoring to expose clean tools
The cons are almost all "it's early," not "it's wrong." That's the profile of a promising standard in its incubation window: the idea is sound, the ecosystem hasn't caught up yet.

Where it fits: use cases

The pattern shines anywhere an agent needs to do something on a site, not just read it.

E-commerce
Expose search_products, add_to_cart, checkout. An agent shops your store through real tools, not by clicking around.
Booking & travel
Multi-city, multi-passenger trips or restaurant tables, where the form is complex and scraping is painful.
SaaS dashboards
Let an agent run the actions your app already has: create a ticket, filter a report, update a record.
Form filling
Declare the form's fields and a submit tool; the agent maps data in cleanly instead of guessing inputs.
Accessibility
A declared, semantic tool surface is a gift for assistive agents, clearer intent than raw markup.
Internal tools
Wrap your admin panel's actions as tools so an internal assistant can drive them safely and visibly.
The through-line: any site that has "things you can do," not just "things you can read," is a candidate. The richer your site's actions, the more WebMCP gives you.

Where this is headed

Now the fun part, because the ceiling here is high.

The obvious next step is standardization across browsers. Right now it’s a Chrome trial; the destination is a web standard every browser implements, the way fetch or the clipboard API are everywhere. When that lands, “does this site have an agent interface?” becomes as normal a question as “is this site mobile-friendly?”

Then there’s the agentic web itself. Imagine sites shipping an agent interface alongside their visual one, on purpose, the way they ship a mobile layout today. Your site’s UI is for humans; its declared tools are for agents; both are first-class. A site that’s good at being operated by an agent gets used by more agents, which becomes a real reason to invest in the tool surface.

It gets more interesting when you combine WebMCP with remote MCP. WebMCP handles what lives in the browser (the page’s own actions, the user’s session), while remote MCP servers handle backend tools and data. An agent could fluidly use both: call a page’s add_to_cart tool via WebMCP, then hit a remote inventory MCP server for stock, stitching client and server tools into one task.

And further out: agent commerce. If a store exposes clean purchase tools and an agent can call them within the user’s authenticated, consenting session, you get a path to agents that actually complete transactions safely, with the human able to watch and confirm, rather than a scraper hammering a checkout flow. The same shape extends to booking, scheduling, support, anything transactional.

The big bet underneath all of it: the web was built for humans to read and click. The next version is built to also be operated by agents, cleanly and on the site’s own terms. WebMCP is one of the first serious attempts to make that a standard instead of a hack.

The takeaway, and go try it

Here’s the whole thing in a sentence: WebMCP lets your website hand an AI agent a clean set of tools instead of forcing it to reverse-engineer your buttons. That single shift, declare instead of scrape, makes agent interactions reliable, keeps the site in control, runs in the user’s real session, and survives your next redesign.

It’s early, it’s Chrome-first, and the standard will change. But the barrier to trying it is almost nothing: flip on chrome://flags/#enable-webmcp-testing, add a registerTool call wrapping a function your site already has, and watch an agent call it. Ten minutes, and you’ll understand the agentic web better than most people reading about it. Then go read the proposal, poke the demos, and file the rough edges you hit, because right now, while it’s still being shaped, your feedback actually moves it.

References

Written from scratch after reading the official documentation. These are the primary, verified sources. Nothing here is copied from them; the code shape follows the documented API.

Background reading: MCP: The Port That Let AI Finally Touch the World for the protocol WebMCP builds on, and LLM security for why the trust model here matters.

← Back to blog