WebMCP and the Agent Economy: the visitor isn't human anymore.

I've spent the last few weeks testing WebMCP in multi-context setups, and the part that keeps pulling me in isn't the spec. It's how it changes the conversation between me and an AI agent. The agent follows faint signals, the kind a search box would drop on the floor, and lands precisely on the blog posts and case studies that match what I actually need. The deeper I go, the more it feels like every relationship, person to person or system to system, is a running act of semantic reconciliation: two sides continuously checking that they mean the same thing.

And that's what made me look up from the protocol and notice something bigger.

The internet's one business model is breaking

For twenty years, the commercial internet had exactly one way to make money: bring people in, get them to look, get them to click. Ads, email captures, affiliate links, checkouts. Every one of them assumes the thing arriving at your site is a person.

That logic is breaking. Not because traffic is falling, but because what's arriving is no longer a person.

Look at that last bar again. The old contract of the open web was simple: a crawler takes your content, the search engine sends you a visitor, the visitor pays with attention. Now an agent reads the page, uses the answer, and the visit never happens. The website still paid all the costs. It just never received the attention it used to get paid in.

This is the paradigm shift I'd watch for the next two years: from an attention economy to a resource-usage-rights economy. Cloudflare is already building the toll booth for it (more on that further down), and the report I'm sharing at the end of this post is about the business side of that shift.

But for those of us who build products, I don't think the opportunity is in the protocol itself. It's in this chain:

Most of this post is about the middle link, the interface, because that's the one you can build today. It's called WebMCP, and to understand why it matters, start with how we design websites now.

A new kind of visitor

When we design a website, we assume the visitor is a person. They'll open a page, read a bit, click a button, fill in a form, and eventually buy something, sign up, or finish whatever they came to do. So that's what we've spent years optimizing: navigation, CTAs, conversion, SEO, landing pages, user flows.

The numbers above say that assumption is already wrong more often than it's right. The next visitor to your site might be an AI agent, and it probably isn't there to browse. It's there to get something done: find this brand's most recent posts, compare three products on price, check inventory, figure out which posts performed best over the last 30 days, create a campaign, book an appointment, pull a specific number.

Which raises an obvious question. If an agent wants to use your product, should it really have to click through it one button at a time, the way a human would?

This is where WebMCP starts to get interesting.

WebMCP in one sentence

The way I currently understand it:

A normal product has a set of screens that humans learn to navigate. A product that supports WebMCP has those same screens, plus a second layer it can hand to an agent:

How agents used to operate a website

Before this, an agent that wanted to operate a normal website had a few options, and none of them were great.

The most primitive is Computer Use: the model looks at a screenshot, finds the button, clicks it, finds the input, types into it, clicks Submit. It's imitating a human. That's impressive to watch, but it's slow and it's fragile. What happens when a button moves? When a modal pops up? When the page loads slowly? When you ship a redesign? The agent very likely gets stuck.

Browser automation is one step smarter. Instead of a screenshot the agent reads the DOM, so it knows there's a <button>Create Campaign</button> on the page and can act on it more precisely. But it's still doing the same thing at heart: operating the UI, rather than calling the product's actual capabilities.

What WebMCP changes

Say I have a product called Creator OS. If an AI wanted to find my best-performing YouTube content from the last month, the old route runs through my interface: open Creator OS, go to Analytics, pick YouTube, pick Last 30 Days, sort by performance, read the table. With WebMCP it makes one call. Try both below.

Notice what happens after the tool returns. The AI can finally spend its effort on the part that matters, the analysis, instead of on finding the date picker. That's the value I care about. WebMCP isn't “making AI better at clicking websites.” It's letting AI use the website's actual capabilities.

Does your site actually need it?

I want to say this early: not every website needs WebMCP. If your site is Home, About, Portfolio, Contact, its job is to be read by people, and bolting on twenty tools to chase a trend would be silly.

It's a different story if your product has data, search, content, user accounts, analytics, workflows, campaigns, inventory, bookings, orders, files, or actions. Those things already are capabilities an agent could use.

Take an e-commerce platform. Today, to answer “which product sold best recently?”, you go Dashboard → Analytics → Products → Last 30 Days → Revenue → Sort. If the platform exposes get_top_products, the agent just asks. Then you keep talking. “Which three are almost out of stock?” → get_low_inventory. “Set up a promotion campaign for those three, but don't publish yet.” → create_campaign.

At that point the AI has stopped being a chatbot. It's become a product operator.

Two interfaces, one product

