WebMCP is a browser-native direction.
WebMCP describes a way for web pages to register tools that a compatible browser or web agent can discover and call. The page can expose structured operations through JavaScript or declarative HTML patterns instead of requiring an agent to infer every action from pixels, labels, and arbitrary page layout.
The proposal is early and subject to change. Treat current browser flags, origin trials, APIs, and examples as experimental documentation rather than a stable platform guarantee. Re-check the browser support and specification status before publishing implementation instructions.
A page tool is not the same as a remote MCP server.
A remote MCP server is a service or process that exposes capabilities over an MCP transport. WebMCP puts the capability surface in the page and browser context. The page can use its existing user session and application state, while the browser and site need to decide how tools are exposed, approved, and constrained.
This can be useful for first-party sites because the page knows its own actions and validation rules. It does not mean a page should expose every internal mutation, and it does not eliminate authentication, CSRF, authorization, or user-confirmation requirements.
Choose structured tools over blind actuation when possible.
A page-native tool can describe the input and call the site's own application logic, which may be clearer than asking an external browser automation server to find a button and hope the page state matches. Keep the tool name, input, result, side effect, and approval step visible.
Playwright MCP remains useful when a site does not provide page-native tools, when the task is cross-site testing, or when the goal is to exercise the browser as a user would. The choice is about the available interface and required evidence, not a claim that one approach replaces the other.
Design for permission, state, and recovery.
A browser-native tool may run with a user's current page state, so the site must make the account, selection, confirmation, and resulting record visible. Test stale forms, missing permissions, expired sessions, duplicate submissions, and navigation away from the expected page.
Start with read-only or reversible tools. Keep irreversible actions behind a user confirmation or explicit approval, and give the agent enough result evidence to tell the user what changed. The page is part of the security boundary, not just a presentation layer.
Related service for this problem
Agent-Readiness Review
Check the browser tool surface and its human approval and recovery paths.