From discoverability to usability: what WebMCP changes for people who build websites

For thirty years the question was whether the search engine could read your page. The question opening up now is whether an agent can use your site.

What WebMCP is, in one sentence

WebMCP is a proposed browser API that lets a page declare its own functionality as tools an agent can call. Instead of simulating clicks and form fills on the interface, the agent completes the task by calling functions and forms the page exposes with a declared schema. The proposal is being developed in a community group and is not yet a standard implemented in browsers.

The shift WebMCP represents

The most common reading about agents is that they will browse interfaces built for people on their own, clicking and filling fields by imitation. That approach works in a demo and fails at scale, because it depends on a stable layout and on visual interpretation. Anyone who has watched a redesign break every test script in the building knows how this movie ends. These agents reach your site as one more category of bot, and the decision about which ones to let in is in the AI bots guide.

The WebMCP proposal flips the responsibility. The site declares what it can do, with an explicit input and output contract, and the agent calls that function. For people who build sites, this brings front-end work closer to the discipline of designing a public API. In commerce, this explicit contract already has its own protocols, described in agentic commerce in e-commerce.

The difference between WebMCP and MCP

The similar name causes confusion with the Model Context Protocol, MCP, which connects assistants to data and tool servers. With MCP, someone maintains a server outside the browser, and the assistant connects to it to query a system, such as a customer database or a data platform. With WebMCP, the page open in the browser declares its own tools, and the agent operating in that browser finds them right there, inside the session of whoever is using the site.

The consequence for people who build sites is one of responsibility. With MCP, the integration is a back-end project, with access and permissions defined on the server. With WebMCP, the tool lives in the front end and inherits the page’s context, including the session of the logged-in person, which makes choosing what to expose a product decision and a security decision at the same time.

What WebMCP changes in technical SEO work

• Capability inventory. Before exposing anything, you need to answer what the site actually does: check availability, calculate shipping, book, compare plans, find a location. This inventory rarely exists in writing.
• Naming and description. Each tool needs a name and a description in natural language that a model understands without ambiguity. It is semantic work applied to functions, with the same rigor we apply today to titles and headings.
• Security boundary. Exposing a function is different from exposing content. Scope, authentication and action limits need to be decided before implementation.
• Forms take center stage again. The proposal treats form elements as natural tool candidates, which rewards correct semantic markup in a place where many sites have piled up technical debt for years.

What I would not do with WebMCP yet

Rewriting a site’s architecture around a specification still in development is risk without a proportional return. The open questions listed in the repository itself affect structural decisions, and an implementation built now will probably be rebuilt.