Cloudflare's agent browser calls site tools instead of clicking

Kitesurf, the browser Cloudflare built for AI agents and runs entirely on Workers, now discovers and calls WebMCP tools directly, according to Cloudflare’s update post. Rather than locating a search box and simulating clicks, an agent driving Kitesurf can call a function the site declares, searchFlights() in Cloudflare’s example, and read the result.

Cloudflare’s own demo is Radar, its internet traffic data site. Open Radar in Cloudflare’s public Kitesurf playground and the WebMCP entry under the DevTools Application tab lists the tools Radar publishes, among them navigate-to and set-location. An agent pointed at that page reads the list and drives Radar through those calls instead of through the interface. Wiring an agent to Kitesurf goes through a flag Cloudflare still names experimental: a chrome-devtools-mcp process pointed at the Browser Run endpoint and launched with --category-experimental-webmcp.

What makes this more than a product note is that both ends of WebMCP now run in shipped software. The server side already exists: Cloudflare’s post says site owners on Cloudflare can switch WebMCP on without touching site code, and Vercel’s mcp-handler exposes site tools to in-page agents behind an auth proxy. Kitesurf is the client that consumes them. Declaring tools stops being a bet on a standard once something exists to call them.

Calling declared functions also cuts against Google’s advice to give agents real buttons and stable layouts. Both pieces of advice hold at once. WebMCP pays off only with clients that implement it, and everything else still arrives as a browser or a fetcher that has to find a control and press it.

Kitesurf can also print a page into a terminal now. The browser separates PageScript, the isolate that runs page code, from PageRenderer, which turns computed page objects into pixels, and Cloudflare moved PageRenderer into its playground Worker and patched it to emit Kitty terminal graphics, supported by Kitty, Ghostty and WezTerm, plus a plain ANSI text mode for terminals without that protocol. After brew install cloudflare/cloudflare/kitesurf, kitesurf <url> renders the page where you already work. Cloudflare offers this as a way to see how an agent using Kitesurf sees a page.

What the terminal shows is Kitesurf’s rendering, not Chrome’s. Kitesurf now passes over 730,000 Web Platform Tests subtests, roughly 500,000 more than at launch, and Cloudflare says wall-clock time and CPU stayed near launch benchmarks as that grew. It is still short of Chrome. A template that renders wrong in the terminal is therefore as likely to be a gap in Kitesurf as a fault in the page, so reproduce it in a normal browser before filing anything.

None of this changes the picture for training crawlers such as GPTBot and ClaudeBot, or for the retrieval bots behind AI answers. Neither kind runs a page’s declared tools. WebMCP matters to a third kind of client, the agent browser working through a task.

What to do

• List the few things an agent would come to the site to do, such as search, filter or check availability, and expose those as WebMCP tools. Sites on Cloudflare can turn the layer on without a code change.
• Render the templates that matter most, such as a category page, a product page and a search results page, with the terminal build and see what survives.
• Leave the HTML path alone. Buttons, labels and stable layout still serve every human visitor and every other bot type.
• Treat the agent integration as an experiment while the flag still says experimental, and keep the tool list small enough that you can check each call by hand.