Coworkkit vs WebMCP
Coworkkit is an AI co-worker inside your web app: it talks, sees the screen, and does the work as the signed-in user, with no AI backend to build. WebMCP is an early browser proposal (a draft W3C Community Group report) that lets a web page register tools so an agent already in the browser can call them. (It's the browser cousin of MCP, which is a backend protocol for connecting a model to servers, a different job we don't cover here.) The two point in opposite directions, and that direction is the whole story.
The short version
Choose Coworkkit if
you want to ship your own co-worker to your own users: it talks to them, sees only what you've declared, and operates the interface you built, as them, never beyond them.
Choose WebMCP if
your goal is the other direction, making your page legible to whatever agent a visitor brings (their own assistant, a browser agent), so an outside agent can discover and call your tools.
At a glance
Where each one sits, and which way it faces. Not a price comparison, a direction comparison: who owns the agent, and what it can reach before you write a line of code.
| Coworkkit | WebMCP | |
|---|---|---|
| What it is | A runtime that puts an AI co-worker inside your web app | A draft browser standard for a page to expose tools to an in-browser agent |
| Whose agent | Yours. You ship it, brand it, set how it behaves | Whoever's. Whatever agent the visitor already brought to your page |
| Maturity | Runs in production in our own product today | Early: a draft W3C proposal in a Chrome origin trial, no mainstream agent calling its tools in production yet |
| Exposed by default | Nothing, until you declare it, one action at a time | A registered tool is callable by whatever agent is present in that session, no per-agent allowlist |
| What you build | Annotations on the UI you already have, plus one token route | Tool registrations against your page logic, annotated for whatever agent reads them |
| Modality | In-app voice, operating the UI as the user | A tool-call interface for an external agent; no voice, no co-worker |
| Safety model | Every action gated at dispatch; ceiling is always the user's own permissions | Inherits the session's cookies and permissions; the agent is one you don't control |
| Best fit | Working alongside a person who has your app open now | Being discoverable to the open agent ecosystem |
Publish your surface
Your tools, offered to whoever turns up.
Ship your own co-worker
Nothing exists for it until you declare it.
Where does a co-worker pull ahead of WebMCP?
The difference is who owns the agent and what it can touch. WebMCP publishes your page's tools outward: you register them, and whatever agent is in the session, an assistant the visitor brought, a browser agent, code you didn't write and can't see the prompt of, can call them. The instinct is good (describe your page on purpose instead of letting an agent scrape your DOM), but the default is exposure: you hand out the tools, then reason about what you didn't mean to hand over.
Coworkkit runs the other way. The agent is yours, and nothing exists for it until you declare it, one action, one element, one surface at a time. It never leaves the browser tab: it acts through the interface you built, inside the user's own already-authenticated session, under that user's own permissions, with a confirmation gate on anything risky. It cannot do anything that user could not do themselves, because there's no other path from the model to your backend. You're not publishing a surface to an outside agent, you're giving your own users a co-worker that works the app for them.
Same room, opposite doors. WebMCP makes your page readable by agents other people bring. A co-worker is the agent you bring to your users.
When is WebMCP the right tool?
Use WebMCP if the goal is to make your site legible to the open agent ecosystem, so a visitor's own assistant can find and operate your page. That's a real and different aim from shipping your own co-worker, and if agent-readable-web is where you're placing a bet, it's the emerging standard to watch. Two honest caveats: it's early (a draft in a Chrome origin trial, with no mainstream agent consuming it in production yet), and it hands your tools to an agent you don't control. Coworkkit is the opposite trade on both counts: production today, and the agent is yours.
FAQ
- Does Coworkkit use WebMCP or MCP?
No. Coworkkit isn't a WebMCP page or an MCP client or server, and doesn't speak either. It's a runtime that ships your own co-worker into your app; it acts through your UI inside a live user session, not by publishing tools for an outside agent to call.
- Is WebMCP the same thing as MCP?
No, related name, different thing. MCP is a backend protocol for connecting a model to servers and tools. WebMCP is a separate, newer browser proposal for a page to expose tools to an in-browser agent. Different specs, different standards bodies, similar spirit.
- Is WebMCP production-ready?
Not yet. As of August 2026 it's a Draft Community Group Report at the W3C, running as an origin trial in Chrome, with no mainstream AI agent calling the tools in production. Worth watching, not something to plan a launch around today.
- Can I use WebMCP alongside an in-app co-worker?
Yes, they don't compete for the same job. WebMCP makes your page callable by agents your visitors bring; a co-worker is the agent you ship to your users. A product could reasonably do both.
- Is WebMCP a security risk?
That's the wrong frame, and I'd rather be precise. WebMCP tools run under the session's own permissions, the same ceiling any in-session automation has. The real difference from a co-worker isn't safe-versus-unsafe, it's the default and the owner: WebMCP exposes tools to an agent you don't control, while a co-worker starts from nothing declared, gates each action, and acts strictly as the signed-in user.
- What's the alternative to WebMCP if I want to ship my own agent?
That's Coworkkit's lane. WebMCP publishes your page's tools to whatever agent a visitor brings; if instead you want to ship your own co-worker that acts as the signed-in user inside your app, that is a different tool, and it is what Coworkkit does. The two can also coexist.