Guesswork
Inferring intent from labels, classes, and layout.
Observation trace
Google I/O Extended Nairobi 2026 · Agent-Ready Websites with WebMCP
Give agents tools, not DOM scraping.
Today, agents parse HTML, the accessibility tree, and screenshots — brittle, slow, and easy to get wrong.
WebMCP lets your site declare what it can do as structured tools on
document.modelContext. Agents see a contract, supply JSON arguments, and your code runs —
with the user still in control.
Without WebMCP vs with WebMCP
Same page action, two agent strategies. Play the simulation — scraping fumbles through the UI; WebMCP calls one registered tool with structured arguments.
Structured tool call
One registered tool — name, schema, arguments. Same contract as imperative registerTool.
Tool registry
0
Last invocation
Simulation only on this page. Live sites with real registerTool and declarative forms are linked below.
How WebMCP works
Three steps — whether you register tools in JavaScript or annotate HTML forms.
-
1
Your site registers tools
Declare actions an agent can take: name, description, JSON Schema, and an
executehandler — the same shape as server-side MCP tools. Use the Imperative API (registerTool) or the Declarative API (form attributes). -
2
The browser exposes them
A WebMCP-aware browser or extension collects tools from
document.modelContextand presents them to the user's agent — scoped to your origin, alongside the page URL and title. -
3
Agents call instead of guess
No more “find the right button.” The agent picks a tool, supplies structured arguments, and your handler runs — navigation, search, booking, content generation, or read-only lookups.
MCP vs WebMCP
Same tool contract — name, description, JSON Schema, and an execute handler. Different runtime: server-side MCP servers vs tools registered by the page in the browser.
| Aspect | MCP | WebMCP |
|---|---|---|
| Where it runs | Server or desktop — an MCP host connects to MCP servers | Browser tab — the open web page on your origin |
| Who provides tools | MCP servers (GitHub, Postgres, filesystem, custom APIs) | Your site via document.modelContext |
| Transport | stdio, SSE, or streamable HTTP between host and server | In-page JavaScript API; browser bridges tools to the agent |
| Tool shape | name, description, inputSchema, handler |
Same — imperative registerTool or declarative form attributes |
| Agent access | Agent connects to configured MCP servers as a client | Agent reads tools from the page the user has open |
| Best for | Backend data, files, APIs, long-running or offline jobs | User-facing actions — forms, search, filters, navigation, booking |
| User context | Server-side credentials and permissions | User session, cookies, and visible UI state on that page |
| Setup | Install and run an MCP server; wire it in your agent host | Add registerTool or WebMCP form attributes to your site |
WebMCP brings MCP-style tools to the web platform. Many agent flows use both — MCP servers for backend access, WebMCP for what the user is doing in the browser right now.
Two ways to register
Pick the API that fits your stack. Many sites use both — imperative tools for app logic, declarative forms for simple inputs.
JavaScript registerTool
Search, filters, navigation, state — anything your app already does in code. Full control over schema and execution.
document.modelContext.registerTool({
name: "sessions_search",
description: "Search public session listings.",
inputSchema: {
type: "object",
properties: {
query: { type: "string" },
room: { type: "string" }
}
},
annotations: { readOnlyHint: true },
execute({ query, room }) {
return { sessions: filterSessions(query, room) };
}
});HTML form attributes
Standard <form> plus WebMCP attributes — no JS wiring. The browser derives the tool schema from fields.
<form toolname="draft_content"
tooldescription="Create a content draft"
toolautosubmit>
<select name="topic"
toolparamdescription="Subject">…</select>
<select name="tone"
toolparamdescription="Voice">…</select>
<button type="submit">Generate</button>
</form>Where to build & test
Blackie Labs explains WebMCP. These companion sites ship both imperative and declarative tools — fork them for your own event or product.
Declarative API
AgentReady Content Studio
HTML forms with toolname and toolparamdescription — social posts, speaker intros, no extra JS.
I/O Extended Nairobi Travel
registerTool for session search, speaker lookup, schedule building, and navigation — full agent-ready event site.
API surface at a glance
The platform hook is document.modelContext (also exposed on navigator.modelContext in some builds).
registerTool(def, opts?)- Imperative — register a tool with schema and
execute. Pass{ signal }to unregister on teardown. getTools()- Inspect what the page exposes — use DevTools WebMCP panel or extensions during development.
toolname·tooldescription- Declarative — on
<form>. Names the tool and tells agents when to use it. toolparamdescription·toolautosubmit- Declarative — per-field schema hints; optional auto-invoke without a submit click.
Ship responsibly
- Register only tools you intend agents to invoke — treat the registry like a public API.
- Use
readOnlyHintand avoid PII in tool inputs on public pages. - Validate schemas and tool output in Chrome DevTools WebMCP inspector.
- Progressive enhancement — pages work normally when WebMCP is unavailable.
Session script · ~10 min
- Hero — WebMCP: tools on
modelContext, not DOM scraping. - Play comparison — observation trace vs structured tool call.
- MCP vs WebMCP table — same contract, server vs browser.
- Timeline + two APIs — imperative vs declarative registration.
- DevTools on Travel demo (
registerTooltools). - AgentReady Studio declarative forms + safety.
Explain WebMCP here. Ship tools on the demos.
Inspired by the Chrome Labs explainer — tailored for GDG Nairobi with both imperative and declarative examples.