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

What is WebMCP?

WebMCP (Web Model Context Protocol) is a proposed browser API that lets a web page declare a set of tools, each with a name, a description and a JSON Schema for its inputs, that an AI agent running in the browser can discover and call directly. It borrows the tool vocabulary of Anthropic’s MCP, which is how desktop assistants talk to servers, and moves it into the page itself. Instead of an agent guessing which button submits a form by reading the DOM or a screenshot, the page says: here is score_page_non_commodity, it takes a URL, call it and I will return the result.

The proposal is edited by Google and Microsoft engineers inside the W3C Web Machine Learning Community Group and is published as a Draft Community Group Report. That phrase matters: it is a draft from a community group, not a W3C Recommendation and not yet on the standards track.

How does a page expose tools to an agent?

There are two surfaces, and a site can use both.

The imperative API is JavaScript. The page registers tools on document.modelContext (the July 2026 draft moved it there from navigator.modelContext, which Chrome still exposes but deprecates), each with an execute function that runs in the page and returns a string. Tools carry annotations such as readOnlyHint, so an agent knows a call has no side effects, and untrustedContentHint, so it treats fetched third-party text as data rather than instructions. Registration accepts an AbortSignal, so tools can be withdrawn when a view unmounts.

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, each field can carry a toolparamdescription, and toolautosubmit lets the agent submit and navigate in one step. 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 hand a result back, and Lighthouse already audits pages 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 explicitly allows it.

Where does WebMCP stand in August 2026?

The honest summary, as of this article’s publication date: the specification is real and moving, the browser support is an origin trial, and measured consumption by agents outside demos is close to zero. The same sources that track adoption note that checker tools for WebMCP already outnumber implementations. That is the pattern early standards follow, and it is the same evidential position the Open Knowledge Format sits in.

Which tools does laurelinlabs.com expose?

Since 25 August 2026 every page on this site registers five read-only tools when a WebMCP-capable browser loads it, and the homepage score form carries the declarative attributes as well. In any other browser the registration is a no-op.

Each tool is annotated readOnlyHint, and the scoring tool is additionally marked untrustedContentHint because it returns text extracted from a third-party page. Nothing here writes data or spends money; that is a deliberate first scope.

Not in a browser? Connect to the Laurelin Labs MCP server

WebMCP only helps an agent that is already on the page. For everything else, the same tools are served as a remote MCP server at https://www.laurelinlabs.com/api/mcp (Streamable HTTP, no sign-in, read-only), which any MCP client can use today: Claude, Claude Code, Cursor, and the desktop assistants that speak the protocol.

The server exposes six tools: search_laurelin_labs, list_topic_hubs, get_knowledge_concept (the OKF bundle), get_latest (the build log), score_page_non_commodity and get_contact_details. Every tool is annotated read-only and idempotent; nothing writes, nothing spends. It is the same code that backs the in-page WebMCP tools, so the three agent layers on this site (schema for search engines, OKF for knowledge, MCP and WebMCP for actions) never disagree.

Why is it useful, and to whom?

For a site owner the value is precision. An agent that calls search_laurelin_labs gets the canonical URL of the right page in one step; an agent that scrapes the navigation gets whatever the DOM happened to expose, and may get it wrong. For a user the value is that tasks complete without the guessing: score this page, find the check about hreflang, tell me how to contact them. For the site’s answer engine optimisation the value is indirect but real: a page that can describe its own capabilities in typed, machine-readable form is a page an agent can trust to do what it says, which is the same trust the trust signals pillar is built on.

For a consultancy there is a second, quieter payoff. Writing tool descriptions forces you to say, in one sentence each, what your site actually does for a visitor. Most sites cannot. That exercise is worth doing even if no agent ever calls the tools.

How do WebMCP, OKF and Schema.org fit together?

They answer three different questions. Schema.org JSON-LD tells a machine what a page is and who stands behind it, and it is the one layer search engines actively consume today. OKF packages what the site knows as curated markdown with provenance, verification and freshness metadata, for agents that want knowledge rather than pages. WebMCP tells an agent what the site can do: the actions it can take on a visitor’s behalf. On this site the three are wired together on purpose: the get_knowledge_concept tool serves the OKF bundle, the bundle mirrors the pages, and the pages carry the schema.

What should a site owner do now?

Three moves, in order of certainty, and the same order as for OKF. First, keep winning the layer that is fetched: indexable, answer-first pages with accurate structured data, built to the perfect HTML page standard. Second, if your site has forms that complete a task (a quote, a booking, a search), add the declarative attributes; it is a few attributes on markup you already have, and Lighthouse will tell you where. Third, register imperative tools only for actions you would be happy to see an agent take without a person watching, start read-only, and annotate honestly. Register for the Chrome origin trial so you can test with real agents when Gemini in Chrome arrives. And keep the claim honest with clients: this is an option on the agentic web, bought for a few hours of work, not a ranking factor.