Your Website Just Became an API
WebMCP, Chrome 146, and the end of 'I should build an API'
Chrome 146 shipped something behind a flag that most developers scrolled past. An early preview of WebMCP — Web Model Context Protocol.
Here’s what it does: it lets your website tell AI agents exactly what actions are available, what inputs they need, and what outputs to expect. Not by scraping your DOM. Not by reverse-engineering your forms. By exposing structured tool definitions directly in the page.
Your website just learned to talk to machines. And machines are about to become your biggest user base.
The Two Bad Options We’ve Been Living With
Until now, AI agents had two ways to interact with websites, and both were terrible.
Option one: automation. The agent loads your page, reads the DOM, finds something that looks like a search box, types into it, clicks something that looks like a submit button, and prays the layout didn’t change since last Tuesday. This is how browser automation has worked for twenty years. It’s fragile, slow, and breaks whenever you A/B test a button color.
Option two: APIs. Structured, reliable, fast. Also: most websites don’t have one. And the ones that do rarely expose everything available through the UI. Your travel site might have an API for searching flights but not for selecting seats or adding bags. The agent hits a wall exactly where the user experience gets interesting.
WebMCP is the third option nobody had: let the website itself declare its capabilities in a format agents can consume, without building a separate API.
How It Actually Works
WebMCP provides two layers:
Declarative: HTML annotations on your existing forms. A checkout form gets metadata describing its fields, validation rules, and expected outcomes. An agent reads the annotation and knows exactly how to fill the form correctly on the first try.
Imperative: JavaScript APIs for dynamic interactions. Your site registers tools — bookFlight(), searchProducts(), checkout() — with JSON schemas defining inputs and outputs. Tools can appear and disappear based on page state. A checkout tool only shows up when there are items in the cart.
Think of it like this: APIs are a side door built specifically for machines. WebMCP is your front door, fitted with a translator so machines can use it too.
The spec is co-authored by Google and Microsoft engineers and incubated at the W3C. Broader browser support is expected by late 2026.
Why This Changes the Solo Builder’s Calculus
If you’re a one-person operation, you’ve probably had this thought: “I should build an API.” Followed immediately by: “I do not have time to build an API.”
WebMCP changes that math. Instead of maintaining a separate API with its own auth, rate limiting, documentation, and versioning, you annotate the product you already have. Your website IS the API. Same codebase. Same deployment. Same interface — just machine-readable.
For an indie SaaS, this means:
Your booking tool becomes agent-accessible without building a REST endpoint
Your checkout flow becomes programmable without Stripe API integration beyond what you already have
Your search becomes a tool agents can call with structured queries instead of fumbling through your autocomplete
The effort is closer to adding Schema.org markup than building a full API. Except instead of helping Google index your content, you’re helping agents use your product.
The Convergence Nobody’s Talking About
Here’s what makes the timing unusual: WebMCP and Mastercard’s Verifiable Intent launched within days of each other.
WebMCP answers “how does an agent interact with your website?”
Verifiable Intent answers “how do you prove the human authorized what the agent did?”
Together, they form the complete loop:
Agent discovers what your site can do (WebMCP)
Agent executes an action with cryptographic proof of authorization (Verifiable Intent)
Transaction is recorded with a tamper-resistant audit trail
That’s not a collection of unrelated announcements. That’s infrastructure. The kind that turns “agents might buy things someday” into “agents are buying things now, with receipts.”
Google is on both sides of this. They co-authored WebMCP and endorsed Verifiable Intent. Microsoft co-authored WebMCP. Mastercard open-sourced the trust layer. The majors are aligning on the same stack, in public, at the same time.
When that happens, the window for “should we care about this?” closes fast.
What to Do This Week
You don’t need to implement WebMCP today — it’s behind a Chrome flag and the spec will evolve. But you should start thinking about your product through this lens:
Audit your user-facing actions. What can a human do on your site? List every action: search, filter, add to cart, book, subscribe, configure. Each one is a potential tool definition.
Think in inputs and outputs. For each action, what does it need and what does it return? That’s your future JSON schema. The cleaner your data model is now, the less work WebMCP adoption will be later.
Watch the W3C incubation. The spec will change. The principle won’t. Websites that can describe their own capabilities to machines will get more traffic than websites that can’t. That’s the direction. The details will sort themselves out.
The web was built for humans who read and click. It’s being rebuilt for agents that call functions and verify results. The builders who see that shift early will own the transition.
Everyone else will wonder why their traffic disappeared.