Compare
Dornick vs MCP-B
MCP-B is the WebMCP plumbing — polyfill, transports, relay, extension — that connects your page to agents elsewhere. Dornick is the agent, in the page. Both speak the standard.
Pick Dornick when…
- You want an agent running in the page, not just tools exposed from it.
- You want the provider surface generated from config you already wrote.
- You need the consumer side too — calling the page's tools, not only publishing them.
- You want the rest of an agent SDK around it: VFS, skills, hooks, multi-agent, compaction.
Pick MCP-B when…
- You only need to expose tools; the agent lives somewhere else entirely.
- You want the local relay that forwards page tools to Claude Desktop or Cursor.
- You want their MV3 extension template or smart-dom-reader.
- You're building your own agent and just need conformant WebMCP plumbing.
Same standard, different jobs
MCP-B (the @mcp-b/* packages) is the most
complete WebMCP toolkit out there. It ships a conformant polyfill, postMessage and extension
transports, a local relay that forwards page tools to desktop MCP clients, an MV3 extension
template, and React hooks.
It is genuinely good, and it is not the same category as Dornick.
MCP-B answers: “how do I expose my page’s functionality to an agent that lives somewhere else?” — Claude Desktop, Cursor, a browser extension.
Dornick answers: “what if the agent lived in the page?”
Compare on the dimensions
| Dimension | MCP-B | Dornick |
|---|---|---|
| WebMCP polyfill | Yes | Yes (@dornick/webmcp, zero-dep) |
| Publish tools from the page | Yes, you write them | Yes, generated from your config |
| Consume the page’s tools | — | Yes, as real agent tools |
| An agent that runs in the page | No | Yes — that’s the product |
| Transports / desktop relay | postMessage, extension, local relay | HTTP MCP client + server |
Declarative <form toolname> | Yes | Yes |
| Agent SDK around it | — | VFS, tool loop, skills, hooks, multi-agent, compaction |
| Chat UI | — | Shadow-DOM, style-isolated |
| Core size | Modular | ~38 KB core, ~7 KB polyfill standalone |
| License | MIT | MIT |
The part that costs you nothing
The difference that matters in practice is how much you write.
With any WebMCP toolkit, publishing a tool means authoring it — a name, a description, a JSON Schema, an execute callback, for every operation you want to expose.
Dornick already has your data points. So it generates them:
new Dornick({ config, transport, webmcp: { publish: true } });
// dornick_set_email, dornick_set_plan, … one per configured dataPoint,
// each schema derived from the type / pattern / allowedValues you already wrote.That is not a better polyfill. It is a different starting point — Dornick knows what your form is for, because you told it, so the tool surface falls out of the configuration.
Use them together
This is the honest recommendation, not a hedge.
Dornick’s polyfill explicitly never clobbers: if MCP-B’s polyfill is already installed,
Dornick detects it, installs nothing, and uses theirs. Both write to the same standard
document.modelContext surface.
So a reasonable stack is: Dornick as the in-page agent and provider, MCP-B’s local relay carrying those same tools out to Claude Desktop. Neither project has to lose for the other to be useful.
Where neither of us can help
Worth stating plainly, because it applies to both projects equally: a polyfilled page is
reachable by extensions, CDP/Playwright drivers, and page script — but not by the
browser’s own built-in agent. Native document.modelContext is a browser IPC surface, and
no polyfill reaches it.
For that you need the real thing: an origin-trial token (Chrome 149–156) or
chrome://flags/#enable-webmcp-testing. Any project claiming otherwise is overselling.
FAQ
Do Dornick and MCP-B conflict if both are on the page?
No. Both polyfills detect an existing document.modelContext and stand down. Dornick's reports foreign-polyfill-present and installs nothing, returning MCP-B's object. Load order doesn't matter.
Can I use MCP-B's relay with Dornick's published tools?
Yes. Dornick publishes onto the same standard document.modelContext surface, so MCP-B's local relay and extension can pick up Dornick's tools like any others. That is the intended composition.
Ship an agent-driven flow this afternoon.
Install Dornick, paste a config, and your form turns into an agent that fills its own inputs.