Chrome Just Made Every Website an AI Agent API — Here's How to Build For It
Last week, Google dropped WebMCP into Chrome 146's early preview. If you haven't been paying attention, here's the short version: your website is about to become an API for AI agents — whether you planned for it or not.
I've been building for this moment since January.
What Actually Shipped
Chrome 146 introduces WebMCP — a protocol that lets AI agents discover and interact with website capabilities the same way they'd call a tool in an MCP server. Two flavors:
Declarative (HTML meta tags): You describe your site's capabilities in markup. Agents read it, understand what your site can do, and act accordingly.
<head>
<meta name="mcp:tool" content="search-products" />
<meta name="mcp:description" content="Search the product catalog by keyword, category, or price range" />
<meta name="mcp:param:query" content="string:Search keywords" />
<meta name="mcp:param:category" content="string:Product category filter" />
<meta name="mcp:param:maxPrice" content="number:Maximum price in USD" />
</head>
Imperative (JavaScript API): For dynamic capabilities — things that depend on user state, real-time data, or complex interactions.
if ('mcp' in navigator) {
navigator.mcp.registerTool({
name: 'check-order-status',
description: 'Look up current status of a customer order',
parameters: {
orderId: { type: 'string', description: 'The order ID to check', required: true }
},
handler: async ({ orderId }) => {
const status = await fetchOrderStatus(orderId);
return { status: status.current, eta: status.estimatedDelivery };
}
});
}
That's it. No separate API to maintain. No OAuth dance for basic read operations. The agent visits your page and knows exactly what it can do.
Why This Changes Everything (And I'm Not Being Dramatic)
Right now, when an AI agent hits your website, it's basically screen-scraping with extra steps. It parses your DOM, guesses at form fields, clicks around hoping for the best. It works — badly.
WebMCP flips that. Your site explicitly tells the agent: "Here are my capabilities. Here are the parameters. Here's what you'll get back." Structured, typed, discoverable.
Think about what this means for e-commerce alone. An agent shopping for a user doesn't need to simulate clicking through filters and pagination. It calls search-products with the right params and gets structured results. That's a 10x improvement in reliability and a 100x improvement in speed.
And here's the part most people are missing — this isn't optional. Chrome stable ships this month. Once it does, agents built on Chrome (which is... most of them) will start looking for WebMCP metadata on every site they visit. Sites that have it will get agent traffic. Sites that don't will get the same janky scraping that breaks every time you change a CSS class.
We Built the SDK Already
I started working on webmcp-sdk back in January when the spec drafts were circulating. Version 0.2.0 is Chrome 146 aligned and published on npm right now.
npm install webmcp-sdk
Four packages in one:
@webmcp/core — The base. Declarative tag generation, imperative API wrappers, capability manifests.
import { WebMCP } from 'webmcp-sdk';
const mcp = new WebMCP();
// Declarative: generates the right meta tags
mcp.declareTool({
name: 'search-products',
description: 'Search the product catalog',
params: {
query: { type: 'string', description: 'Search keywords' },
category: { type: 'string', description: 'Category filter' }
}
});
// Imperative: registers a live handler
mcp.registerTool({
name: 'get-cart',
description: 'Get current shopping cart contents',
handler: async () => {
return await cartService.getItems();
}
});
@webmcp/react — React bindings. Because if you're not using React in 2026 you're... actually maybe you're onto something, but most of us still are.
import { WebMCPProvider, DeclareTool } from 'webmcp-sdk/react';
function App() {
return (
<WebMCPProvider>
<DeclareTool
name="search-products"
description="Search the product catalog"
params={{ query: 'string', category: 'string' }}
/>
<ProductPage />
</WebMCPProvider>
);
}
@webmcp/security — Rate limiting, capability scoping, input validation. Because the first thing someone's going to do with WebMCP is try to get an agent to call your internal admin tools. Don't let them.
@webmcp/testing — Mock agent interactions. Test that your WebMCP declarations actually work before a real agent finds out they don't.
The Two Approaches — When to Use Which
Go declarative when: Your capabilities are static. Product search, content lookup, public data access. The meta tags are there on page load — zero JavaScript required, works even if the agent doesn't execute your scripts.
Go imperative when: Capabilities depend on context. Authenticated operations, real-time data, anything where the available tools change based on who's visiting or what state they're in.
Most real sites will use both. Declarative for the basics, imperative for the dynamic stuff. The SDK handles both through one consistent interface.
What You Should Do This Week
Seriously, this week. Chrome stable is imminent.
- Audit your site's core capabilities. What would an agent want to do on your site? List the top 5 actions.
- Add declarative meta tags for the obvious stuff — search, browse, read content. Takes 20 minutes.
-
Install
webmcp-sdkand wire up imperative handlers for anything dynamic. -
Add security scoping from
@webmcp/security. Don't skip this. Agents will probe every tool you expose. -
Test with
@webmcp/testingbefore Chrome stable drops and real agents start hitting your endpoints.
The gap between "agent-ready" and "agent-invisible" sites is about to become very visible in your analytics. The sites that prepare now will capture agent-driven traffic from day one. Everyone else will scramble to catch up.
npm install webmcp-sdk — and you're building for the agent web.
I'm Bill, co-founder at AI Agent Economy. We build open-source infrastructure for the agent web — wallets, payment rails, and now WebMCP tooling. Check out the webmcp-sdk on npm or follow @AgentEconomy for updates.
Top comments (0)