Why it matters
WebMCP is an emerging browser-side way for a page to describe actions as tools an agent can discover and invoke. It can make a human-facing workflow easier for a browser assistant to use without replacing the page or its existing server-side authorization.
This is different from an AI assistant built into your product and from a backend MCP server. The page offers tools in the current browser session and context. Browser support and the specification are still evolving, so treat it as progressive enhancement and keep the ordinary UI usable.
Decisions to make
- Choose one customer task whose existing UI can be described as a small, meaningful tool.
- Decide whether a form annotation or a JavaScript tool best represents that task.
- Define the tool name, input schema, visible result, and errors in customer terms.
- Choose which actions require the user to review or confirm before the final step.
- Keep tenant, session, and permission checks in the server action the tool calls.
- Decide how tools appear and disappear as the page, active account, or user access changes.
Build checklist
- Feature-detect WebMCP and leave the normal interface fully functional without it.
- Expose only tasks available in the current page and authenticated user context.
- Reuse the same validated product operation that the visible UI uses.
- Return a clear result the user can inspect in the page, not only a hidden tool response.
- Test missing inputs, wrong-account requests, expired sessions, and denied actions.
- Review draft-spec changes and test supported browsers before treating the integration as stable.
Common mistakes
- Treating WebMCP as a backend MCP endpoint or as a substitute for product APIs.
- Exposing an unrestricted mutation because a tool is available only in the browser.
- Removing the human UI or assuming every customer browser supports the draft API.
Tools & references
3 starting points to compare or study. Check fit, maintenance, terms and current capabilities before choosing one.
