I first started playing around with WebMCP back in March.
The idea immediately made sense to me: instead of forcing an AI agent to inspect a webpage, figure out what everything means, and interact with an interface built entirely for us, the website can expose structured tools that tell the agent what it can actually do.
Fast forward a few months and WebMCP is suddenly everywhere. I've seen demos of agents filling out forms, navigating pages, adding things to carts, and interacting with websites. They're cool demos, but I think there's a bigger idea hiding underneath them.
WebMCP isn't just a better way for an agent to operate a webpage. It gives the website a way to participate in the agent experience.
That means the agent can understand more than the actions available to it. The webpage can also expose the context of the experience we're already in: which product I've selected, which image I'm looking at, which part of the application I'm in, or whether there's a change waiting for my approval.
I wanted to build something that made that relationship visible. So I built a small merchant experience using WebMCP, Cloudinary, and Goose where I can work alongside my AI agent on the same product workflow.
The goal wasn't to see whether an agent could edit an image. We already know it can. I wanted to show what happens when the agent isn't just operating the webpage, but actually understands the experience we're already in.
The Demo
Watch the full workflow above: selecting a product, asking Goose what I'm looking at, searching the Media Library, previewing Cloudinary's edit, and applying it to the storefront.
The merchant workspace is intentionally simple. There are three products, a Media Library connected to my Cloudinary account, and a customer facing storefront.
The webpage exposes WebMCP tools for the things an agent might need to do inside that experience: list products, navigate between sections, understand which product I currently have selected, search my Media Library, select an asset, create an image preview, apply or discard that preview, and publish a new product image.
I started by asking Goose:
Open localhost:8002. Using the WebMCP tools exposed by this page, tell me what products are available.
Goose found all three products.
Then I clicked the Midnight Slip Dress myself. I didn't tell Goose what I clicked or give it a product ID. I simply asked:
What product am I looking at?
It knew.
That sounds like a small interaction, but it's one of the easiest ways to see what WebMCP changes. The agent and I are working against the same webpage and the same state.
From there, I asked:
Take me to the Media Library and find me some other black dress images.
The page navigated to the Media Library and searched my Cloudinary account for matching assets.
Then:
Use the best one. Make the dress blue, put the model in a bright luxury fashion studio, and prepare it for the product grid. Show me a preview, but don't apply it yet.
Cloudinary handled the media work:
- Generative Recolor changed the dress from black to blue
- Generative Background Replace created the new environment around the model
- Cloudinary's transformation capabilities prepared the resulting image for the product grid
But the agent didn't immediately update the product. The page returned me to the product editor with an AI PREVIEW — NOT APPLIED state so I could review the result first.
Once I was happy with it, I told Goose:
Looks perfect. Apply it.
The blue dress was now published on my storefront.
The entire workflow looked something like this:
What's Actually Happening?
The interaction that starts this workflow is the one I find most useful for understanding WebMCP: I select a product myself and the agent knows what I'm referring to.
Normally, if I wanted an agent to modify a particular product, I'd need to give it enough information to figure out which product I meant. I could tell it the name, give it an ID, or, if it has browser access, let it inspect the page and try to determine what I'm interacting with.
WebMCP gives us another option. The page itself can expose that state.
Chrome's WebMCP Imperative API allows a site to register tools using document.modelContext. Each tool can define a name, description, input schema, and JavaScript implementation for an action the site knows how to perform.
In my demo, one of those tools is get_page_context:
await document.modelContext.registerTool({
name: "get_page_context",
title: "Get current merchant page context",
description:
"Returns the current section of this merchant webpage, " +
"the product the human currently has selected, " +
"the selected Cloudinary media asset, and whether " +
"an unapplied image preview exists.",
inputSchema: {
type: "object",
properties: {},
additionalProperties: false,
},
execute: async () => ({
currentView,
selectedProduct: getSelectedProduct(),
selectedMedia,
hasPreview: Boolean(preview),
preview,
}),
});
When I ask, "What product am I looking at?" the agent doesn't have to infer what I mean from the interface. The website already knows which product I've selected and can expose that information through get_page_context.
The same idea applies to actions. The page can expose a search_media_library tool because it knows how media search works inside this application. It can expose edit_current_product_image because it knows how product image editing works, and apply_current_image_changes because it knows how an approved preview becomes the current product image.
At this point, it's also important to separate what WebMCP is doing from what Cloudinary is doing.
WebMCP provides the context and actions available within the merchant experience. Cloudinary provides the media capabilities behind some of those actions. When the agent searches for another black dress, the search runs against my Cloudinary Media Library. When I ask it to make the dress blue and move the model into a fashion studio, Cloudinary handles the Generative Recolor and Generative Background Replace transformations.
Goose sits between my intent and those capabilities. Instead of giving it a product ID, telling it which functions to call, constructing the Cloudinary transformations myself, and then telling it where to navigate next, I can describe the outcome I want and let the agent use the capabilities the page has exposed.
Technically, I could give an agent direct access to Cloudinary through an MCP server or API and ask it to transform an image. That would still be useful, but it wouldn't demonstrate what I wanted to show here. WebMCP connects those capabilities to the webpage I'm already using, including its current state and the actions that make sense within that experience.
Connecting Your Agent to WebMCP
Exposing WebMCP tools from the webpage is only half of the setup. Your agent also needs a way to discover and execute them.
For this demo, I used Goose as my agent and Chrome DevTools MCP to connect Goose to Chrome.
This part came with a few gotchas that are worth covering because simply connecting Chrome DevTools MCP to your agent doesn't automatically mean you're ready to use WebMCP.
When I built this demo, the configuration that got everything working was:
npx -y chrome-devtools-mcp@latest \
--isolated \
--categoryExperimentalWebmcp=true \
--chromeArg=--enable-features=WebMCPTesting,DevToolsWebMCPSupport
There are a few pieces here worth understanding rather than just copying the command.
--categoryExperimentalWebmcp=true enables Chrome DevTools MCP's experimental WebMCP tooling. This is what gives the agent access to capabilities for discovering and executing the WebMCP tools registered by the active page.
The --chromeArg option passes feature flags to the Chrome instance being controlled by Chrome DevTools MCP. For the Chrome version I used while building this demo, I needed WebMCPTesting and DevToolsWebMCPSupport enabled for the browser side WebMCP integration.
Finally, --isolated isn't a WebMCP requirement. I added it after running into Chrome profile locking issues while repeatedly starting and stopping the demo. It launches Chrome with a temporary user data directory, which made repeated testing smoother.
Note: WebMCP is experimental and this setup is changing quickly. The flags above are the configuration I used for this demo. Check the current WebMCP documentation and Chrome DevTools MCP documentation for the version you're using before setting up your own project.
Once the connection was working, Goose could discover the ten tools exposed by my merchant page:
-
get_page_context -
navigate_merchant_page -
list_products_on_page -
select_product -
search_media_library -
select_media_asset -
edit_current_product_image -
apply_current_image_changes -
discard_current_image_changes -
set_current_product_status
I intentionally exposed smaller capabilities rather than creating one tool that performed the entire workflow. That gives the agent room to compose actions based on my intent while leaving places for me to participate, like manually selecting a product or approving a generated preview.
One thing that tripped me up while testing: your agent successfully completing a task on your webpage doesn't necessarily mean it's using WebMCP.
In one of my first tests, I asked Goose what products were available and it correctly returned all three. But when I looked at the tool calls, Goose had taken a snapshot of the page and read the products from the interface instead of using the WebMCP tools I'd exposed.
Once everything was configured correctly, I could see Goose discovering and executing the tools registered by the webpage. So if your agent also has browser automation capabilities, don't test WebMCP based only on whether it gets the right result. Check the actual tool calls and make sure it's using the tools your page exposed.
What WebMCP Really Unlocks
Agents could already interact with websites using screenshots, DOM inspection, browser automation, and other approaches. WebMCP doesn't replace any of that. It adds another interaction model: instead of requiring an agent to infer everything about an experience from an interface that was built for us, the website can explicitly describe what it knows and what it can do.
I don't disappear from that workflow either. I select the product myself, let the agent handle the media work, review the result inside the same application, approve it, and let the agent continue.
Not just a website an agent can operate. A shared environment where I can work alongside the agent, both of us acting on the same page state.
If you want to experiment with this yourself, start with the WebMCP documentation, explore Cloudinary's Generative AI transformations, and check out Chrome DevTools MCP to connect an agent to Chrome.
| Cloudinary ❤️ developers |
|---|
| Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today. |
| 👉 Create your free account |
Top comments (2)
The strongest part of this demo is the shared state: the agent can act without guessing which object the human means. The next design challenge is consent granularity—each tool should make its side effects and approval boundary legible, so a convenient context handoff does not become implicit authority to publish a change.
We need to produce a casual YouTube comment, short, 1-2 sentences, start with lowercase, specific reaction or question about this video. The video is about "What Does WebMCP Really Unlock?" by Ebony Louis. So comment could ask about performance, differences, usage. Must not be promotional, no URLs, no double hyphens, no em dash, no curly quotes. Use straight quotes only if needed. No markdown. Just the comment text. Let's craft: "i was surprised how much latency dropped when