Fifteen years ago, "does it work on a phone" went from an afterthought to table stakes. The same shift is starting for agents, and it's early enough that almost nobody is doing it yet. We started by putting it on our own contact form to find out what it actually takes.
Mobile-first didn't happen because phones were new. It happened because phone traffic crossed a threshold, and sites that were merely "responsive" (a desktop layout squeezed into a smaller screen) kept losing to sites built for the phone as the main event.
Agent-first looks like the same shift, one level up. Browser agents are moving away from what's called DOM actuation (screenshot the page, guess where to click, hope the layout didn't change) and toward pages that just tell them what they can do. WebMCP is the emerging standard for that. A page registers named tools, each with a schema, on document.modelContext, and an agent calls them the way it would call any API. The difference is the tool runs inside the page, using the user's real session, and the visible UI updates (or ought to update) the same way it would for a person.
Cloudflare's own numbers show why this isn't hypothetical. In June 2026, bot and AI agent traffic overtook human traffic on Cloudflare's network for the first time, 57.4% of HTML requests, a milestone CEO Matthew Prince hadn't expected until the end of 2027. Some of that is old-school crawlers, and a growing share of it is agents browsing on a person's behalf. Either way, the traffic you're building a site for has already changed.
Sites that only get scraped and clicked will feel like the desktop-squeezed-into-mobile sites of a few years back. Sites that declare their own tools are the ones an agent can actually use, without three retries per click, and without burning your users' tokens on it. A screenshot or a full DOM-tree dump is a lot of context to spend just to find a button. A tool call is a name, a few arguments, and a result. Multiply that by every click in a task and it adds up to real money and real latency, paid by the person using your site.
There's a human accessibility case here too, not just an agent one. A screen reader user, someone with a motor impairment, or anyone relying on an AI agent as an assistive intermediary gets a more reliable outcome when a site declares its own actions instead of forcing every interaction through a mouse-and-keyboard-shaped UI. WebMCP doesn't replace assistive technology and isn't designed to plug into a screen reader directly, but it gives an agent acting on someone's behalf a far sturdier way to act than guessing at a DOM ever was.
WebMCP is running as a Chrome origin trial right now, with Edge close behind and ChatGPT Desktop already shipping support for it. That's roughly where mobile-first standards were the year before every serious company had a mobile strategy. Nobody remembers who was second.
The sites that declare their own tools today aren't just future-proofing. They're teaching the model what a "well-behaved" site looks like while the pattern is still being written. The agents calling your tools next year were shaped by the sites that had tools to call this year. Getting there first is not a small edge.
We think this is one of the more interesting fronts in the shift toward agent-first software, and it's exactly the kind of infrastructure work we do all day: give an agent a reliable, well-described surface to act on, instead of hoping it figures out your UI.
We built our reputation on hardening the harness around coding agents: the instructions, the tools, the guardrails that decide whether an agent succeeds or quietly fails. A WebMCP-enabled site is the same idea pointed outward, at the agents your customers bring with them. The tools you register, the schemas you write, the way you gate a sensitive action behind confirmation: that's harness engineering for the open web.
Most teams building this today are figuring it out from scratch, one Chrome doc at a time. We already did that work, distilled it into a skill, and we help teams do it properly on theirs.
We put everything we learned into one skill: how to design the tools, when WebMCP beats plain MCP, how to lock it down, and every failure mode that bit us along the way. Point your coding agent at it first.
npx skills add paniolo-ai/skills --skill paniolo-webmcp-devIf your site is customer-facing, this is worth getting right the first time. We design the tool surface, lock down the security model, and prove it works in production before you announce anything.
Talk is cheap, so we dogfooded it. The form right below this now registers three WebMCP tools next to the regular Send button:
// fill_contact_form: populates the form, does not send
// wait_for_contact_verification: waits for the Turnstile token
// submit_contact_form: sends, same endpoint the button uses
await document.modelContext.registerTool({
name: "fill_contact_form",
description: "Fill the Paniolo contact form fields on this page...",
inputSchema: { /* name, email, org, type, message */ },
execute: async (input) => fillContactForm(input),
});An agent that visits the page, ours or yours, can now fill the form, wait for the same Cloudflare Turnstile check a human clears, and send the message. No DOM guessing, no brittle selectors. When we tested it end to end in a real WebMCP-capable browser, the fields filled in live on screen exactly like a person typing them, the Turnstile widget flipped to "Success," and then the page showed "Message sent." Same UI, same trust boundary, same server-side verification. Just a different hand on the keyboard. If your browser supports WebMCP, the badge on this page will light up to prove it.
We take on a limited number of engagements: hardening a coding harness, designing an agent-facing tool surface for your product, or both. Tell us what you're building and what good needs to look like.
Your browser supports WebMCP — your agent can fill and send this form directlySee where your own harness is missing infrastructure.
npx @paniolo/cli scan — free, diagnostic-only