Googleが発表した新Web標準ドラフト――WebMCP。実際どうなの？ IO Extendedで実装・登壇して分かったことGoogle's WebMCP draft standard enables websites to expose MCP servers directly…

Google has put forward a new Web standard draft known as WebMCP, a specification that would let websites expose Model Context Protocol (MCP) servers directly inside the browser. The idea matters because it points toward a future in which AI agents can call the features of an ordinary web page through a standardized interface, rather than depending on separately hosted services or bespoke integrations. Because it is still a draft, the details are likely to change, but the direction signals how the web platform is beginning to treat AI agents as first-class consumers of web content.

To understand WebMCP, it helps to review the Model Context Protocol itself. MCP is an open standard, originally introduced by Anthropic, that defines how AI models and agents connect to external tools, data, and services. An MCP server advertises a set of capabilities—functions an agent can invoke, resources it can read, and so on—and an AI client discovers and calls them through a consistent protocol. In most existing deployments, MCP servers run as standalone processes or remote services that sit outside the browser.

WebMCP appears to reframe that model by bringing the server into the page. Instead of an agent connecting to an external endpoint, a website would be able to declare its own MCP server that lives in the browser context and exposes the page's functionality directly. In practice this could allow an agent operating alongside the user, such as an assistant built into the browser, to discover what a given site can do and to trigger those actions in a structured way. The approach aligns with a broader industry push to let agents act on the web more reliably than screen-scraping or simulated clicks typically allow.

The proposal was presented in connection with Google I/O 2026, the company's annual developer conference, where new web platform directions are frequently outlined. Following the main event, Google Developer Groups (GDG) chapters around the world host community-run I/O Extended gatherings that recap and expand on the announcements. It was at one of these, Google I/O Extended Osaka 2026, that a developer active under the handle tanahiro2010, a member of GDG Greater Kwansai, ran a hands-on session whose title translates roughly as "Let's build WebMCP and call it from an AI agent."

The session put the draft into practical use, walking participants through implementing a WebMCP-based server and invoking it from an AI agent. According to the author's account, the exercise offered a concrete look at how the specification behaves in real code, as well as where it still falls short. That framing is notable: rather than presenting WebMCP as a finished capability, the write-up treats it as an early-stage draft whose rough edges become visible only when you try to build something with it. Readers looking for a production-ready toolchain are likely to find gaps, missing pieces, and behavior that may shift as the specification matures.

For context, WebMCP sits within a fast-moving landscape of agent-oriented tooling. MCP has gained traction across the ecosystem since its debut, with a growing number of clients, servers, and directories, and several major AI vendors have signaled support for the protocol. At the same time, browser makers and AI companies have been experimenting with ways to let agents operate interfaces directly, from computer-use features to accessibility-tree-based automation. A browser-native way to publish MCP capabilities would fit naturally into that trend, potentially giving site owners more control over how their functionality is exposed to agents compared with approaches that infer intent from the rendered page.

Because WebMCP remains a draft, its scope, security model, and API surface are all subject to revision, and it is too early to say whether it will be adopted broadly or standardized in its current form. Questions around permissions, user consent, and how sites authenticate agent access will likely be central to its evolution. Developers considering an early look should also weigh the maintenance cost of building against a moving target, since interfaces that work today may need to be rewritten as the draft changes.

For those curious about where agent-web interaction is heading, hands-on reports like this one provide a grounded view of both the