How to Use Kitesurf WebMCP

The short answer

To use Kitesurf WebMCP, connect an MCP-compatible agent to Cloudflare Browser Run through Chrome DevTools MCP, point the WebSocket endpoint at browser=kitesurf, and enable the experimental WebMCP tool category. That gives the agent two important commands: list_webmcp_tools to discover a page's actions and execute_webmcp_tool to run one.

Start with a read-only or reversible action. Cloudflare Radar is a useful documented target because it exposes actions such as navigate-to and set-location. Inspect the schema that Kitesurf returns, supply only the arguments that schema accepts, then compare the structured result with the visible page state. A tool call is not a pass until both agree.

This walkthrough is a documented test plan, not a claimed live test. No test Cloudflare account or Browser Run token was available for this run, so there is no fabricated success result below.

What Kitesurf WebMCP actually changes

MCP and WebMCP do different jobs. MCP connects your agent to the remote browser. WebMCP lets the website publish its own named actions inside that browser. Think of MCP as the phone line and WebMCP as the menu at the other end: the line gets you there, while the menu tells you exactly what can be ordered and which details each order needs.

Without that menu, an agent often reads the page, finds a control, clicks it, waits, and reads again. With WebMCP, a page can expose a function such as set-location with typed inputs. The agent still has to choose the right action and validate the output, but it no longer has to infer every interaction from pixels or page structure.

Cloudflare's WebMCP documentation says Kitesurf has its own implementation, so it does not need a Chrome Lab session. Pages can register programmatic tools through document.modelContext, and Kitesurf also recognizes declarative form tools marked with toolname and tooldescription attributes.

Connect an MCP client to Kitesurf

You need Node.js 20.19 or newer, an MCP-compatible client, a Cloudflare account ID, and an API token with Browser Rendering - Edit permission. Cloudflare's MCP client setup covers Claude Desktop, Claude Code, Cursor, and OpenCode. If this is your first MCP connection, the MCP server roundup gives useful context on what the local server is doing.

Cloudflare's Kitesurf launch gives this local-client configuration:

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}",
        "--category-experimental-webmcp"
      ],
      "enabled": true
    }
  }
}

Use your client's expected configuration shape, but preserve the command arguments. Keep the real account ID and token in environment-backed secrets rather than a committed settings file. Do not copy the Chrome Lab parameters into this URL. Kitesurf uses browser=kitesurf, does not require lab=true, and does not accept keep_alive.

The final flag matters. --category-experimental-webmcp is what adds list_webmcp_tools and execute_webmcp_tool to Chrome DevTools MCP. A connection can otherwise work perfectly while the two WebMCP commands remain absent.

Run one checked task on Cloudflare Radar

The smallest useful test proves four things: discovery works, the schema is readable, execution returns data, and the page reflects the result.

1. Ask the connected agent to open https://radar.cloudflare.com/. Keep the task inside a test account and avoid any action with financial, destructive, or account-wide consequences.
2. Call list_webmcp_tools. Save every returned tool name, description, and input schema. The available set can change after navigation or another action, so this inventory belongs to the current page state.
3. If a benign action such as set-location is present, select it and read its returned schema. Do not guess the argument names from this article. Use the live schema as the contract.
4. Call execute_webmcp_tool with a schema-valid location value. Record the exact tool name, arguments, structured result, elapsed time, and visible page state.
5. Compare the response with what Radar shows. Re-run list_webmcp_tools after the state change and record any added or removed actions.

A useful agent prompt is direct:

Treat the evidence as a small test record, not a chat transcript. At minimum, keep these fields:

This turns a demo into something an engineering team can repeat. It also separates a WebMCP failure from an agent reasoning failure. If the named tool is absent, the interface failed before execution. If the call succeeds but the page disagrees, the implementation or verification failed after execution.

Where Kitesurf needs a fallback

Kitesurf WebMCP is not a universal browser control layer. Its current boundaries decide which production tasks are safe to route through it.

• Tools registered inside an iframe or popup are not exposed through CDP. Treat them as unavailable to the agent and use a conventional browser path, a human path, or a top-level tool if you own the site.
• Kitesurf sessions do not appear in wrangler browser list and have no live view. An agent cannot complete a tool that pauses for a person's confirmation.
• For a confirmation-gated action, Cloudflare's documented manual route is the WebMCP panel under Application in the Kitesurf playground. That is a handoff, not unattended automation.
• Kitesurf does not implement the WebMCP tools permissions policy or origin-based tool filtering. Tool discovery is not authorization. Keep a separate allowlist for domains, actions, and test identities.
• The tool list is stateful. Re-list after navigation or any action that changes the page before assuming the next tool still exists.

