Article summary — original

Cloudflare Updates Agentic Browser Kitesurf with WebMCP, Expanded Standards, and Terminal Rendering Cloudflare has introduced major updates to Kitesurf, its agentic browser built on Cloudflare Workers. The release brings WebMCP support, broader web standard compatibility, full Browser Run API coverage, and the ability to render pages directly inside terminals. Kitesurf now supports WebMCP, allowing AI agents to interact with sites via programmatic tools instead of simulated clicks. Web Platform Tests (WPT) passing subtests exceeded 730,000, alongside added support for URL-based module resolution, JSON modules, and import maps. Full Browser Run API integration enables control via CDP, Playwright, Puppeteer, MCP, and Worker bindings for Quick Actions. Decoupling PageRenderer allows Kitesurf to output pages to modern terminal emulators using the Kitty graphics protocol and ANSI text mode. WebMCP Support and Expanded Web Standards To reduce the fragility of agents clicking pixels, Kitesurf has introduced WebMCP support, enabling AI models to directly trigger exposed functions on websites like Cloudflare Radar. The browser engine has also added URL-based module resolution, JSON modules, import maps, and integration with the Cloudflare Workers module registry. Additionally, iframe isolation and timing have been refined, helping Kitesurf surpass 730,000 passing Web Platform Tests subtests—an increase of 500,000 since its initial launch. Full Browser Run Integration and Quick Actions Kitesurf now achieves complete API coverage within Cloudflare's Browser Run platform, permitting programmatic automation using CDP, Playwright, Puppeteer, or MCP. Developers can also invoke Quick Actions—such as taking screenshots, extracting HTML, and generating PDFs—directly within Worker scripts using the env.BROWSER.quickAction() binding rather than relying solely on the REST API. Decoupled Architecture and Terminal Rendering Kitesurf separates its PageScript session execution from its PageRenderer drawing logic, allowing rendering workloads to be moved outside the core engine. Cloudflare demonstrated this flexibility by routing PageRenderer output to terminal emulators via the Kitty graphics protocol and ANSI text mode, supporting interactive keyboard and mouse events. Cloudflare also confirmed ongoing plans to eventually open-source Kitesurf as development matures.

Article summary — zh

Cloudflare发布Kitesurf更新:支持WebMCP与终端渲染,全面覆盖Browser Run API Cloudflare发布了面向AI Agent的无头浏览器Kitesurf的最新进展。本次更新正式引入了WebMCP支持,扩大了Web标准覆盖并大幅提升WPT测试通过量,实现了Browser Run API的完全兼容,并展示了将渲染引擎解耦至终端显示的创新能力。 Kitesurf正式支持WebMCP,允许AI Agent直接调用网站暴露的API函数而非依赖模拟点击。 Kitesurf通过的WPT子测试数量已突破73万项,比发布初期增加了50多万项。 实现Browser Run API的全面覆盖,支持CDP、Playwright、Puppeteer、MCP以及Worker内直接调用Quick Actions。 利用PageScript与PageRenderer的架构分离,实现了支持Kitty协议与ANSI文本模式的终端直接网页渲染与交互。 原生集成WebMCP与标准支持扩展 为解决传统自动化浏览中依赖模拟点击导致的脆弱与低效,Kitesurf正式支持WebMCP协议。开发者可在网站中直接向Agent暴露结构化工具函数,AI模型能通过调用函数完成复杂交互。此外,Kitesurf扩展了包括基于URL的模块解析、JSON模块、import map以及iframe隔离与多语言文本展示等Web标准,其通过的Web Platform Tests (WPT) 子测试数量已超过73万项,较发布时增加50万项以上。 全面融入Browser Run平台生态 Kitesurf现已具备Cloudflare Browser Run API的完整覆盖能力。开发者可通过CDP、Playwright、Puppeteer或MCP等主流工具调度Kitesurf。广受欢迎的Quick Actions功能也已支持在Worker脚本内部通过env.BROWSER.quickAction()绑定直接调用,用于高效执行截图、提取HTML内容或生成PDF等任务,同时内部针对DOM遍历和字体加载等关键链路进行了性能调优。 渲染解耦与终端交互体验 Kitesurf在架构上将管理页面逻辑的PageScript与负责像素生成的PageRenderer相互解耦。基于这种隔离特性,官方将渲染模块移出后接入了Kitty终端图形协议和纯ANSI文本模式,使用户能够直接在终端中浏览网页并支持键盘、鼠标交互与滚动。官方还展示了在终端内运行Doom游戏Demo,直观展现了Agent视角的页面感知能力。 全Workers运行与开源承诺 Kitesurf完全部署在公有Cloudflare Workers网络上,未采用任何内部特权API,以验证平台的承载能力并降低运行成本。官方目前已在kitesurf.dev公开WPT测试进展与性能基准,并重申未来将正式开源Kitesurf,当前产品在Beta测试期间提供免费试用。

