WebMCP vs MCP: when an agent should go through the browser
WebMCP gives an agent inside the browser structured tools on the page. A direct MCP server lets any agent call the service with no browser at all. I've built both. Here's when each one fits, with Shopify's checkout as the worked example.
I’ve built a few WebMCP integrations, and I’m still not sure about it.
The short version: WebMCP only makes sense to me when the agent is part of the browser, where you can watch and step in. When you work through chat, it feels unnatural. Why keep a browser involved when the agent can call the service directly? For a chat app, a desktop client, code or a job nobody watches, build a direct MCP connection. Shopify draws roughly the same line for its checkout.
WebMCP, browser-control tools and server MCP
WebMCP is a proposed web standard. The page registers tools, and the browser’s built-in agent calls them, so the agent doesn’t have to guess what a button does. Chrome runs it as an origin trial from Chrome 149, with a flag for local development, and says the API may still change.
Browser-control MCP tools are MCP servers that operate a browser by clicking and typing. The site declares nothing, so the agent reads the page and works out what each element is for. Chrome calls this actuation and describes WebMCP as the more reliable option.
Server MCP means the service exposes its own tools, for example over MCP’s Streamable HTTP transport, which streams with SSE. No browser is involved. An MCP client such as ChatGPT Desktop or Claude Code calls the service directly, from a chat or from code.
Chrome’s own comparison is clear that WebMCP doesn’t replace MCP. WebMCP tools exist only while the page is open. An MCP server is there whenever a client calls it.
What I found building both
The latest WebMCP integration I built let agents work on screenplay projects in a video web service, using the interface and the functions behind it.
It worked. But I ended up replacing it with a direct MCP connection. I could control projects from ChatGPT Desktop or Claude Code without keeping the web interface in the loop. In my workflow, I found it faster, and it used fewer tokens. Without the browser, it was also much easier to build automated agent workflows in code. I haven’t gone back to the WebMCP version.
The automation part follows from the design: code can reach WebMCP tools only through a browser that has the page loaded. A server MCP has no page to keep open.
Shopify checkout: two ways in
Shopify added WebMCP support to checkout on 2026-09-28. Browser agents can now read and update eligible checkouts, and submit them once the buyer confirms. Shopify’s docs describe this and a server option side by side.
Checkout WebMCP works on the checkout open in the buyer’s tab. It registers get_checkout, update_checkout and complete_checkout, plus navigate_to_storefront when the store has an online storefront. Before calling complete_checkout, the agent has to show the buyer the order and total and get their permission. Shop Pay login and payment challenges stay with the buyer, on the page. (Checkout WebMCP reference)
The tools only appear on eligible checkouts. Shopify lists the exceptions: B2B checkouts, embedded and mobile-SDK checkouts, checkouts with another shop’s merchandise, draft orders, order edits, payment collection, and the standard three-page checkout unless the buyer uses Shop Pay. update_checkout also leaves line items alone; the buyer changes those on the page. If you build on Shopify, check that list against your store’s checkout before planning around WebMCP.
Checkout MCP runs from your agent’s server and doesn’t depend on the buyer’s browser. It’s a JSON-RPC endpoint at https://{shop-domain}/api/ucp/mcp, and every request needs authentication or a signed request. When the buyer has to enter something or review the order, the agent hands them a checkout link to finish there. (Checkout MCP reference)
Shopify’s docs recommend Checkout MCP unless the agent has to run in the buyer’s browser. Either way, the buyer still approves the purchase.
Where this is heading
Long term, I think agent-native will become the standard. The UI, WebMCP and direct MCP should all work with the same underlying logic and state. People and agents can then use whichever interface fits, without rebuilding the workflow for each one.
Looks like Shopify is going this way too. Its WebMCP tools use the same state as the checkout UI, and both MCP options use the same checkout object. That’s the direction I’m most interested in.
A shorter version of this first appeared on LinkedIn on 2026-09-30.
On this page