This is also why WebMCP fits Creator OS so naturally. Creator OS isn't a single tool; it's a whole workflow: Research → Strategy → Idea → Content → Production → Publish → Analytics → Learn → Optimize. So the questions users really want to ask aren't “write me a caption.” They're: what performed best recently, and why? Which direction is worth continuing? What should I make next week? Build me a campaign from that, create the drafts, put them on the calendar.

If an agent can read brand context, content history, campaigns, analytics, calendar, audience, and performance directly, those questions become easy to answer. Which leads to a picture I really like: Creator OS ends up with two interfaces on top of the same data and the same logic.

I think this quietly changes a lot of SaaS product design, and I don't mean that every product becomes one giant chat box. The UI stays important. Looking at a trend, comparing visuals, editing content, reviewing results, tweaking details, checking status: a GUI beats a conversation for all of those.

What changes is that the AI starts taking over the navigation work. “Which page do I go to for this number?” becomes “show me what happened this month,” and the AI goes and finds it. The UI's role shifts from being the only way in, to being the place where you look at, edit, control, and approve what the AI did.

That shift matters far more than “adding a chatbot to the website.”

Why not just give the AI an API?

I asked myself this too. Strictly speaking, an API can do all of it: GET /api/posts, GET /api/analytics, POST /api/campaign. But APIs are designed for developers. An agent would have to work out on its own what each endpoint is, what the parameters mean, how authentication works, when it should call what, and what the returned data represents.

WebMCP is closer to an agent-native interface. You're not just exposing /api/posts; you're telling the agent, in its own terms, what the tool is for.

So my shorthand is: API = software ↔ software. WebMCP = agent ↔ website. Under the hood, both can share exactly the same backend services.

The architecture I'd use

Don't wire WebMCP straight into the database. And please don't let an agent run SELECT * FROM users;. The version I believe in puts a capability layer in the middle, and every entrance goes through it.

The hard question: what should an agent see?

To me, this is the most important part of doing WebMCP at all. The question isn't “how much can I open up?” It's:

There's a principle in the WebMCP audit doc I've been working from that I fully agree with: capabilities exposed to an agent should be small and explicit; every tool needs a clear purpose, boundary, input schema and structured output; important actions should separate preparing from confirming; and real safety has to come from backend authorization and human confirmation, never from the tool description.

Four levels of risk

I'd split Creator OS's capabilities into four levels. Click through them.

My rule for Level 4 is very simple: the AI can prepare; a person takes the last step.

Concretely: if I say “build me a campaign for next week based on my top content from the last 30 days,” the agent is free to chain get_recent_content → get_content_metrics → find patterns → create_campaign → create_content_drafts on its own. But the moment it reaches for publish_content, Creator OS should stop and show me this:

What never goes into WebMCP

Some things I would never hand to an agent, full stop: API keys, the Stripe secret, database credentials, the Supabase service role, OAuth refresh tokens, passwords, webhook secrets. The agent has no reason to know any of them. If it needs to reach an external platform, the path is agent → Creator OS tool → backend → stored credential → external service, never agent → “give me the API key.”

For the same reason, I won't ship a universal database tool. No run_sql, no query_database. Instead: get_recent_posts, get_campaign_metrics, search_content. The agent gets capabilities, not the keys to the database.

Five questions I ask before adding a tool

Every time I consider a new WebMCP tool, I run it through the same five questions. Try it on a tool you have in mind.

If it's Creator OS, the first version is six tools

Not forty. Six.

That's already enough for a very good demo. I can ask: “Look at everything I published in the last 30 days, tell me what worked and why, then give me five ideas for the next post.” Creator OS runs get_recent_content → get_content_metrics → the model analyzes → generate_content_ideas, and hands back something like this:

SEO, AEO, GEO and WebMCP are one line

This is the part of the second WebMCP doc I most wanted to write about. For years we optimized websites for one machine question: can a search engine understand my site (SEO)? Then: can an answer engine answer the user's question directly from it (AEO)? Then: can generative AI understand, cite and recommend my brand correctly (GEO)? WebMCP is one more step on the same line: can an agent use my product?

That's why the audit doc doesn't stop at WebMCP. It puts canonical URLs, semantic HTML, structured data, direct answers, sources, methodology, APIs, llms.txt and WebMCP into one system. An agent-ready site isn't done when you add an MCP tool. It has to be findable, understandable, trustworthy, and callable, all at once.

The bigger picture: the Agent Web

The second piece of material I was given has a framework I keep coming back to. It splits the internet's agent-usable resources into five layers.

What this framework makes clear is that WebMCP is probably only the third layer. Today, the whole conversation is about access. But the fourth layer is closer than it looks, because the crawl-to-refer numbers at the top of this post finally gave the infrastructure companies a reason to build it.