The honest production pattern is a router: WebMCP first when a suitable named action is present, normal browser automation when it is not, and a human handoff when the action requires consent. Do not hide those branches behind one optimistic prompt.

The business math is maintenance, not just browser price

Kitesurf is free during its beta behind account limits, but Cloudflare has not established that its general paid Browser Run overage rates apply to the free beta. The current Kitesurf pricing and allowance picture is covered separately, including the reasons not to build a permanent cost model from a beta offer.

There is already a real browser-infrastructure budget in this market. Browserbase lists paid plans at $20 and $99 per month. Browserless lists plans at $25 and $140 per month when billed annually. Those products cover broader infrastructure jobs, so this is not an apples-to-apples replacement claim. It is evidence that teams already pay to operate browser agents.

WebMCP changes a different line in the budget: selector maintenance, retries, and operator review. It does not remove the browser, the model, security controls, result validation, or the fallback path. Measure the same task both ways and compare elapsed time, failed attempts, human interventions, and engineering fixes. Keep Kitesurf only where the measured reduction in upkeep is larger than the integration work.

Seven use cases, ranked by who gains most

Every use case below assumes the target page actually exposes an appropriate WebMCP tool. Kitesurf cannot manufacture a site action that is not there.

The first use case has the broadest value because most teams will face a mixed web for years. A router that knows when not to use WebMCP is more useful than a demo that succeeds on one prepared page.

Three products worth building

1. A WebMCP-first fallback router

Build a policy layer for agent teams that lists a page's tools, matches the user's requested action to an allowed schema, and routes the task either to execute_webmcp_tool, conventional browser automation, or a human queue. This is the strongest opportunity because it solves the adoption gap instead of waiting for every site to implement WebMCP.

The demand is already visible around the job: browser automation gets about 720 monthly searches, while the commercial query browser automation tools gets about 260 and carries a $34.28 CPC in the run's keyword data. The smallest sellable version needs one MCP client connector, a domain and action allowlist, a schema matcher, an execution log, and one fallback adapter.

The catch is reach. WebMCP coverage is still limited, tool sets can change with page state, and Kitesurf cannot surface iframe or popup tools through CDP. The fallback engine is part of the product, not an optional later feature.

2. A WebMCP regression monitor

Sell site owners a scheduled check that records exposed tool names and schemas, runs one reversible fixture action, compares the result with the visible page, and alerts on a diff. About 590 monthly searches target website automation, with a $33.88 CPC. The related singular query browser automation tool is up 24% year over year in the suggestion data.

An MVP can monitor a short list of owned routes with test credentials, store before-and-after tool inventories, and produce a compact failure record with the arguments, result, time, and page state. The catch is state. A missing tool may reflect the wrong route or session state rather than a broken release, so the product needs reproducible navigation and careful fixtures.

3. A WebMCP readiness auditor

Build a preflight service for web teams that maps which customer journeys expose top-level tools, which actions sit behind iframes or popups, and which ones require a person's approval. The demand proxy is practical: playwright browser automation gets about 320 monthly searches and is up 129% year over year, while website automation gets about 590.

The smallest version accepts an owned site's routes and test identity, lists and classifies the available tools, and produces a prioritized implementation report. Its honest catch is observability. Because Kitesurf cannot expose nested iframe or popup tools through CDP, an auditor cannot infer their intended contracts from Kitesurf alone. It needs site-owner input or a second inspection method to distinguish hidden from absent.

Limits and the honest take

Use Kitesurf WebMCP now for bounded, reversible tasks where a structured action is clearly better than a click sequence. Do not use it as the only path for a critical workflow, a nested payment experience, or a task that must wait for live human approval.

The feature is valuable, but the launch is ahead of the ecosystem. The named-action model can reduce ambiguity and make failures easier to diagnose. It does not make every website agent-ready, and it does not turn a returned payload into proof that the page did the right thing. The verification step is the product boundary that matters.

If you want this connection, verification test system, and fallback policy built for a production agent, I can help with the production system.