Few weeks back, I walked you through building a UCP-compliant record store.

Agents could discover products, create checkout sessions, apply discounts, and complete purchases through a standard API.

That covered payments but agents still couldn't browse, search, or interact with the page before checkout.

They needed product IDs and prices upfront.

This week, Google shipped the WebMCP early preview and filled that gap.

With Claude in Chrome, Gemini in Search, Copilot in Edge, WebMCP lets you decide how they interact with your site.

UCP prevents lost sales at checkout.

You might be wondering, why not just wrap your existing endpoints in an MCP server?

The reason is that WebMCP runs inside the browser session with existing auth, cookies, and user context, and MCP is backend-to-backend.

Different entry points for different agent types.

I wired all three layers together on a concert ticket booking page.

If you’re an engineer or a tech professional, this edition is for you. Let’s get right to it.

Before we get into the setup, something worth flagging if you're a engineer, professional working in tech or want to get into it:

The schedule is as follows:

Day 1: 6th March | 7:00–11:00 PM
Developer Productivity, AI Agents & AI Assisted Coding w/Cursor & Claude.

Day 2: 7th March | 10:00 AM–2:15 PM
Agentic AI, Crew AI & Langraph Frameworks & Live Demo Of Real Agentic Workflows That Companies Use.

Day 2: 7th March | 3:00–6:00 PM
Orchestration, MCPs, Building Multi Agents Systems & Case Studies.

1. Compresr

Context compression API for LLM pipelines and agents. Drop it into your Claude Code or OpenClaw workflows and get up to 200x compression without quality loss, cuts token spend, reduces latency, and actually improves generation quality.

2. Castari

One-command deployment for AI agents built on Claude Agent SDK. It wraps your agent in a secure, auto-scaling sandbox with observability and an endpoint URL, basically Vercel for AI agents. Prototype to production in minutes, not weeks.

3. Canary

An AI QA engineer that reads your codebase, understands what your app is supposed to do, then tests it as a real user would. Push a PR, Canary reads the diff and runs end-to-end tests on real user flows.

Three things need to be running before any of this code works.

1. Chrome Canary with WebMCP enabled

WebMCP is currently only available in Chrome 146 Canary. Regular Chrome won't work.

Download Chrome Canary at google.com/chrome/canary. Once installed:

Your browser now understands navigator.modelContext.

Optional but useful: install the Model Context Tool Inspector Extension from Google.

It lets you see what tools are registered on any page, trigger them manually, and debug responses without needing an agent connected.

2. UCP mock server

The checkout code in this article talks to http://localhost:8182. That's the official UCP Python reference server from Google's sample repo.

Here's how to run it:

Prerequisites: Python 3.11+, and uv (pip install uv)

Verify it's running:

You should see a JSON manifest listing the checkout, discount, and fulfillment capabilities. That's the server the checkout tool handler in this article talks to.

CORS note: The checkout tool makes cross-origin requests from your concert page to localhost:8182. The UCP sample server doesn't send CORS headers by default.

For local testing, either serve your concert page from the same origin, or run the browser with --disable-web-security --user-data-dir=/tmp/chrome-dev (Canary only, never in production).

3. A mock concert backend

The WebMCP tools like checkAvailability, selectSeats, holdSeats, all call concert-specific endpoints that don't exist in the UCP repo. You need a thin local backend serving them.

Here's a minimal Express server that gives you everything:

Run it with:

Then update the fetch URLs in checkAvailability, selectSeats, and holdSeats from /api/concerts/... to http://localhost:3001/api/concerts/....

With all three running, the rest of this walkthrough will work end to end.

Add MusicEvent, Offer, MusicVenue, and performer markup to your concert listings:

An agent landing on this page understands the listing without parsing any HTML.

Notice this is on-page discovery. It tells agents what's here, not how to get here.

That distinction matters later.

Layer 2: WebMCP (interaction)

Your concert search form already exists for humans. Let's make it agent-callable.

Three attributes added.

The agent now calls searchConcerts("jazz", "Mumbai", "2026-03-15") as a structured tool call instead of guessing which input field maps to what.

Everything beyond search needs JavaScript. Register tools via navigator.modelContext.registerTool() :

The e.agentInvoked check is the key pattern. Same handler serves both agents and humans.

No separate endpoints needed.

The 10 minute hold on holdSeats is a deliberate constraint.

Seats are scarce resources with race conditions. The hold locks them while the agent completes checkout.

If it doesn't finish in time, they release back to inventory.

Layer 3: UCP (transaction)

Once seats are held, the agent pays. The checkout tool handler calls the UCP endpoints directly:

UCP validates the price server-side.

Try sending price: 100000 for a ₹1500 ticket, the server will reject it.

An agent can hallucinate a lower price so UCP ensures the merchant is always the price authority.

applyDiscount("EARLYBIRD") gives 15% off.

The allocations array maps every discount rupee to a specific line item so the agent knows exactly which tickets were discounted and by how much.

If the 10-minute seat hold expires before checkout completes, UCP rejects the transaction and the status stays incomplete.

Seats release to inventory and the agent needs to go back to holdSeats and start over.

Two protocols, one failure mode handled cleanly across both.

This requires Chrome Canary with the "WebMCP for testing" flag enabled, and the spec is still in W3C incubation, so registerTool() parameters and schema format are not finalized.

Expect the API surface to shift.

WebMCP implements the tools portion of MCP only, without prompts or resources, and UI sync is your responsibility.

When an agent calls holdSeats(), your seat map needs to reflect it visually for the human watching.

WebMCP handles tool execution, not UI updates.

If you want to prototype without waiting for Chrome stable, polyfills that convert WebMCP to JSON-RPC are starting to appear.

The stack we just built assumes agents already landed on your concert page.

Getting them there is a different problem, and none of these protocols solve it.

There's no WebMCP equivalent of sitemap.xml, no registry, and no crawl mechanism.

Agents discover your tools only after landing on your page.

Google, through Search and Gemini is the one who controls how agents reach pages. So this "open standard" still has a Google-shaped bottleneck at the top of the funnel.

Schema.org solved on-page search discovery in 2011, but agent distribution has no equivalent yet.

That's the missing layer beneath everything we just built.

Build the stack now, but know where your agent traffic comes from.

Until next time,
Vaibhav 🤝🏻

If you read till here, you might find this interesting

#Partner 1

Stop losing nuance when you type prompts. Wispr Flow captures your spoken reasoning, removes filler, and formats it into a clear prompt that keeps examples, constraints, and tone intact. Drop that prompt into your AI tool and get fewer follow-up prompts and cleaner results. Works across your apps on Mac, Windows, and iPhone. Try Wispr Flow for AI to upgrade your inputs and save time.

Try Wispr Flow

#Partner 2

HubSpot switched to Mintlify and saw 3x faster builds with 50% fewer eng resources. Beautiful, AI-native documentation that scales with your product — no custom infrastructure required.

Simplify Your Docs Today