WebMCP: how a website hands its tools to an AI agent, and what laurelinlabs.com now exposes

What is WebMCP and where does it stand?

WebMCP (Web Model Context Protocol) is a proposed browser API that lets a web page register named, typed tools an AI agent in the browser can discover and call directly, instead of guessing which button to press from the DOM or a screenshot. It borrows the tool vocabulary of Anthropic’s Model Context Protocol, name, description and a JSON Schema for inputs, and moves it into the page itself. The draft is edited by Google and Microsoft engineers in the W3C Web Machine Learning Community Group and published as a Draft Community Group Report, whose own status section is the honest framing:

This specification was published by the Web Machine Learning Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

WebMCP Draft Community Group Report, webmachinelearning.github.io/webmcp

Most WebMCP coverage stops there, at the specification. This article does not, because on 25 August 2026 we implemented it on this site, and what follows is the build log and the measurements rather than another summary of the draft.

What did laurelinlabs.com ship, and when?

On 25 August 2026 every page of laurelinlabs.com began registering five read-only tools with document.modelContext, falling back to navigator.modelContext for Chrome builds that predate the July 2026 rename, as a no-op in every other browser. The homepage scoring form carries the declarative attributes as well, so it is callable by an agent with no JavaScript involved at all.

Every tool is annotated readOnlyHint, and the scoring tool is additionally marked untrustedContentHint because it returns text extracted from a third-party page. Nothing writes data or spends money; that is a deliberate first scope. The same handlers are also served as a remote MCP server at https://www.laurelinlabs.com/api/mcp (Streamable HTTP, no sign-in), plus a sixth tool, get_latest, for the build log, so the in-page tools and the server tools can never disagree: one codebase, two transports.

What does the tool surface measure like?

Since no mainstream assistant consumes WebMCP yet, the measurable half of the surface today is the MCP server, which speaks the same tool contract. We measured it on 29 August 2026 from a datacentre client, 4 days after launch: 3 runs per call over JSON-RPC 2.0, medians reported.

Two readings from those numbers. First, cost: the largest response is 5,981 bytes, so an agent can walk the entire tool surface for less transfer than one hero image, and a warm call answers in under 200 ms. Second, the cold path is the tax of serverless hosting: the first request after idle took 1,158 ms, roughly 7 times the warm median, which is worth knowing before you promise an agent a snappy tool. An agent resolving a question through search_laurelin_labs gets a canonical URL in one 418 byte response; the scraping alternative is fetching and parsing pages that run 50 to 100 times that size.

How does a page expose tools to an agent?

There are two surfaces, and this site uses both. The imperative API is JavaScript: register a tool with a name, a description, a JSON Schema and an execute function that runs in the page. This is the real registration for our search tool:

const mc = document.modelContext ?? navigator.modelContext;
await mc.registerTool({
  name: 'search_laurelin_labs',
  description: 'Search laurelinlabs.com for services, frameworks, tools, articles and audit checks.',
  inputSchema: { type: 'object', properties: { query: { type: 'string' } }, required: ['query'] },
  annotations: { readOnlyHint: true },
  execute: async ({ query }) => {
    const r = await fetch('/api/search?q=' + encodeURIComponent(query));
    return (await r.text());
  },
});

The declarative API needs no JavaScript: a form gains toolname and tooldescription attributes and the browser derives the input schema from the form controls. Chrome extends SubmitEvent with agentInvoked and respondWith() so a page can tell an agent submission apart from a human one, and Lighthouse already audits for forms that could be declared this way.

<form action="/tools/non-commodity-score" method="get"
      toolname="score_page_non_commodity"
      tooldescription="Open the Non-Commodity Score for a public URL."
      toolautosubmit="true">
  <input type="url" name="url" required
         toolparamdescription="Absolute http or https URL of the page to score">
  <button type="submit">Score it</button>
</form>

Tools are origin-isolated: a tools Permissions Policy defaults to self, so an embedded cross-origin frame cannot register tools unless the host allows it. Registration accepts an AbortSignal, so tools withdraw cleanly when a view unmounts.

What happened when we scored this article?

The first version of this article was published on 25 August 2026 as a conventional explainer. On 29 August 2026 we ran it through the NCS Checker extension with all four vectors of the Non-Commodity Score measured, and it failed our own publishing gate.

The redundancy evidence was specific: the passages explaining what WebMCP is competed with the Chrome team’s own documentation and lost, while the most novel passage on the page, the consultant’s verdict, sat at the bottom. The version you are reading is the edit that evidence dictated. The commodity explainer is compressed into the opening section, the implementation log and the live measurements lead, and every claim of experience now carries a date and a number. That loop, score, read the evidence, cut redundancy, add what only you can measure, is the same one we sell, which is why this article had to pass the same gate as everything else on the site.

What should a site owner do now?

Three moves, in order of certainty. First, keep winning the layer that is fetched: indexable, answer-first pages with accurate structured data, built to the perfect HTML page standard, because that layer is consumed today and WebMCP is not yet. Second, if your site has forms that complete a task, add the declarative attributes; it is a few attributes on markup you already have. Third, register imperative tools only for actions you would be happy to see an agent take unwatched, start read-only, annotate honestly, and join the origin trial so real agents can reach them when Gemini in Chrome arrives. The same restraint applies to the claim you make for it: WebMCP is an option on the agentic web, bought for an afternoon of work, not a ranking factor, and the position it shares with the Open Knowledge Format is that checker tools currently outnumber consumers. Publish it cheaply, measure it honestly, and revisit when the first mainstream consumer ships.

Not in a browser? Any MCP client can use the same tools today: add https://www.laurelinlabs.com/api/mcp as a custom connector in Claude, or claude mcp add --transport http laurelin-labs https://www.laurelinlabs.com/api/mcp in Claude Code, or POST JSON-RPC 2.0 by hand, starting with {"jsonrpc":"2.0","id":1,"method":"tools/list"}.