Google released WebMCP this week, a new Chrome API that lets websites declare structured tools for AI agents instead of forcing them to actuate the UI visually. We shipped it on 38shift.com the same day.
What follows is the implementation, the trade-offs we made, and the strategic argument for any team whose product is about to be navigated by agents whether they instrument for it or not.
At a glance
- —Six tools live on 38shift.com today: list_insights, get_insight, list_case_studies, get_case_study, list_services, contact_38shift.
- —About 350 lines of code across four files. Feature-detected, so non-WebMCP browsers see no behavior change.
- —Available behind Chrome's chrome://flags/#enable-webmcp-testing flag now, and in Chrome 149's origin trial once it ships.
- —Spec reference: developer.chrome.com/docs/ai/webmcp.
What WebMCP actually is
Until now, agents that visited a website did the same thing humans did. They actuated the UI: clicked through the DOM, read rendered text, simulated keystrokes, inferred what the page meant from the way it looked. The approach works, sort of, but it is slow, brittle, and produces failure modes a human would never produce.
WebMCP changes the contract. A site declares a set of structured tools, each with a name, a description, an input schema, and a handler function. The browser surfaces those tools to any agent running in the page. The agent calls the tool directly. The site responds with whatever the tool returns. No visual actuation, no DOM scraping, no guessing.
The closest analogy is REST APIs for the agent layer. Tools are declared by the site, scoped by Permissions-Policy, and discoverable through a standard surface on navigator.modelContext. Two implementation paths are offered: imperative JavaScript registration, and declarative annotations on HTML form elements.
What we shipped
Six tools, scoped to the parts of 38shift an agent would plausibly want to interact with.
- —list_insights returns the catalog of insight articles with slug, title, date, read time, and subtitle.
- —get_insight takes a slug and returns the full article rendered as markdown.
- —list_case_studies and get_case_study return the same shape for work projects.
- —list_services returns the seven services on the homepage.
- —contact_38shift takes a purpose and optional context, and returns the contact email plus a scaffolded draft message.
Each tool returns markdown rather than raw JSON. The reasoning is practical: agents read markdown well, the inspector extension surfaces it cleanly, and a developer debugging a tool output gets a human-readable response in one read. JSON serialization is a step away if a downstream pipeline ever needs it.
The four files
The whole implementation is four files plus a one-line config change.
types/webmcp.d.ts declares the ambient TypeScript types for navigator.modelContext. Chrome has not published types yet, and type-safe registration matters when the surface is this new. Ambient declarations augment the global Navigator interface so every consumer gets autocomplete and compile-time checks.
lib/webmcp-tools.ts is the pure registry. It imports the existing insight and work data, builds markdown renderers for each shape, and exposes a single registerWebMcpTools(modelContext, signal) function. The signal lets the React lifecycle abort registration cleanly on unmount.
components/webmcp-provider.tsx is a 20-line client component that feature-detects the API and calls the registrar. Mounted once in app/layout.tsx, it registers on initial page load and stays for the session. Non-WebMCP browsers hit the early return and the component renders nothing.
next.config.mjs gets a single addition: tools=(self) in the Permissions-Policy response header. The default policy is self-only anyway, but explicit declaration documents the security posture and survives any future browser default changes.
What we deliberately did not do
WebMCP's Declarative API is elegant. Drop toolname and tooldescription attributes onto a form element and the browser auto-registers it as a tool. Field-level annotations like toolparamtitle and toolparamdescription refine the schema. For sites with rich forms, this is the right pattern.
Our /contact page is intentionally not a form. It is a curated email handoff: a clear address, social links, a paragraph on what to include in the first message. Forcing a form onto the page to make WebMCP happy would have broken the human experience to serve the agent experience.
Instead, we exposed a contact_38shift tool imperatively. The agent passes a purpose and optional context. The tool returns the email address plus a scaffolded draft built around those inputs. The agent surfaces that draft to its user, who reviews and sends it. The agent affordance matches the human affordance. We did not force one to mimic the other.
Why we shipped this fast
Three reasons.
First, the spec is in origin trial. Chrome 149 will open broader testing, but the API is live behind a flag today. Early shippers get a feedback loop with the working group and a head start on the patterns that will define how this spec gets implemented across the industry.
Second, the site that instruments first becomes the agent-readable default route for its category. Search engines spent two decades teaching brands that the first to instrument structured data earned the rich-result real estate. Agentic browsing will replay the same dynamic on a faster timeline.
Third, the work is bounded. About 350 lines of code across four files. No runtime risk for browsers that do not support the API. No new auth surface. No persistent server-side state. The blast radius of being wrong is small.
The strategic argument
Agents are about to navigate your product whether you instrument or not. ChatGPT's browsing stack, Perplexity's Comet, Claude's browser extensions, and Gemini's agent runtime are all converging on the same pattern: the agent reads the page on the user's behalf and takes action. The question is not whether they will visit. The question is how cleanly they can use what they find.
An instrumented site responds to a query like 'show me their insights on GTM Engineering' with the actual article, returned as structured content with provenance. An uninstrumented site responds with whatever the agent can extract from a rendered DOM, parsed by a model that does not know which div is the article body.
The difference compounds when the agent is mediating a transaction. 'Find me a consultancy for AI growth engineering and start a conversation' is a query that does not work well on an uninstrumented site. The agent has to guess at the contact form, guess at field semantics, guess whether submission worked. On an instrumented site, the agent calls contact_38shift, the site returns the email and a draft, the agent hands it to the user, and the loop closes.
What this is not
WebMCP is not a moat. It is open, every site can ship it, and the work takes a day. Anyone reading this article can have the same surface live on their product by end of week.
What it is is a muscle. The brands that ship first build the patterns: which tools to expose, how to scope them, how to handle the trade-offs between Declarative and Imperative, how to keep the agent affordance aligned with the human affordance. Six months in, those patterns are codified, the operators know them, and the late shippers are still figuring out their first tool registration. Same dynamic as responsive design in 2012. Same dynamic as structured data in 2015. The late teams catch up. They just spend more to do it.
What we will be watching
A few open questions.
Spec stability. The Chrome doc explicitly notes the API is subject to change. We are tracking the working group on GitHub and will adapt our tool definitions if names or signatures shift.
Browser convergence. Safari, Firefox, and Edge will eventually have to either implement WebMCP, propose alternatives, or cede the agent-readable web to Chromium. None has signaled yet.
Agentic ranking. Whether instrumented sites get prioritized in agent-mediated tasks (book me a table, find me a consultant, subscribe me to that newsletter) is the agentic-SEO question. The answer probably depends on whoever ships the dominant agent runtime.
Tool composition. The fact that one tool can call another, or that an agent can chain six tools in a single user turn, opens design questions we have not yet had time to think through.
The takeaway
WebMCP is live on 38shift today. If you are building a product that will be navigated by agents in the next 18 months, the operative question is not whether to instrument. It is how fast.
We will publish a follow-up once the API stabilizes and we have data on agent usage. Until then, the spec is at developer.chrome.com/docs/ai/webmcp, and the patterns above are running in production on this site today.