What Cloudflare is actually building

Until recently a digital asset had three possible states: fully free and public, fully blocked, or licensed through an expensive human-negotiated contract. Cloudflare is adding a fourth: a rule at the edge that charges per use. The mechanism is an HTTP status code that sat unused in the spec for thirty years, 402 Payment Required, and a protocol built on it called x402. Step through a paid request:

Around x402, Cloudflare has lined up three products that together form one billing chain. AI Crawl Control is visibility: which crawlers hit your site, allow or block each one, set rules per bot. Pay Per Use is pricing: a crawler asks, gets a price, and pays when the content is actually used in an AI answer, not merely when it's fetched (this replaced the earlier Pay Per Crawl idea). Monetization Gateway, announced July 1, 2026 and still on a waitlist, moves billing and settlement from your origin to Cloudflare's edge in 330+ cities, and covers web pages, datasets, APIs, files, search indexes, and, notably, MCP tool calls.

Neither site owners nor AI companies have to build a payment system; the identification, rule matching, quote, verification and settlement all happen in the edge network between them. Put plainly, a website can now say to an agent: “You want this resource? It costs money.”

I also want to keep the sober part. Both documents say the same thing: this is real, and it's early. Monetization Gateway is a waitlist. x402 being under the Linux Foundation doesn't mean the ecosystem has formed. Nobody should assume a specific protocol will become the standard. So I'm not going to rebuild a product around x402 today. What I will start doing now is the work that holds up no matter which payment protocol wins:

This is also why structured data suddenly matters more. A lot of websites are, frankly, a pretty page plus a wall of text plus a lot of JavaScript. Great for people. But what an agent wants is accurate, current, uniformly structured, clearly sourced, and callable. The PDF put it in one line I think could become a design principle for a lot of future products:

Agents need clean, trustworthy, usable resources to do good work.

If you're building SaaS right now

If I were redesigning a product today, I'd add one question to the usual list. We already ask: what's the user journey? Now also ask: what's the agent journey? For Creator OS the two look like this, and they shouldn't be identical.

I suspect this becomes a real layer of product design work in the next few years.

Where I land on WebMCP

I don't think every website needs WebMCP tomorrow. It's a direction that's still moving quickly: the spec, browser support, agent behavior and the ecosystem will all keep changing. So I won't build a pile of tools with no real use just to hit “WebMCP Score 100.” The audit doc makes this point sharply, and I like it: a scanner score is evidence, not a goal, and you shouldn't create redundant tools to satisfy a scanner.

The question to ask isn't “does my site support WebMCP?” It's: if an AI agent showed up at my product, what's the most valuable thing it could do here? If the answer is look up data, compare, analyze, create, book, search, buy, publish, or run a workflow, then WebMCP is worth taking seriously. If the answer is “read my About page,” do SEO, AEO, GEO and structured content first, and don't rush.

For Creator OS, my answer is clear. I'll do it, because Creator OS is a workflow product and workflows are exactly what agents are good at. But I'll start with those six tools, watch whether people actually use them that way, and only then expand into create_campaign, schedule_content, publish_content, analyze_campaign, recommend_next_action. If it all works, the product turns into a loop:

At that point Creator OS isn't “AI-powered content software” anymore. It's closer to an AI operator for your brand. That's what makes WebMCP interesting to me: not the protocol, the product it makes possible.

Last thing

The core question of website optimization used to be: can a person find, understand, and use my product more easily? The new question sits right next to it: can an agent find, understand, trust, and use it?

I don't think WebMCP by itself is the answer. But it has made me more certain of one thing: the next generation of websites won't only offer a UI to humans. They'll offer capabilities to agents. A few years from now we may look at a product and ask, as naturally as we ask about desktop, mobile, API and SEO today: how good is the human interface, and how good is the agent interface?

If you're building a SaaS, a marketplace, a creator tool, an e-commerce store, or anything else with data and workflows inside it, I think it's already worth sitting with this. Not because you have to chase WebMCP, but because of the question underneath it: when the people using your product are no longer only people, how should your product be designed?

That's the part I find truly interesting.

A question for you, passing through

If an agent were going to pay for your expertise, what would you package it as? An API? An MCP tool? Or a dataset that keeps updating? Pick one; I'm curious how people answer this.

One more thing. In a digital world flooded with automated crawling, some encounters, some connections, are an extraordinarily precious kind of human traffic. This connection is already Keep-Alive. If we're on the same frequency, I hope some link forms between us too. Share your mysterious, one-of-a-kind world with me.