# What Is WebMCP? Why We’re Adding It to the Control Plane Console

> Source: <https://dev.to/noahcontrolplane/what-is-webmcp-why-were-adding-it-to-the-control-plane-console-46hm>
> Published: 2026-11-04 02:35:48+00:00

WebMCP is a draft specification that lets a web page expose its functionality to AI agents as structured tools, so agents call functions instead of scraping the page or simulating clicks. Control Plane is adding WebMCP to the console in December 2026, exposing all console functionality to agents working in the browser.

WebMCP lets a web page expose its functionality to AI agents as “tools.” A tool is a JavaScript function with a natural-language description and a JSON Schema describing its inputs. An agent reads the list of tools and calls them directly. It does not scrape the page or simulate clicks. This is described in the [WebMCP repository](https://github.com/webmachinelearning/webmcp) and the [draft specification](https://webmachinelearning.github.io/webmcp/).

WebMCP is being developed in the W3C Web Machine Learning Community Group. Its editors are engineers from Microsoft and Google, and it is published as a Draft Community Group Report that is still evolving. A Community Group is not the W3C standards track, so WebMCP is not a W3C Recommendation and should not be treated as a finished standard.

According to the draft, the imperative API registers tools from JavaScript. The page calls `document.modelContext.registerTool()` with a name, a natural-language description, and an `execute` function. Optional fields include a title, a JSON Schema `inputSchema` and `outputSchema`, and annotations that describe how the tool behaves. A declarative approach that annotates standard HTML forms is being explored separately and is not yet part of the specification, although Chrome documents a Declarative API in its implementation.

The snippet below illustrates the draft API with a hypothetical workload-health tool. It is not Control Plane’s implementation, and the names may change as the draft evolves.

```
// Illustration of the WebMCP draft API, not Control Plane code.
// Names may change as the specification evolves.
await document.modelContext.registerTool({
  name: "inspect_workload_health",
  description: "Read health signals for a workload the signed-in user can access.",
  inputSchema: {
    type: "object",
    properties: {
      gvc: { type: "string" },
      workload: { type: "string" }
    },
    required: ["gvc", "workload"]
  },
  annotations: { readOnlyHint: true },
  async execute({ gvc, workload }) {
    // The application's own service checks the user's access and returns the result.
  }
});
```

WebMCP is a client-side complement to MCP servers. The web page acts as an in-page MCP server for its own client-side logic. Tools run with the page’s existing state and the user’s existing signed-in session, so a backend server does not have to replicate authentication and context.

| WebMCP | MCP server | 
|---|---|
| Where it runs | In the browser, inside the web page | 
| Who hosts it | The web page itself | 
| Authentication | The user’s existing signed-in session | 
| Best for | Agents working in the browser that need a site’s full UI and page state | 
| Availability | While the page is open | 
| What it exposes | Tools | 

They reach agents in different places. An MCP server serves agents running in a terminal, an editor, or a chat client. WebMCP serves agents that are already in the browser, on the page, in the user’s session. A platform that offers both covers both situations without asking the user to switch tools. [Chrome’s own comparison](https://developer.chrome.com/docs/ai/webmcp/compare-mcp) describes MCP as persistent and WebMCP as tied to the open tab, and recommends using both. Chrome calls WebMCP a set of MCP-inspired APIs that omit server-side concepts such as resources.

Agents that drive a UI through screenshots and clicks can be slow and brittle. The agent captures the screen, guesses where a button is, clicks, and checks whether it worked. A layout change can break the whole sequence.

With WebMCP, the page registers tools and the agent works from that list:

The WebMCP explainer notes that without tools, “simple operations often require multiple steps and can be slow or unreliable.” With tools, the agent calls a function with defined inputs instead of inferring what the interface does.

Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, and bare metal into what Control Plane calls a Global Virtual Cloud (GVC). The CLI, console, Terraform and Pulumi providers, and the Control Plane MCP server all work through the same Control Plane API. Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run.

Control Plane supports MCP and AI agents through the paths below. Other cloud platforms publish their own MCP and agent support, so check each vendor’s official documentation for current status. For a wider look at the category, see our guide to the [best MCP servers for DevOps](https://controlplane.com/blog/post/best-mcp-servers-for-devops?utm_source=devto&utm_medium=syndication&utm_campaign=what-is-webmcp-control-plane-console).

An agent needs a structured interface to the platform, authentication it can use safely, and guardrails. On Control Plane, agents have these options today:

`https://mcp.cpln.io/mcp` and has over 100 tools in four toolset profiles. readonly covers investigation, including metrics, logs, traces, workload events, one-call workload diagnosis, and the audit trail. core, the default, adds the deploy-and-operate tools. mk8s adds tools that create and update Control Plane Managed Kubernetes (MK8s) clusters, and full adds the complete administrative surface, including org IAM and cloud-account registration. Job tools do a whole task in one call, such as deploying an app, adding a database, creating or rotating a secret without its value entering the chat, or diagnosing a workload. See the All of these, and the console, sit on the same Control Plane API. They are governed by the same policies and recorded in the same audit trail. For more on running agents against production systems, read [how to let AI agents operate production infrastructure safely](https://controlplane.com/blog/post/ai-agents-production-infrastructure-safely?utm_source=devto&utm_medium=syndication&utm_campaign=what-is-webmcp-control-plane-console).

Control Plane also runs agents themselves. Sandboxes run in dedicated Kata Containers microVMs, and Control Plane’s Universal Cloud Identity (UCI) gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code.

A checkout workload’s latency rises after a deploy, and an engineer asks an agent to find the cause without changing production. On Control Plane today, the agent connects to the MCP server on the readonly profile and works in five steps:

Once WebMCP is in the console, an engineer viewing that workload gets the same flow from a browser agent that calls the console’s tools directly.

Five tests decide whether agents can run production operations on a platform. Control Plane meets all five today through its MCP server, and WebMCP will extend them to the console in December 2026.

Every other interface people use to work with Control Plane is already usable by agents: API, CLI, Terraform, Pulumi, MCP server, and AI plugins. The console is the remaining one for agents that work in the browser. Control Plane is adding WebMCP to the console in December 2026, and it will let agents use everything the console can do.

Here is what that means:

WebMCP has a defined security model, and it is still a draft. In summary:

Chrome publishes [WebMCP tool security guidance](https://developer.chrome.com/docs/ai/webmcp/secure-tools). We recommend following it for any site or agent that uses WebMCP.

Agents act within the permissions you have granted, through the same API, policies, and audit trail as the console. The MCP server and AI plugin paths use OAuth with per-org consent. If you are new to agents on infrastructure, begin with the MCP server’s readonly profile, which has no write tools, so an assistant on it cannot change a live resource. Because the toolset profile is fixed for the life of a connection, an agent cannot expand its own tool access mid-session.

Per [Chrome’s documentation](https://developer.chrome.com/docs/ai/webmcp), published May 18, 2026 and last updated October 7, 2026, WebMCP is available for local development by enabling `chrome://flags/#enable-webmcp-testing`. It is also available through a WebMCP origin trial starting in Chrome 149. Chrome says WebMCP is under active discussion and subject to change, and describes it as designed for local browser workflows with a human in the loop, with tools that execute visibly on the page.

WebMCP is a draft specification that lets a web page expose its functionality to AI agents as tools. Tools are JavaScript functions with natural-language descriptions and JSON Schema inputs. It is developed in the W3C Web Machine Learning Community Group.

An MCP server runs as its own process, locally or remotely, and handles its own authentication. WebMCP runs in the web page and uses the page’s state and the user’s existing signed-in session. The two are complementary.

Per Chrome’s documentation, WebMCP is available through the `chrome://flags/#enable-webmcp-testing` flag for local development and through an origin trial starting in Chrome 149. It is subject to change.

The page registers tools. The agent discovers them, chooses one from its description, and calls it with arguments that match the JSON Schema. The tool runs in the page, so the agent does not rely on screenshots or simulated clicks.

The model has the user and the agent share one browser session. Tools are exposed to the registering page and same-origin frames by default, and cross-origin frames need a Permissions Policy. Chrome notes that tools execute visibly on the page. Follow Chrome’s published security guidance.

No. It is a draft developed in the W3C Web Machine Learning Community Group. A Community Group is not the W3C standards track, and the specification is still evolving.

Control Plane does, through a hosted MCP server, AI plugins, and documented setups for many MCP-compatible clients. For other platforms, check each vendor’s official documentation.

On Control Plane, agents can use the hosted MCP server, the AI plugin, the CLI, Terraform, or Pulumi. All of them sit on the same API, governed by the same policies and recorded in the same audit trail.

Read-only investigation of the workload an engineer is already viewing. The agent gathers status, logs, and metrics, explains the evidence, and proposes a next step. On Control Plane you can do this today by connecting the MCP server on the readonly profile.

Control Plane is adding WebMCP to the console in December 2026. It will let agents use everything the console can do.

AI agents can operate Control Plane today through the MCP server and AI plugins. Start with the [AI overview](https://docs.controlplane.com/ai/overview?utm_source=devto&utm_medium=syndication&utm_campaign=what-is-webmcp-control-plane-console) and the [MCP documentation](https://docs.controlplane.com/ai/mcp?utm_source=devto&utm_medium=syndication&utm_campaign=what-is-webmcp-control-plane-console).

[Talk to the Control Plane team](https://controlplane.com/requestdemo?utm_source=devto&utm_medium=syndication&utm_campaign=what-is-webmcp-control-plane-console) | [Sign up free](https://console.cpln.io/signup)

*Originally published on the [Control Plane blog](https://controlplane.com/blog/post/what-is-webmcp-control-plane-console?utm_source=devto&utm_medium=syndication&utm_campaign=what-is-webmcp-control-plane-console).*