Saved original article

In August, we introduced Kitesurf, a browser for the agentic age that runs entirely on Cloudflare Workers.  We built it around what agents need from the web, rather than carrying all the features and bloat of a browser designed for humans. If this is the first you’re hearing about it, we highly recommend you read the blog post [where we introduced Kitesurf](https://blog.cloudflare.com/kitesurf/), for all the juicy technical details of how we did it. Since then, we’ve put Kitesurf through increasingly realistic tasks and used internal and external feedback from customers to make it more capable and more efficient. Here’s what has changed, how you can try it today, and where we’re going next. Websites were not built for agents to use. Browsing today is a messy process of clicking pixels and hoping the right element loads. In a programmatic world this is slow and fragile. [WebMCP](https://developer.chrome.com/docs/ai/webmcp) helps by allowing developers to expose site functionality directly to agents, where they can call functions like **searchFlights()** instead of simulating clicks. Cloudflare has been supporting WebMCP since its early days; just a few weeks ago we announced that site owners can now turn on WebMCP [with one switch](https://blog.cloudflare.com/webmcp/), so browser agents can discover and use tools on their sites without changing the site’s code, and Browser Run has been [supporting WebMCP](https://developers.cloudflare.com/browser-run/features/webmcp/) when using Chrome [beta](https://developers.cloudflare.com/changelog/post/2026-04-15-br-webmcp/) for some time now. Today we are announcing that Kitesurf now supports WebMCP. You can test this by going to our public [Kitesurf playground](https://kitesurf.cloudflare.app?url=https://radar.cloudflare.com/), opening Cloudflare Radar, and navigating to WebMCP on the Application tab in the DevTools panel. As you can see, Radar [exposes](https://developers.cloudflare.com/changelog/post/2026-08-07-radar-researcher-and-webmcp/) a list of WebMCP tools like **navigate-to** or **set-location** which allow clients to interact with the page and explore Radar programmatically. If you target Kitesurf with your AI Agent: You can see that the AI model can interact with the exposed WebMCP tools which you can use to complete tasks more reliably. You can read more about how to use WebMCP with Kitesurf and Browser Run [here](https://developers.cloudflare.com/browser-run/features/webmcp/). Since the initial announcement, we’ve been adding more browser standards so that agents can render more sophisticated pages. The list of the APIs that Kitesurf supports has grown, and now includes: We added [URL-based module resolution](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules), [JSON modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import), and [import map](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script/type/importmap) handling—important for sites that load JavaScript in chunks. Additionally we are using the new [Cloudflare Workers’ module registry](https://blog.cloudflare.com/workers-module-registry-nodejs/) to support imports from URLs. Iframe behavior has improved as well; now they load at the right time, stay better isolated, and display text correctly across more languages and encodings. As we said at launch, running tests is how we keep the quality of both code and results under control without losing velocity while improving Kitesurf. [Web Platform Tests (WPT)](https://github.com/web-platform-tests/wpt) is a shared, open-source test suite that checks whether browsers implement web standards consistently. We now pass 730,000+ [WPT subtests](https://github.com/web-platform-tests/wpt) and are growing. That’s 500,000 more subtests than when we launched. Here you can see the evolution over time, up to the latest version since we started the project: For an AI agent, efficiency isn’t so much about loading pages fast, but about the latency of the agentic loop. To make Kitesurf truly agentic, we’ve aggressively optimized the browser engine’s internals so that every DOM traversal, timer, and font fetch is as lightweight as possible, ensuring the agent spends its compute cycles on reasoning, not waiting for the browser to catch up. These optimizations include: Together, these optimizations help keep Kitesurf efficient for agents. Despite adding support for more web standards—and bringing Kitesurf closer to the capabilities of full-featured browsers like Chrome—its wall-clock time and CPU usage remain roughly in line with our launch benchmarks, and in some cases they have improved. [Browser Run](https://developers.cloudflare.com/browser-run/) is our developer platform product that lets you programmatically control and run headless browser instances. When you use this API, you can select from a list of browser flavors we support, including Kitesurf. This means that we have to make sure that all of our browsers are supported across the API surface. Starting today, Kitesurf has full Browser Run API coverage. You can use Kitesurf with [CDP](https://developers.cloudflare.com/browser-run/cdp/), [Playwright](https://developers.cloudflare.com/browser-run/playwright/), [Puppeteer](https://developers.cloudflare.com/browser-run/puppeteer/), or [MCP](https://github.com/cloudflare/mcp-server-cloudflare/tree/main/apps/browser-rendering). One of the most popular Browser Run features, [Quick Actions](https://developers.cloudflare.com/browser-run/quick-actions/), provide simple interfaces for common browser tasks like capturing screenshots, extracting HTML content, generating PDFs, and more. When we launched Kitesurf, you could use Quick Actions from our REST API. Now you can also use them from inside a Worker script using the **env.BROWSER.quickAction()** binding: As we detailed in the [How we built it](https://blog.cloudflare.com/kitesurf/#how-we-built-it) section of our announcement blog post, Kitesurf separates [PageScript](https://blog.cloudflare.com/kitesurf/#pagescript), the isolate that handles the page session and runs the page code, from [PageRenderer](https://blog.cloudflare.com/kitesurf/#pagerenderer), which is responsible for generating the actual pixels from the computed page objects. This not only gives great isolation and flexibility, but it also allows us to decouple and move the rendering logic to outside Kitesurf (to the client, for example, or to another Worker), while keeping the security-critical parts server-side, running in our network. If this model sounds familiar, it may be because Cloudflare has another SASE product called [Cloudflare Browser Isolation](https://www.cloudflare.com/sase/products/browser-isolation/), which runs all untrusted web code at the edge of our global network while it “streams” the rendering data back to the clients. We can do something similar with Kitesurf. To prove it, we moved PageRenderer to our [Playground](https://kitesurf.dev/) Worker and patched this version so that instead of converting scene data into an image, it outputs to [Kitty](https://sw.kovidgoyal.net/kitty/graphics-protocol/)—a terminal graphics protocol supported by modern terminals like Kitty [itself](https://sw.kovidgoyal.net/kitty/), [Ghostty](https://ghostty.org/), [WezTerm](https://wezterm.org/), and others. We even went a step further and added a pure ANSI text mode for environments where Kitty isn't available. The result is that you can now quickly open and render a page using Kitesurf without leaving the comfort of your terminal application. This is super useful not only because you can now browse the modern Web at a glance without context-switching, but you can also use this tool to see how an agent using Kitesurf “sees” a page. To install the terminal version of Kitesurf, do this: From now on just type this in terminal: Here’s a demo of it working. The terminal also sends back scrolling and click events, so you use the keyboard, arrows, or the mouse normally, as if you were in a dedicated browser application window. And here is our [Silent Space Marine](https://silentspacemarine.com/) Doom demo running in Kitesurf inside the terminal: We continue to iterate rapidly on the road to the best agentic browser for our customers and developers. Expect ever-better performance benchmarks and for the list of supported Web standards and WPT test coverage to continue to rise quickly. In fact, we’ve decided to publish the results [here](https://kitesurf.dev/wpt) and [here](https://kitesurf.dev/benchmarks), in the open, so that you track them as we move forward, in real time. We are going to continue exploring scenarios where decoupling Kitesurf and moving PageRenderer away from PageScript is an advantage for agents, or where higher frame rates are important. We may or may not have a 30fps Doom version running in Kitesurf as we write this. We also want to address the elephant in the room: While we are currently prioritizing rapid development, we remain committed to open-sourcing Kitesurf. This is coming soon, but we want to do this right, so we are set up to support it for the long term. Kitesurf stays true to its initial design goal: It runs entirely on top of Workers just like any other customer application does; that means we only use our publicly available features and APIs and have no access to any special privileges. This is not only a great way to dogfood and prove our own platform, but also the only way to make Kitesurf very cheap and scale automatically across the Cloudflare global network. Give Kitesurf a try in the refreshed [kitesurf.dev](https://kitesurf.dev) playground, and use it in your projects via [Browser Run](https://developers.cloudflare.com/browser-run/kitesurf/). It’s **available for free while in beta**, behind per-account [limits](https://developers.cloudflare.com/browser-run/limits/?cf_page=kitesurf%2F). Keep an eye on our [changelog](https://developers.cloudflare.com/browser-run/changelog/?cf_page=kitesurf%2F) and come chat with the team on [Discord](https://discord.com/invite/cloudflaredev). Share your experience and send us feedback—we’ll be listening.