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. 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.The argument format changed during the trial

   Chrome’s current docs pass the arguments as a plain object and deprecate the JSON string form from Chrome 155. Chrome 151 does not take an object. Pass one and it fails with "Failed to parse input arguments", which reads like a schema problem and is not.

   So pass the object, and retry as a string only on that exact error. Retrying on any error would run a tool twice when the tool itself threw. The result comes back as a string either way, so it needs parsing before .content exists. 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 args = {
     businessType: 'restaurant',
     painPoint: 'phone rings all day and we miss reservations',
   };
   
   let raw;
   try {
     raw = await mc.executeTool(fit, args);
   } catch (err) {
     if (!/parse input/i.test(String(err))) throw err;
     raw = await mc.executeTool(fit, JSON.stringify(args)); // Chrome 151
   }
   
   console.log(JSON.parse(raw).content[0].text);

2. 2.There is no unregisterTool

   The spec has no unregisterTool. You take a tool back by aborting the signal you passed to registerTool, and the trial build I tested gives you ontoolchange, executeTool, getTools and registerTool, nothing more.

   Anything you register from the console survives until you reload and shows up alongside the real ones. Pass a signal and abort it in your effect cleanup, or React strict mode registers your whole set twice in development.

3. 3.The entry point changed name

   The spec and Chrome’s docs use document.modelContext. Earlier versions of the API used navigator.modelContext. Read both until the trial closes.

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

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

4. 4.The declarative form API may hand an agent your honeypot

   Chrome turns a plain form into a tool from two attributes, building the schema from the inputs inside that form and using each label as a description. A honeypot is an input inside that form, sitting off-screen rather than hidden, because hidden is what automated fills skip. The explainer still lists how off-screen and hidden fields are handled as an open question.

   If Chrome offers your spam trap to the agent as a parameter, a helpful agent fills it in and your trap 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.