To add WebMCP to a website, you register tools with the browser in JavaScript (the imperative API), or add a few attributes to an existing HTML form (the declarative API), and switch the feature on for real visitors with a Chrome origin-trial token. On quantumines.com we did both on 10 November 2026: four read-only tools that answer questions about the studio and its products, and a contact form that an agent can fill in but only the visitor can send. The whole client-side part is one 76-line file. This write-up shows what we built, why each choice was made and what we would do differently.

What is WebMCP, in one paragraph?

WebMCP is a proposed web standard from the Chrome team for exposing structured tools to AI agents that act inside a browser. Without it, an agent has to read the page, guess which button does what and simulate clicks and typing (Chrome's docs call this "actuation"). With it, the page says: here is a tool called get_product, it takes a product name, and it returns these facts. Chrome offers it as an origin trial from Chrome 149, and as a flag (chrome://flags/#enable-webmcp-testing) for local testing. It is still experimental and the API may change.

Why would a small studio site bother?

Quantumines is a technology and product studio in Lahore. Our site exists so that people, search engines and AI assistants get our facts right: who runs the studio, what each product does, how to reach us. We already publish those facts for machines in /facts.json, /llms.txt and a guide for AI readers. WebMCP was a small extra step that lets an agent working for a visitor ask the page directly instead of scraping it. It took us a morning, adds no weight for visitors whose browsers don't support it, and fits the rule we follow everywhere: one set of verified facts, served in every format people and machines use.

Which tools did we register?

Four, all read-only:

The WebMCP tools on quantumines.com (12 November 2026)
ToolInputWhat it returns
get_studio_factsnoneWhat the studio does, its founder and co-founder, services, contact email, official profiles and the date the facts were last checked
list_productsnoneThe best-known products with a one-sentence summary, website and profile page for each
get_productname (string)One product's details, or a list of valid names if the name doesn't match
search_quantuminesquery (string)Up to eight matching guides, answers and pages, with links

All four read from files the site already publishes. The three fact tools read /facts.json; the search tool reads the link list in /llms.txt. That means there is no second copy of the facts to keep in sync: when the build script regenerates those files, the tools change with them.

What does the code look like?

The file starts with feature detection, so browsers without WebMCP skip it entirely:

const mc = document.modelContext;
if (!mc || typeof mc.registerTool !== 'function') return;

Each tool is a plain object with a name, a description written for a language model, a JSON Schema for its input, an annotation and an execute function. Here is the one that looks up a product:

{
  name: 'get_product',
  description: 'Get the details of one Quantumines product by name ...',
  inputSchema: {
    type: 'object',
    properties: { name: { type: 'string', description: 'Product name, for example "CryptoMerchant".' } },
    required: ['name']
  },
  annotations: { readOnlyHint: true },
  execute: async ({ name }) => { /* find it in /facts.json */ }
}

Three details mattered more than we expected:

  • Forgiving matching. get_product compares names with spaces, case and punctuation removed, so "Crypto Merchant", "cryptomerchant" and "CryptoMerchant" all work. When nothing matches, it returns the valid names rather than an error, which gives the agent a way forward.
  • One fetch, shared. The facts file is fetched once per page and the promise is reused by every tool, so an agent calling three tools in a row costs one request.
  • Clean-up. Tools are registered with an AbortController signal, and the controller is aborted on pagehide, so nothing is left registered once the page is gone.

The script is loaded with defer, so it never blocks rendering. After this and the image work done the same day, Lighthouse scored the homepage 100 in performance, accessibility, best practices and SEO, with a mobile largest-contentful-paint time of 1.8 seconds.

How do you let an agent use a form without letting it send things?

The contact form on our homepage uses the declarative API: three kinds of attributes on ordinary HTML.

  • toolname="contactQuantumines" and a tooldescription on the form element say what the form is for and when to use it.
  • A toolparamdescription on each field says what goes in it ("Email address where Quantumines should reply").
  • The hidden anti-spam field gets one too: "Anti-spam field. Always leave this empty." Without that line, an eager agent may fill every input it finds and trip the spam filter.

The attribute we deliberately left out is toolautosubmit. Without it, an agent can fill the form, but the visitor still reviews the message and presses Send. Sending a message to someone is an action with consequences, and we think the person should make that final click. The same thinking is behind marking the other four tools readOnlyHint: true: none of them can change anything.

How do you turn it on for real visitors?

During the trial, WebMCP only runs on sites that present a valid origin-trial token. We registered quantumines.com in the Chrome Origin Trials console and got a token valid until 29 March 2027. You can put a token in an origin-trial meta tag, but we send it as an HTTP response header instead:

res.setHeader('Origin-Trial', ORIGIN_TRIALS);

Our Node server sets it on every response, including the static pages, so no page can be missing it, and renewing it later is a one-line change in one file. The token is public by design; it only works for the origin it was issued to. We have a reminder to renew it from 1 March 2027.

How did we test it?

On the live site, in Chrome 156 under the origin trial, we checked that all four tools appear, that each returns what /facts.json says, that a wrong product name gets a helpful reply, and that the form tool fills the fields but does not send. Chrome's docs also point to two extensions that act as test agents (the Model Context Tool Inspector and an example agentic extension) and to DevTools support for checking how the browser reads your JSON Schemas.

What would we tell another small team?

  • Start read-only. Tools that only read public facts carry almost no risk and still help agents get you right.
  • Reuse what you publish. If you have a facts file, a sitemap or an llms.txt, build the tools on top of it instead of writing new data.
  • Write descriptions for a model, not a marketer. Say what the tool returns and when to use it. Name the inputs with examples.
  • Keep the human in the loop for anything that sends, buys or deletes. Leave out auto-submit and use a confirmation step.
  • Treat it as an experiment. Chrome says the API is subject to change, so keep the code small and check Chrome's docs whenever you touch it.

Frequently asked questions

Does WebMCP replace llms.txt or structured data?

No. Search engines and AI crawlers read pages, schema and files such as llms.txt without running your JavaScript. WebMCP helps a different reader: an agent acting inside a browser tab for a person. We keep all three, fed from the same facts.

Which browsers support WebMCP?

As of November 2026, Chrome offers it as an origin trial from version 149 and behind a testing flag. It is a proposed standard, so other browsers may follow. Pages should treat it as a progressive enhancement and work fully without it.

Can WebMCP tools run in iframes?

Tool registration is controlled by the tools permissions policy, which defaults to self: it works in the top-level page and same-origin frames. A cross-origin iframe needs allow="tools".

Is it safe to expose a form to agents?

It is as safe as the form itself, provided you keep the final submit with the person. Validate on the server as you would for any visitor, and don't add auto-submit to forms that send messages, place orders or change accounts.

The tools are live on quantumines.com and documented, with the rest of our machine-readable files, in the guide for AI readers. Quantumines is the studio founded by Muhammad Ali Raza (Ali Arbi); for its products, see /products.