WebMCP, explained with a roofing company

Watch it happen

Coppervale Roofing is not a real company. I built it to show the difference.

The site lists three services, prices four roofing materials, and covers six towns. Behind it sit tools an assistant can ask directly: what a metal roof costs, whether Halstead is covered, what appointments are open.

In the recording, someone asks an assistant about replacing their roof. It gets the price range, confirms the town, and finds an opening. It never reads the page. It asks the site, and the site answers.

Everything in it is invented. The prices, the towns, the appointment times. Nothing books.

Where this actually stands

Straight answer: almost nothing uses this yet.

WebMCP is a Chrome trial running through Chrome 156. Google says Gemini in Chrome will be the first assistant to call these tools. As of August 2026 none of the big ones do. I sat on my own site with seven working tools registered, and no assistant picked them up on its own.

So this is early, and you do not need it today. I built it because it costs close to nothing to run and I would rather have it working than read about it.

What is worth doing today is making sure an assistant reading your site finds the right answers. Your Google listing, your hours, your prices, and copy that plainly says what you do. WebMCP is the step after that, not instead of it.

If you build websites

The rest of this is for people who build websites. If that is not you, the useful part is above.

1. 1.Arguments cross as a JSON string, not an object

   The explainer shows objects. Chrome 151 does not take one. Pass an object and it fails with "Failed to parse input arguments", which reads like a schema problem and is not. The result comes back as a string too, so it needs parsing before .content exists.

   The tell is that inputSchema from getTools() is serialized as well. Your execute functions still receive a normal object, so only the call boundary is affected.

   const mc = document.modelContext;
   const tools = await mc.getTools();
   
   const fit = tools.find((t) => t.name === 'check_fit');
   const raw = await mc.executeTool(fit, JSON.stringify({
     businessType: 'restaurant',
     painPoint: 'phone rings all day and we miss reservations',
   }));
   
   console.log(JSON.parse(raw).content[0].text);

2. 2.There is no unregisterTool

   The trial build gives you ontoolchange, executeTool, getTools and registerTool. That is all of it. Chrome 149 also predates the signal option, so on that build you cannot take a tool back at all.

   Anything you register from the console survives until you reload and shows up alongside the real ones. React strict mode registers your whole set twice in development unless you check for the method and fall back to the abort signal.

3. 3.It silently needs origin isolation

   WebMCP will not register in a document that is not origin-isolated. Chrome usually origin-keys anyway when it has the memory, so it often works without you doing anything. That is worse than failing, because you ship believing it is fine and it stops being fine on a loaded machine.

   Send the header on every route. One line, and it turns a maybe into a yes.

   // next.config.ts
   async headers() {
     return [{
       source: '/:path*',
       headers: [{ key: 'Origin-Agent-Cluster', value: '?1' }],
     }];
   }

4. 4.The entry point moved mid-trial

   It went from navigator.modelContext to document.modelContext in July 2026. Chrome 150 deprecated the old spelling, but the trial opened on it and Chrome 149 has nothing else. Read both until the trial closes.

   The published types package covers only the new spelling, so it cannot type the fallback the older build needs. Six hand-written interfaces beat a dependency that describes half your users.

   const modelContext = document.modelContext ?? navigator.modelContext;
   if (!modelContext) return;

5. 5.The declarative form API will hand an agent your honeypot

   Chrome turns a plain form into a tool from two attributes. It builds the schema from the named inputs inside that form. A honeypot is a named input inside that form, sitting off-screen rather than hidden, because hidden is what automated fills skip.

   So Chrome offers your spam trap to the agent as a parameter, with your own label as the description, and a helpful agent fills it in. Your trap then throws the lead away. A good honeypot answers a rejection with a success response, so nobody on either end ever finds out.

   Move the honeypot outside the form element and wire it by ref, or drop the name attribute. Check it before you ship, not after.