WebMCP: How Your Website Becomes a Tool for AI Agents

AI agents that do tasks in the browser have a perception problem today: they see websites as pixels and DOM trees, guess where to click, and fail silently on anything non-standard. WebMCP reverses the direction – the website tells the agent what it can do. We didn’t just read about it, we built it: six tools run in production on this site. This article explains the proposal and shares the hands-on experience.

The problem: agents guess instead of knowing

A browser agent asked to fill out a contact form on an unfamiliar website works like a very patient intern without an onboarding: take a screenshot, detect fields, click coordinates, hope. That works surprisingly often – and breaks silently on custom dropdowns, multi-step forms or unusual markup.

For website owners this means: whether an agent can operate your site is currently decided by the luck of your markup. WebMCP turns that into a deliberate decision.

The proposal: document.modelContext

WebMCP (Web Model Context) is a draft of the W3C Web Machine Learning Community Group, driven largely by Google and Microsoft engineers. At its core is a small JavaScript API:

document.modelContext.registerTool({
  name: 'lookup_glossary_term',
  description: 'Looks up a web development term in the glossary.',
  annotations: { readOnlyHint: true },
  inputSchema: {
    type: 'object',
    properties: { term: { type: 'string' } },
    required: ['term'],
  },
  execute: async ({ term }) => findInGlossary(term),
});

An agent-capable browser collects these registrations and offers them to the agent as tools – with name, description and parameters as a schema instead of a puzzle. If you know server-side MCP, you recognise the pattern: the same idea, except the website itself is the tool provider and nothing extra needs hosting.

The state of things (at publication of this article): the API runs in Chrome as an origin trial and already changed its namespace in summer 2026 – from navigator.modelContext to document.modelContext. That is the honest framing: a standard in the making, not a finished platform.

Our production case: six tools on this website

We didn’t want to write about the agent-ready web without operating it. Running in production on this site:

Tool	Type	Purpose
Contact form info	reading	Fields, required inputs and budget options as a schema
Prefill form	writing	Enters the user’s data into the form – submitting stays with the human
Open contact modal	UI	Opens the contact dialog with a prefilled subject
Glossary lookup	reading	69 terms with definition and citable URL
Services overview	reading	Offerings with public price anchors and page URLs
Maintenance plans	reading	The three plans with prices, response and service hours

The main lessons from building it:

1. Progressive enhancement is non-negotiable. Our integration is a complete no-op when document.modelContext is missing – no error, no performance cost, no behaviour change for normal visitors. That makes the investment risk-free: in the worst case, nothing happens.

2. Reading tools first. Five of our six tools are read-only (readOnlyHint: true). They answer the questions an agent wants to resolve for its user – what does this agency offer, what does maintenance cost, what does this term mean – with nothing that could go wrong. Writing actions need more care: our form tool fills in, but the human submits.

3. Structured data pays twice. The tools deliver the same prices and facts as the pages themselves, from the same central source. If you already maintain your content as data (instead of prose copies), registering tools takes minutes. If you don’t, your actual problem lies elsewhere.

4. An API change is priced in. The namespace move from navigator to document cost us one line, because registration lives in one place. With experimental APIs, that is precisely the design goal: one spot that changes – not twenty.

Security: public API surface, deliberately shaped

A registered tool is an invitation to third-party software. The rules we built by:

• Only what the UI can do. No tool does anything a visitor couldn’t do by clicking anyway. WebMCP is an accessibility layer for agents, not a back door.
• Nothing confidential. Tools deliver only public page content – structured, but not exclusive.
• The human keeps their hand on irreversible actions. Filling in yes, submitting no.
• Keep schemas strict. Tight input schemas aren’t pedantry here – they limit attack surface.

Is it worth it now?

Honestly: the measurable benefit today is small, because agent-capable browsers exist only as an origin trial and behind flags. If you only care about short-term effects, you can wait.

We see three reasons to build anyway: the cost is minimal (our six tools together took one manageable afternoon – because the data foundation existed). The risk is zero (no-op without the API). And the learning curve is real – whoever understands today how websites explain themselves to agents helps shape the pattern instead of catching up in 2027. It’s the same logic as all GEO measures: the website becomes machine-readable step by step, and every step stands on its own.

If you want to know how your website becomes agent-ready – from structured data via llms.txt to WebMCP tools: this is exactly the kind of foundation we build into our website projects.