What happens when websites start talking to AI agents?

WebMCP is a proposed web standard that lets a website expose its capabilities directly to AI agents. Instead of making an agent visually reverse-engineer how the site works, the site can just tell it what's possible: search products, check inventory, configure an item, add something to a cart, upload artwork, check an order status, make a reservation, submit a form.

The agent doesn't need to know where the "Add to Cart" button sits or what color it is. The site can offer a structured capability for adding to the cart. Google's Chrome team describes WebMCP as a way for sites to expose structured tools that agents can invoke directly, with the goal of making those interactions more accurate and reliable than simulating mouse clicks and keystrokes.

Today we design a website for its human interface: buttons, forms, menus, search boxes, product pages. WebMCP adds the idea that a site can also have an interface for agents. A person sees "Check Order Status." The agent sees something more like "get order status using an order number." Same site, same underlying functionality, two ways in.

This isn't about tearing out your website and rebuilding it for AI. Chrome frames WebMCP as a progressive enhancement to an existing site. Humans still get the website they always had; agents get a cleaner way to understand it.

That's one option, and browser automation has been around for years. AI makes it far more capable because it can reason about what it's looking at. But anyone who's built browser automation knows the catch: interfaces change. A button moves, a field gets renamed, a modal pops up, the navigation gets reworked, and what ran yesterday breaks today. Even a smart agent is still interpreting an interface meant for a person.

WebMCP flips that. The site describes the actions an agent can take, directly. The proposal uses examples like booking a flight or making a restaurant reservation through the site's own functionality instead of forcing an agent through a brittle chain of screenshots, scrolling, and simulated clicks. That's much closer to software talking to software.

If you've been following AI infrastructure, you've probably run into MCP, the Model Context Protocol. MCP gives AI systems a standard way to interact with external tools and data. A company might stand up an MCP server that lets an assistant search its database, pull a customer record, or create something in a business system.

WebMCP applies the same idea to the web. Roughly: MCP gives an AI access to tools provided by some other system, while WebMCP lets the website you're actually on expose tools directly to the agent using it. You don't need the architecture to get the point. Agents shouldn't always have to figure out what software can do when the software could just tell them.

Our industry is full of software that works fine for humans and is miserable for other software to work with: supplier sites, distributor storefronts, order management platforms, company stores, decorator portals, shipping systems, product configurators. A lot of them have limited APIs, APIs locked to certain customers, or nothing worth calling an API at all. That's always been a ceiling on automation.

When I want to automate something today, I run down the same short list. Is there an API? A Zapier integration? A data feed I can pull? Can I automate the browser? Sometimes the answer to all of it is no.

WebMCP opens another door: what if the site itself exposed the actions that matter? Picture pulling up a supplier site and having your assistant ask it to find a navy polo under $30, check inventory in XL and 2XL, list the available decoration locations, price it at 72 pieces, and drop those products into a project. Or a company store where someone says, "order the same onboarding kit we bought for Sarah last month, but ship this one to our new hire in Denver." The agent might need to gather pieces from several systems to pull that off, but when it reaches the storefront, it wouldn't have to shop the store like a person. The store could just expose the tools needed to place the order.

We've been down a version of this road before. PromoStandards exists because we got tired of every supplier publishing product, inventory, and order data in its own shape. WebMCP is a different mechanism, but the instinct behind it is the same: make it easier for one piece of software to work with another.

So let me do a little vision casting.

Imagine commonsku exposed WebMCP tools right on the pages you already work in. You're in a project and you tell your assistant to add three products from a supplier, apply your standard margin, and build the presentation. It doesn't click around the way you do. It calls "add product to project," "set margin," and "generate presentation," and the work is done.

Now imagine the supplier sites did the same. You ask for a navy polo under $30, in stock in XL and 2XL, priced at 72 pieces with a left-chest embroidery. Instead of bouncing between SanMar, S&S, and alphabroder and reading three different inventory tables, your assistant asks each site the same question and hands you back a clean comparison.

Then extend it to your storefront platform, your order desk, and your decorator's portal. A reorder that today means logging into four systems becomes a single request that each one already knows how to fill.

None of this exists yet, and I'm not saying commonsku or anyone else is building it. But it's the kind of future WebMCP points at, and it's worth picturing, because the tools that make themselves easy for an agent to use are the ones distributors will reach for first.

It'd be easy to read WebMCP as "we won't need APIs anymore." I don't buy that. APIs, MCP servers, integrations, webhooks, and automation platforms are all still the plumbing that holds business systems together.

WebMCP fills a different gap. There are plenty of moments where an agent is already on a site acting as the user. They're logged in, the site already knows their permissions, their pricing, their preferences, their session. Rather than making the agent leave all that behind to go connect to a separate integration, the site can expose some of its capabilities right there. That could make the browser itself a much more interesting place to automate.

For years now, companies have poured money into user experience. How easy is the site to navigate? How fast can someone find a product? How many clicks to check out? A new question may end up sitting right next to those: how easy is our software for an AI agent to use? Call it agent experience.

A site that's great for humans can still be terrible for agents. And as more customers hand work off to AI assistants, that gap starts to cost something. Take two suppliers with basically the same products. One makes an agent crawl six pages, interpret a configurator, scrape inventory out of a table, and fight through checkout. The other tells the agent how to search, how to check inventory, how to configure decoration, and how to place an order. The agent is going to have a much easier time with the second one, and that could turn into a real advantage.

WebMCP is a proposed standard, not something every browser and website supports today. The work is happening through the W3C Web Machine Learning Community Group, and Chrome currently treats its WebMCP support as experimental. So no, don't go asking your e-commerce provider when they're adding it.

But I'd watch the direction, because WebMCP is one piece of a bigger change. We've always built software assuming a person would be sitting in front of it. Now we're starting to build it knowing the "user" is sometimes an AI agent acting on someone's behalf, and that quietly rewrites a lot of assumptions about how software should work.

I've written before about how much context matters in AI. The most useful systems won't just have a strong model behind them; they'll understand your customers, products, margins, suppliers, workflows, permissions, inventory, and order history. But context is only half of it. An agent also has to be able to do things: search, price, create, update, place an order, pull a status.

What makes WebMCP interesting is the suggestion that some of those abilities may eventually live right inside the sites we already use. The web we've known was built for people clicking links. The next version may also be built for agents calling tools. If that happens, "does your software have an API?" won't be the only question worth asking. We'll also start asking: can my AI use it?