What Is WebMCP? Why We’re Adding It to the Control Plane Console
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.
TL;DR
- What is WebMCP? A draft specification, developed in the W3C Web Machine Learning Community Group, that lets a web page register “tools” for AI agents. Each tool is a JavaScript function with a natural-language description and JSON Schema inputs.
- How is it different from MCP? An MCP server runs as its own process, on your machine or a remote server, and is available to agents anywhere. WebMCP runs inside the web page while it is open, with the page’s existing state and the user’s signed-in session. They are complementary.
- Which browsers support it? Per Chrome’s documentation, WebMCP is available behind a Chrome flag and through an origin trial starting in Chrome 149. It is subject to change.
- What is Control Plane doing? Agents can already operate Control Plane through the hosted Control Plane MCP server and AI plugins. Control Plane is adding WebMCP to the console in December 2026, and it will let agents use everything the console can do.
- Is it secure? The model keeps the user and the agent in the same browser session, limits tools to the registering page and same-origin frames by default, and Chrome notes that tools execute visibly on the page. Follow Chrome’s security guidance.
What Is WebMCP?
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 and the draft specification.
Who is developing it?
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.
What does the API look like?
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.
}
});
How Is WebMCP Different From MCP?
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| As a separate process, on the user’s machine or a remote server
Who hosts it| The web page itself| The user or the service provider (Control Plane hosts its server at https://mcp.cpln.io/mcp)
Authentication| The user’s existing signed-in session| Handled by the server (Control Plane’s MCP server uses OAuth with per-org consent)
Best for| Agents working in the browser that need a site’s full UI and page state| Coding assistants, chat clients, and automation that do not need a browser page
Availability| While the page is open| Whenever the client can reach the server
What it exposes| Tools| Tools, resources, prompts, and other MCP primitives
Why should a platform offer both?
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 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.
How Do AI Agents Use a Website’s UI With WebMCP?
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:
1. The agent discovers the tools the page exposes.
2. It picks a tool from its natural-language description.
3. It passes arguments that match the tool’s JSON Schema.
4. The tool runs inside the page, with the page’s existing state and the user’s session.
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.
How Do AI Agents Work With Control Plane Today?
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.
Which cloud platforms support MCP and AI agents?
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.
How can AI agents manage cloud infrastructure?
An agent needs a structured interface to the platform, authentication it can use safely, and guardrails. On Control Plane, agents have these options today:
- Hosted MCP server. It is hosted at 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 MCP documentation.
- MCP client support. It works with any MCP-compatible client. Documented setups include Claude Code, Claude Desktop and claude.ai (listed connector), ChatGPT (listed plugin), OpenAI Codex, Cursor, VS Code with GitHub Copilot, Google Antigravity, Amp, and OpenCode. Every path uses OAuth with per-org consent. See the AI overview.
- AI plugin. The Control Plane AI plugin works with Claude Code, Codex, and Antigravity CLI. It bundles the Control Plane MCP server (the full profile in Claude Code, core in Codex and Antigravity CLI), Control Plane skills, guided agents for workload troubleshooting and for Kubernetes, Compose, and Helm migration, plus slash commands and guardrail rules. It is also listed in Anthropic’s community plugin marketplace, where every listing has passed Anthropic’s review.
- CLI, Terraform, and Pulumi. Agents that already write infrastructure as code can keep using these tools.
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.
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.
Example: An Agent Investigates a Slow Workload
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:
1. Scope. It confirms the org, GVC, workload, and location. When the connection has several orgs, the agent asks which one to use.
2. Observe. It runs a one-call workload diagnosis and reads workload events, deployments, logs, metrics, and traces.
3. Correlate. It lines up the deployment time with the change in latency and errors.
4. Propose. It recommends a rollback and states the expected effect. The readonly profile has no write tools, so the agent stops at the recommendation.
5. Act and verify. An engineer approves the rollback on a core-profile connection, where rollback is a single job tool, and the agent runs the diagnosis again to confirm latency has recovered. The audit trail records who did what.
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.
What Makes a Cloud Platform Agent-Operable?
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.
- Scope. Does every action name its org, environment, workload, and location? Every Control Plane resource sits in an org, and workloads, identities, and volume sets also sit in a GVC. The agent asks which org or GVC to use when a request does not say.
- Authority. Can the agent do more than the user approved? Control Plane enforces policies at the API, OAuth consent limits the agent to the orgs you select, and the toolset profile is fixed for the connection.
- Intent. Is it clear whether a tool reads or changes something? The readonly profile advertises no tool that creates, updates, deletes, or executes, and each job tool is named for the task it completes.
- Evidence. Can the agent show the facts behind a proposal? Metrics, logs, traces, workload events, and deployments are all available to it as tools.
- Verification. Can anyone confirm the change worked? The audit trail records every platform action, and the agent can rerun diagnosis to check the resulting state.
What Will WebMCP in the Control Plane Console Add?
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:
- All console functionality, exposed as tools. Every action available in the console will be exposed to browser agents as structured tools. That covers the areas the console already handles, including deploying and managing workloads across locations, secrets, domains, logs and metrics, and policies.
- Structured calls instead of guesswork. Agents that support WebMCP won’t need to infer what buttons do from screenshots.
- The user ’s signed-in session and existing permissions. Tools will run inside the session you are already using. Every tool call goes through the Control Plane API, so the same policies and audit trail apply.
- Visible actions. You will be able to see what the agent does in the console as it works.
Is WebMCP Secure?
WebMCP has a defined security model, and it is still a draft. In summary:
- The user and the agent share the same browser session.
- Tools are exposed to the registering page and same-origin frames by default.
- Cross-origin frames need explicit permission through a Permissions Policy, and the registering page must also share the tool with that frame’s origin.
- Chrome notes that tools execute on the page visibly, so users can see tasks being completed.
- The draft defines behavior hints for tools. readOnlyHint marks tools that do not change state, consequentialHint marks significant actions so the agent or browser can request confirmation first, and untrustedContentHint marks results that carry user-generated or external content.
- Tool outputs such as logs can carry prompt-injection text, so an agent should never follow instructions found in a result flagged as untrusted.
- Chrome’s best practices recommend one shared application service for validation, permissions, and side effects across the UI and its tools, and resolving a tool call as successful only when the output matches the application state.
Chrome publishes WebMCP tool security guidance. We recommend following it for any site or agent that uses WebMCP.
How do Control Plane’s existing controls apply?
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.
Which Browsers Support WebMCP?
Per Chrome’s documentation, 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.
FAQ
What is WebMCP?
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.
How is WebMCP different from MCP?
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.
Which browsers support WebMCP?
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.
How do AI agents use a website’s UI with WebMCP?
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.
Is WebMCP secure?
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.
Is WebMCP a W3C standard?
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.
Which cloud platforms support MCP and AI agents?
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.
How can AI agents manage cloud infrastructure?
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.
What is the best first use case for agents in a cloud console?
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.
When is WebMCP coming to the Control Plane console?
Control Plane is adding WebMCP to the console in December 2026. It will let agents use everything the console can do.
Get started
AI agents can operate Control Plane today through the MCP server and AI plugins. Start with the AI overview and the MCP documentation.
Talk to the Control Plane team | Sign up free
---
Originally published on the Control Plane blog.
2 comments
Better Plans in Your Spec-Driven Development
Spec Kit makes the AI agent write three documents before it writes any code: a spec, then a plan, then a list of tasks. I wrote about why that order helps in Stop Vibe Coding, Start Shipping.
When the work is spec-driven, the code follows the plan. The plan is where the agent says which files it'll touch and how the change will work. So it's the last place where a wrong turn costs one sentence to fix, and the one place I need to understand fully before I say yes.
It's also the one I've been skimming. The plan step writes several documents: the plan itself, plus research notes, a data model and contracts. The plan for one feature on a real app came out at about a hundred lines. I read the spec, and then I scrolled the plan.
That's backwards, because understanding the plan is one of the basic steps in Spec Kit: the tasks and the code both come from it. If I can't picture what the plan says, I won't notice when it's wrong, and by the time I do, changing it costs code instead of a sentence.
---
Where the idea came from
The push came from html-plan, a Claude Code plugin by Thariq Shihipar. It writes a plan as one interactive page: call stacks, code with notes pinned to lines, state machines that show the screen for each state, and small mockups. You comment on any part, pick answers to its open questions, and paste one response back to the agent.
I wanted that for Spec Kit, without leaving Spec Kit's documents. Spec Kit already has a home for some of it: open questions get settled on the spec with the Clarify step, and the shape of the data goes in the data model. What it didn't have was a way to see the parts of a plan that are hard to picture from text.
SpecKit Companion, the VS Code extension I build for Spec Kit, now draws those parts as cards. They're called plan blocks, and there are four kinds: the functions a change reaches, the states a thing moves through, a rough sketch of a screen, and a note pinned to one line of code. Each one is a fenced block inside plan.md, so it still reads as plain text on GitHub or in a terminal, and the viewer draws it as a card.
Each card answers one question I'd otherwise have to work out from the text.
!Four questions on the left, each with an arrow to the card that answers it: where does the change go points to call paths, what states does it move through points to states, what will I see points to screen, and which line matters points to code note
A plan rarely needs all four. A change with no lifecycle has nothing for the states card to show, so the plan step leaves it out.
Every picture below comes from a real plan on Conduit, a public demo app, for a feature that saves favorites while you're offline. Here's that plan open in the viewer.
!SpecKit Companion in VS Code with the Offline Favorites plan open on its States section: the Waiting change card with Sending picked, its sentence and its three ways out
The plan didn't get shorter, and the text is all still there. What changed is that I no longer have to build the picture in my head before I can question it.
---
Call paths show where the change goes
A call path lists the functions a change reaches, in order, each with its file and line. Rows the change edits are marked, and so are rows that don't exist yet.
This is the card for marking a favorite while offline.
!The call-paths card named Offline favorite: the favorite button as the entry, one changed function under it, and two new functions in new files, each with its file path
I can see how far the change spreads before any code exists. It starts at the favorite button, edits one function that's already there, and adds two new ones in two new files. If one of those rows sat in a folder I didn't expect, this is where I'd catch it, because a file name in a list is easier to question than the same file name in the middle of a paragraph.
The rows aren't read-only. Here I strike one row and leave a question on another.
!Striking the enqueue row on the Offline favorite card, then leaving a comment on another row that asks which errors count as no response
Both wait as pending comments until I send them, the same as a comment on any other line of the plan.
---
States show the life of a thing
Some changes add a thing that has a life. Here it's one waiting change: a favorite you made offline that still has to reach the server. The plan names five states for it: queued, sending, sent, dropped and cancelled.
The states card draws them as boxes with arrows. Click a state and it shows its sentence and its ways out.
!Clicking through the Waiting change card: Queued, then Sending, then Sent, each showing its sentence and its ways out
Sending has three ways out, and the third is the one I'd have missed in prose. The server accepts the change, or it answers with an error, or it doesn't answer at all and the change goes back to waiting.
In prose, the no-answer case is one clause among many. On the card it's an arrow back to Queued, and if that arrow were missing I'd see the gap.
---
Screens sketch what a person will see
When a change alters what's on screen, the plan can sketch it. The sketch is boxes with words in them and a few numbered notes. For this feature, the whole visible change is one new chip in the header that counts the waiting changes.
!The screen card named Header: a rough sketch of the app header with one new chip for the waiting changes count, and a numbered note saying when the chip shows
It's rough on purpose. The card says what appears and where, and it leaves how it looks to the design. That's enough to agree on what a person sees before anyone builds it. The one note on this card settles two questions I'd otherwise ask in review: the chip shows only for a signed-in reader, and it hides when the count is zero.
A state can also point at its screen, so picking a state shows the screen that goes with it. The offline plan had no use for that link, because none of its states has a screen of its own. This one comes from another real plan on the same app, for a draft, review and publish flow.
!A states card for an article's status with InReview picked: its sentence and two ways out, and under them a sketch of the Edit article screen in that state with three numbered parts
Now the two cards answer one question together: in this state, what am I looking at?
---
Code notes point at the one line that matters
The fourth card shows a few real lines from a file, with a note pinned under the line it explains.
The offline plan didn't get one. No single line in it needed a sentence, so the plan step left the card out. This picture is from another real plan on Conduit, for a bug where the article feed kept showing the old articles after you picked a new tag.
!The code card for article.api.ts: line 44 highlighted, with a note under it saying this line keeps the old articles on screen and is the one to delete
The whole fix is deleting that one line, and I'd rather read why under the line itself than three paragraphs away from it.
---
Sending the plan back
Once you can see the plan, you can change it before any code exists.
That happens at two points. Before the plan, the spec marks the questions the request left open, and the Clarify step has the agent ask you each one and write your answers into the spec. Once the plan is written, you comment on it in the viewer: hover a line, type a note, or strike a call-path row. Each comment waits as pending under its line.
When you're done, Refine sends every pending comment on the plan to the agent in one prompt. For each one it names the line and the section, quotes the text and gives your note, and the agent edits plan.md in place. The comments then show as applied, which means sent, not checked. I read the new plan before I move on to tasks, and comment again on anything it missed.
---
How the plan step picks the cards
There's nothing to set up. The plan step writes the plan, then reads the change and decides which cards it needs.
!The spec goes into the plan step, which reads the change: a small change leads to a plain plan, and a bigger change leads to the plan plus the cards it needs, with a note that it writes down what it picked, and then to the viewer drawing the cards
A small change gets none: renaming a link in the header went through with a plain plan. A bigger one gets only the cards that fit, and the plan step writes down which ones it picked. If it skipped one you wanted, ask for it and run the plan step again, or write the block yourself.
After the cards are written, a check opens every file and line they cite and reports a missing file or a line past the end of one. On a states card it stops on a state nothing reaches and on a dead end that isn't marked final. The result is recorded on the spec when the plan step closes, so a failed check shows up instead of hiding.
I ran three features with no hints, and each got a different set of cards. One of them added a label to two pages and got no screen, which I'd call a miss.
---
Try it
Update SpecKit Companion in VS Code to 0.37.0 or later, run the plan step on a change that isn't tiny, and open the plan.
The plan blocks page in the docs has the grammar of each card, including how to add one to a plain Spec Kit run. If you haven't seen the viewer these cards live in, Give Spec Kit Superpowers is the tour.
---
What I can and can't say yet
You see more of the plan, sooner, and you can change it before any code exists. Whether that makes the code better, I haven't measured.
If a plan of yours got a card that was wrong, or needed one it didn't get, open an issue with the plan. Those are the cases I want to see next.
1 comment
Mentions
What Is WebMCP? Why We’re Adding It to the Control Plane Console 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. TL;DR - What is WebMCP? A draft specification, developed in the W3C Web Machine Learning Community Group, that lets a web page register “tools” for AI agents. Each tool is a JavaScript function with a natural-language description and JSON Schema inputs. - How is it different from MCP? An MCP server runs as its own process, on your machine or a remote server, and is available to agents anywhere. WebMCP runs inside the web page while it is open, with the page’s existing state and the user’s signed-in session. They are complementary. - Which browsers support it? Per Chrome’s documentation, WebMCP is available behind a Chrome flag and through an origin trial starting in Chrome 149. It is subject to change. - What is Control Plane doing? Agents can already operate Control Plane through the hosted Control Plane MCP server and AI plugins. Control Plane is adding WebMCP to the console in December 2026, and it will let agents use everything the console can do. - Is it secure? The model keeps the user and the agent in the same browser session, limits tools to the registering page and same-origin frames by default, and Chrome notes that tools execute visibly on the page. Follow Chrome’s security guidance. What Is WebMCP? 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 and the draft specification. Who is developing it? 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. What does the API look like? 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. } }); How Is WebMCP Different From MCP? 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| As a separate process, on the user’s machine or a remote server Who hosts it| The web page itself| The user or the service provider (Control Plane hosts its server at https://mcp.cpln.io/mcp) Authentication| The user’s existing signed-in session| Handled by the server (Control Plane’s MCP server uses OAuth with per-org consent) Best for| Agents working in the browser that need a site’s full UI and page state| Coding assistants, chat clients, and automation that do not need a browser page Availability| While the page is open| Whenever the client can reach the server What it exposes| Tools| Tools, resources, prompts, and other MCP primitives Why should a platform offer both? 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 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. How Do AI Agents Use a Website’s UI With WebMCP? 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: 1. The agent discovers the tools the page exposes. 2. It picks a tool from its natural-language description. 3. It passes arguments that match the tool’s JSON Schema. 4. The tool runs inside the page, with the page’s existing state and the user’s session. 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. How Do AI Agents Work With Control Plane Today? 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. Which cloud platforms support MCP and AI agents? 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. How can AI agents manage cloud infrastructure? An agent needs a structured interface to the platform, authentication it can use safely, and guardrails. On Control Plane, agents have these options today: - Hosted MCP server. It is hosted at 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 MCP documentation. - MCP client support. It works with any MCP-compatible client. Documented setups include Claude Code, Claude Desktop and claude.ai (listed connector), ChatGPT (listed plugin), OpenAI Codex, Cursor, VS Code with GitHub Copilot, Google Antigravity, Amp, and OpenCode. Every path uses OAuth with per-org consent. See the AI overview. - AI plugin. The Control Plane AI plugin works with Claude Code, Codex, and Antigravity CLI. It bundles the Control Plane MCP server (the full profile in Claude Code, core in Codex and Antigravity CLI), Control Plane skills, guided agents for workload troubleshooting and for Kubernetes, Compose, and Helm migration, plus slash commands and guardrail rules. It is also listed in Anthropic’s community plugin marketplace, where every listing has passed Anthropic’s review. - CLI, Terraform, and Pulumi. Agents that already write infrastructure as code can keep using these tools. 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. 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. Example: An Agent Investigates a Slow Workload 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: 1. Scope. It confirms the org, GVC, workload, and location. When the connection has several orgs, the agent asks which one to use. 2. Observe. It runs a one-call workload diagnosis and reads workload events, deployments, logs, metrics, and traces. 3. Correlate. It lines up the deployment time with the change in latency and errors. 4. Propose. It recommends a rollback and states the expected effect. The readonly profile has no write tools, so the agent stops at the recommendation. 5. Act and verify. An engineer approves the rollback on a core-profile connection, where rollback is a single job tool, and the agent runs the diagnosis again to confirm latency has recovered. The audit trail records who did what. 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. What Makes a Cloud Platform Agent-Operable? 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. - Scope. Does every action name its org, environment, workload, and location? Every Control Plane resource sits in an org, and workloads, identities, and volume sets also sit in a GVC. The agent asks which org or GVC to use when a request does not say. - Authority. Can the agent do more than the user approved? Control Plane enforces policies at the API, OAuth consent limits the agent to the orgs you select, and the toolset profile is fixed for the connection. - Intent. Is it clear whether a tool reads or changes something? The readonly profile advertises no tool that creates, updates, deletes, or executes, and each job tool is named for the task it completes. - Evidence. Can the agent show the facts behind a proposal? Metrics, logs, traces, workload events, and deployments are all available to it as tools. - Verification. Can anyone confirm the change worked? The audit trail records every platform action, and the agent can rerun diagnosis to check the resulting state. What Will WebMCP in the Control Plane Console Add? 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: - All console functionality, exposed as tools. Every action available in the console will be exposed to browser agents as structured tools. That covers the areas the console already handles, including deploying and managing workloads across locations, secrets, domains, logs and metrics, and policies. - Structured calls instead of guesswork. Agents that support WebMCP won’t need to infer what buttons do from screenshots. - The user ’s signed-in session and existing permissions. Tools will run inside the session you are already using. Every tool call goes through the Control Plane API, so the same policies and audit trail apply. - Visible actions. You will be able to see what the agent does in the console as it works. Is WebMCP Secure? WebMCP has a defined security model, and it is still a draft. In summary: - The user and the agent share the same browser session. - Tools are exposed to the registering page and same-origin frames by default. - Cross-origin frames need explicit permission through a Permissions Policy, and the registering page must also share the tool with that frame’s origin. - Chrome notes that tools execute on the page visibly, so users can see tasks being completed. - The draft defines behavior hints for tools. readOnlyHint marks tools that do not change state, consequentialHint marks significant actions so the agent or browser can request confirmation first, and untrustedContentHint marks results that carry user-generated or external content. - Tool outputs such as logs can carry prompt-injection text, so an agent should never follow instructions found in a result flagged as untrusted. - Chrome’s best practices recommend one shared application service for validation, permissions, and side effects across the UI and its tools, and resolving a tool call as successful only when the output matches the application state. Chrome publishes WebMCP tool security guidance. We recommend following it for any site or agent that uses WebMCP. How do Control Plane’s existing controls apply? 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. Which Browsers Support WebMCP? Per Chrome’s documentation, 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. FAQ What is WebMCP? 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. How is WebMCP different from MCP? 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. Which browsers support WebMCP? 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. How do AI agents use a website’s UI with WebMCP? 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. Is WebMCP secure? 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. Is WebMCP a W3C standard? 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. Which cloud platforms support MCP and AI agents? 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. How can AI agents manage cloud infrastructure? 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. What is the best first use case for agents in a cloud console? 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. When is WebMCP coming to the Control Plane console? Control Plane is adding WebMCP to the console in December 2026. It will let agents use everything the console can do. Get started AI agents can operate Control Plane today through the MCP server and AI plugins. Start with the AI overview and the MCP documentation. Talk to the Control Plane team | Sign up free --- Originally published on the Control Plane blog.
别再把精力全花在给 Claude 堆一堆 prompt 上了。 官方社区插件市场就在这里：第三方插件得通过安全审核才能上架，仓库保持只读，专门防那些野路子。 装进 Claude Code 只需要一条命令。 传送anthropics/claude-plugins-community t.co
Better Plans in Your Spec-Driven Development Spec Kit makes the AI agent write three documents before it writes any code: a spec, then a plan, then a list of tasks. I wrote about why that order helps in Stop Vibe Coding, Start Shipping. When the work is spec-driven, the code follows the plan. The plan is where the agent says which files it'll touch and how the change will work. So it's the last place where a wrong turn costs one sentence to fix, and the one place I need to understand fully before I say yes. It's also the one I've been skimming. The plan step writes several documents: the plan itself, plus research notes, a data model and contracts. The plan for one feature on a real app came out at about a hundred lines. I read the spec, and then I scrolled the plan. That's backwards, because understanding the plan is one of the basic steps in Spec Kit: the tasks and the code both come from it. If I can't picture what the plan says, I won't notice when it's wrong, and by the time I do, changing it costs code instead of a sentence. --- Where the idea came from The push came from html-plan, a Claude Code plugin by Thariq Shihipar. It writes a plan as one interactive page: call stacks, code with notes pinned to lines, state machines that show the screen for each state, and small mockups. You comment on any part, pick answers to its open questions, and paste one response back to the agent. I wanted that for Spec Kit, without leaving Spec Kit's documents. Spec Kit already has a home for some of it: open questions get settled on the spec with the Clarify step, and the shape of the data goes in the data model. What it didn't have was a way to see the parts of a plan that are hard to picture from text. SpecKit Companion, the VS Code extension I build for Spec Kit, now draws those parts as cards. They're called plan blocks, and there are four kinds: the functions a change reaches, the states a thing moves through, a rough sketch of a screen, and a note pinned to one line of code. Each one is a fenced block inside plan.md, so it still reads as plain text on GitHub or in a terminal, and the viewer draws it as a card. Each card answers one question I'd otherwise have to work out from the text. !Four questions on the left, each with an arrow to the card that answers it: where does the change go points to call paths, what states does it move through points to states, what will I see points to screen, and which line matters points to code note A plan rarely needs all four. A change with no lifecycle has nothing for the states card to show, so the plan step leaves it out. Every picture below comes from a real plan on Conduit, a public demo app, for a feature that saves favorites while you're offline. Here's that plan open in the viewer. !SpecKit Companion in VS Code with the Offline Favorites plan open on its States section: the Waiting change card with Sending picked, its sentence and its three ways out The plan didn't get shorter, and the text is all still there. What changed is that I no longer have to build the picture in my head before I can question it. --- Call paths show where the change goes A call path lists the functions a change reaches, in order, each with its file and line. Rows the change edits are marked, and so are rows that don't exist yet. This is the card for marking a favorite while offline. !The call-paths card named Offline favorite: the favorite button as the entry, one changed function under it, and two new functions in new files, each with its file path I can see how far the change spreads before any code exists. It starts at the favorite button, edits one function that's already there, and adds two new ones in two new files. If one of those rows sat in a folder I didn't expect, this is where I'd catch it, because a file name in a list is easier to question than the same file name in the middle of a paragraph. The rows aren't read-only. Here I strike one row and leave a question on another. !Striking the enqueue row on the Offline favorite card, then leaving a comment on another row that asks which errors count as no response Both wait as pending comments until I send them, the same as a comment on any other line of the plan. --- States show the life of a thing Some changes add a thing that has a life. Here it's one waiting change: a favorite you made offline that still has to reach the server. The plan names five states for it: queued, sending, sent, dropped and cancelled. The states card draws them as boxes with arrows. Click a state and it shows its sentence and its ways out. !Clicking through the Waiting change card: Queued, then Sending, then Sent, each showing its sentence and its ways out Sending has three ways out, and the third is the one I'd have missed in prose. The server accepts the change, or it answers with an error, or it doesn't answer at all and the change goes back to waiting. In prose, the no-answer case is one clause among many. On the card it's an arrow back to Queued, and if that arrow were missing I'd see the gap. --- Screens sketch what a person will see When a change alters what's on screen, the plan can sketch it. The sketch is boxes with words in them and a few numbered notes. For this feature, the whole visible change is one new chip in the header that counts the waiting changes. !The screen card named Header: a rough sketch of the app header with one new chip for the waiting changes count, and a numbered note saying when the chip shows It's rough on purpose. The card says what appears and where, and it leaves how it looks to the design. That's enough to agree on what a person sees before anyone builds it. The one note on this card settles two questions I'd otherwise ask in review: the chip shows only for a signed-in reader, and it hides when the count is zero. A state can also point at its screen, so picking a state shows the screen that goes with it. The offline plan had no use for that link, because none of its states has a screen of its own. This one comes from another real plan on the same app, for a draft, review and publish flow. !A states card for an article's status with InReview picked: its sentence and two ways out, and under them a sketch of the Edit article screen in that state with three numbered parts Now the two cards answer one question together: in this state, what am I looking at? --- Code notes point at the one line that matters The fourth card shows a few real lines from a file, with a note pinned under the line it explains. The offline plan didn't get one. No single line in it needed a sentence, so the plan step left the card out. This picture is from another real plan on Conduit, for a bug where the article feed kept showing the old articles after you picked a new tag. !The code card for article.api.ts: line 44 highlighted, with a note under it saying this line keeps the old articles on screen and is the one to delete The whole fix is deleting that one line, and I'd rather read why under the line itself than three paragraphs away from it. --- Sending the plan back Once you can see the plan, you can change it before any code exists. That happens at two points. Before the plan, the spec marks the questions the request left open, and the Clarify step has the agent ask you each one and write your answers into the spec. Once the plan is written, you comment on it in the viewer: hover a line, type a note, or strike a call-path row. Each comment waits as pending under its line. When you're done, Refine sends every pending comment on the plan to the agent in one prompt. For each one it names the line and the section, quotes the text and gives your note, and the agent edits plan.md in place. The comments then show as applied, which means sent, not checked. I read the new plan before I move on to tasks, and comment again on anything it missed. --- How the plan step picks the cards There's nothing to set up. The plan step writes the plan, then reads the change and decides which cards it needs. !The spec goes into the plan step, which reads the change: a small change leads to a plain plan, and a bigger change leads to the plan plus the cards it needs, with a note that it writes down what it picked, and then to the viewer drawing the cards A small change gets none: renaming a link in the header went through with a plain plan. A bigger one gets only the cards that fit, and the plan step writes down which ones it picked. If it skipped one you wanted, ask for it and run the plan step again, or write the block yourself. After the cards are written, a check opens every file and line they cite and reports a missing file or a line past the end of one. On a states card it stops on a state nothing reaches and on a dead end that isn't marked final. The result is recorded on the spec when the plan step closes, so a failed check shows up instead of hiding. I ran three features with no hints, and each got a different set of cards. One of them added a label to two pages and got no screen, which I'd call a miss. --- Try it Update SpecKit Companion in VS Code to 0.37.0 or later, run the plan step on a change that isn't tiny, and open the plan. The plan blocks page in the docs has the grammar of each card, including how to add one to a plain Spec Kit run. If you haven't seen the viewer these cards live in, Give Spec Kit Superpowers is the tour. --- What I can and can't say yet You see more of the plan, sooner, and you can change it before any code exists. Whether that makes the code better, I haven't measured. If a plan of yours got a card that was wrong, or needed one it didn't get, open an issue with the plan. Those are the cases I want to see next.
@trq212 @trq212 I made some update to the plug-in and I raised them in this issue : claude-plugins-community#2892 - Select any part of the plan and comment - Light / Dark theme support - "Other" option on decision
html-plan 오 이거 좋네요. Claude Code 커뮤니티 플러그인/스킬. Claude Code 팀 Thariq가 만들었구요. github.com/anthropics/claude-plugins-community/tr… 구현 계획을 긴 마크다운 대신 한 장의 인터랙티브 HTML 페이지로 만들어 줘요. 휙 읽고 결정할 수 있게 설계되어 있어요. UI 목업, 상태, 콜스택, 스키마, 코드 등.. 여러 정보를 시각적으로 보여주는게 좋다요. 레벨 별로 펼쳐서 볼 수도 있는데, 여러 선택과 코멘트 이후에 답변 만들어서 클로드에 붙여넣으면 더 정확한 구현 ㄱㄱ 클로드에게 이걸 던져주세요. claude plugin marketplace add anthropics/claude-plugins-community claude plugin install html-plan@claude-community
Instead of searching for unvetted third-party tools, Claude Plugins — Community gives you a security-scanned marketplace for Claude Code. anthropics/claude-plugins-community #Python #GameDev #OpenSource
Community Plugins That Extend Claude – claude-plugins-community #Shorts Community Plugins That Extend Claude – claude-plugins-community. Community Claude plugins and extensions. GitHub: anthropics/claude-plugins-community 💡 Why it's useful: Broad range of community integrations. ⚠️ Keep in mind: Community projects vary in quality, security and maintenance. Which repo should we break down next? Tell us in the comments. Subscribe to @developerosindia for one AI GitHub repo explained every day. #Shorts #AIAgents #Claude #GitHub #OpenSource
@trq212 Have been using it quite a lot, it's quite hard to read the result in some cases and smaller devices. I've made a few tweaks to make it follow light/dark mode and read better on phones. Here's the change on my fork, lmk what you think github.com/anthropics/claude-plugins-community/co… t.co