Microsoft·Google WebMCP Commentary: In the browser agent era, why the tool boundary to be exposed by the site must be designed first before screen automation

Publication date: 2026-06-24 | Category: ai News

1. One-line problem definition

Key takeaways: As browser agents become commonplace, it is no longer enough for websites to design only the screen visible to the human eye.

Browser automation today largely involves reading the screen, finding buttons, and mimicking clicks. This may look good for demos, but it's brittle in real-world service. If the button text changes, an extra modal pops up, or the accessibility label is missing, the agent can do the same thing incorrectly.

This is the real problem that WebMCP targets. The proposal is for the website to structure functions to agents such as “You can search here,” “You can check the price of this product,” and “Changes to this reservation require user confirmation.” Coverage includes search, commerce, reservations, SaaS, and admin tools that require AI agents to call site functions within the browser. On the other hand, it is still too much for a blog with a simple introduction page or no external execution.

2. First, conclusion

Key takeaway: WebMCP is not a “SEO tag for AI”, but rather an executable contract required when entrusting site functionality to an agent.

My judgment is clear. Not many teams will fully adopt WebMCP in 2026. This is because it is still in the W3C Community Group Draft stage and is being verified through origin trials of Chrome and Edge. But product and front-end teams need to start preparing now. The reason is simple. As soon as the browser agent acts within the actual user's login session, the site must manage not only a “clickable UI” but also a “callable tool” as a product surface.

The team that is right for you now is a service that has a lot of repetitive actions, such as creating forms, searches, filters, shopping carts, reservations, and tickets, and is trying to experiment with browser agent inflow. The teams that still need to be observed are services that only have high failure costs, such as changing member information, making payments, or sending externally. Such teams should design approval, revocation, and audit logs before implementing WebMCP.

3. Decomposition of core structure

Key takeaway: WebMCP is a structure that places a “tool list” between web pages, browsers, and agents.

To put it simply, for a novice developer, the existing web UI is a menu board that people read. WebMCP is an agent-readable order book. People can order directly by looking at the menu, but rules such as “Product ID is a string,” “Quantity is a number,” and “Cancellation requires user confirmation” are written more clearly on the order form.

The structure is easy to see in four layers.

1. Site Layer: The web app has the actual functionality as an HTML form or JavaScript function. Functions such as search, filter, quote calculation, and reservation change.
2. Tool registration layer: Site registers name, description, input schema, and execution function through the same API as navigator.modelContext
3. Browser mediation layer: Browsers such as Chrome or Edge expose this tool to the agent and manage origin and user session boundaries.
4. Agent layer: An in-browser agent, such as Gemini in Chrome, discovers tools and selects the tool call that matches the user's request.

The point is not “the website operates a new MCP server.” The browser acts as a bridge, and the site declares functions that can be called from within its pages.

4. Description of design intent

Key takeaways: The design intent of WebMCP is to make agents avoid guessing the screen.

The way browser agents scrape the DOM or mimic clicks relies heavily on human UI. A good UI for humans and a stable execution interface for agents are different. For example, a person might see the “Apply Discount” button and understand the context, but an agent might be confused as to whether the button is Apply Coupon, Confirm Payment, or View Promotion.

WebMCP separates tool name, natural language description, input schema, and execution results to reduce this uncertainty. What you get is stability. What you give up is the hidden freedom of automation. Because the site must explicitly expose the tool, initial design costs are higher than the “let the agent handle all the screens” approach.

But I think this cost is necessary. The moment an agent shares a user's login session, mistakes can lead to real changes, not just wrong answers. Therefore, the value of WebMCP is that it allows you to decide “which features not to expose” rather than exposing features.

5. Evidence and Comparison

Key takeaways: The real comparison for WebMCP is not the MCP server, but DOM scraping, dedicated APIs, and accessibility-based automation.

As of June 2026, there are three reasons. First, the W3C Web Machine Learning Community Group's draft WebMCP has the status of Draft Community Group Report. Second, Chrome is experimenting with WebMCP through an origin trial after Chrome 149, and Edge also released a separate origin trial. Third, the main implementation descriptions cover both the method of exposing HTML forms declaratively and the method of registering JavaScript functions as imperatives.

6. Actual operation flow / step-by-step execution method

Key takeaways: Don't expose payments or account changes from the beginning, start small with read-only tools.

1. Categorize actions to be left to agents. Divide into view-only, create draft, change after user confirmation, and absolutely no automation.
2. Select the first tool as read-only. For example, functions that do not change data even if they fail, such as searchDocs, getProductPrice, filterEvents Good.
3. Make the input schema small. Don't take everything as one string, instead use fields like productId, dateRange, region Share.
4. Sensitive actions require user confirmation. Reservation cancellation, payment, personal information change, and external shipment must go through the browser confirmation UI rather than running the agent alone.
5. Leaves a call log. Failure analysis is possible only when the tool name, input value summary, user confirmation, execution result, and reason for failure are saved.
6. Keep the regular UI fallback. Even without WebMCP, people should be able to do the same things with existing forms and buttons.

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: 'searchDocs',
    description: 'Search public help documents by keyword',
    inputSchema: {
      type: 'object',
      properties: {
        query: { type: 'string', description: 'Search keyword' }
      },
      required: ['query']
    },
    handler: async ({ query }) => {
      return await window.helpCenter.search(query);
    }
  });
}

The example above is intentionally read-only. Start at this level so that failure to select a tool does not lead to actual customer harm.

7. Pitfalls

Key takeaway: The most dangerous mistake in WebMCP is believing that “the agent will understand”

• Pitfall 1: Writing tooltips like marketing copy
  Prevention: Instead of “finds the best products”, say “takes product ID and region and returns current availability” Write:
  Recovery: Further narrow the description and schema based on the incorrectly called log.
• Pitfall 2: Exposing changes without confirmation
  Prevention: Payment, cancellation, deletion, and external transfer must require user confirmation.
  Recovery: When a problem occurs, unregister or originate the tool. Retrieve the trial token and check the extent of damage using the log.
• Pitfall 3: Neglecting existing UI accessibility
  Prevention: WebMCP is not a substitute for accessibility. Labels, roles, error messages, and keyboard flows need to be organized together.
  Repair: Screens with a lot of agent failures will have their form structure and accessibility labels fixed before WebMCP.
• Pitfall 4: Exposing all features as tools
  Prevention: Register only the top 5 tools first by frequency of use and cost of failure
  Recovery: Tools with low call rate or high cost of failure Disables the tool and downgrades it to a read-only replacement tool.

8. Strengths and Limitations

Key takeaways: WebMCP increases browser agent friendliness, but it is still too early to call it a universal deployment standard.

Strengths are clear. Agents guess less about their screens because your site describes its features in a structured way. Since it operates within the browser origin and user session, it is more natural than leaving a separate API key to the user. The HTML form-based declaration method can be attached to existing sites at low cost.

The limit is also large. As of June 2026, WebMCP is not a final standard. Browser support is centered around origin trials and is tied first to specific agent experiences such as Gemini in Chrome. Additionally, tool call input is still untrusted input. Sites must validate values ​​sent by agents as if they were normal user input.

Therefore, the current recommendation is not “full adoption” but “create AI-ready action inventory and experiment with 1-2 read-only tools.” For financial, medical, and public services with many sensitive tasks, standard stabilization and audit log systems come first.

9. Points to study more deeply

Key takeaway: To properly understand WebMCP, you need to look at the browser security model and form design together, rather than the MCP itself.

• W3C Draft: API names, security considerations, and tool registration models may change, so please check the source material periodically.
• Chrome·Edge origin trial: You must check the actual deployable version, token registration method, and expiration date.
• Browser origin Security: We need to see how cookies, CSRF, and permission checks fit together when tools are run within the same user session.
• Designing accessible forms: Even without WebMCP, a clear form structure helps both people and agents.
• Audit log design: Agent calls must be stored separately from the user's direct clicks for cause analysis.

10. Action Checklist + Author's Perspective

Key takeaway: WebMCP is not about adding features, but about redrawing the execution boundaries of the product.

• Have the actions to be exposed to the agent classified as view, draft, change after confirmation, or prohibited?
• Is your first experiment tool read-only and low-cost of failure?
• Is the tool input schema divided into verifiable fields rather than one wide string?
• Do sensitive actions have user confirmation, cancellation, retry, and audit logs?
• Does the existing UI work in browsers that do not support WebMCP?
• Is the tool name, input summary, user confirmation, and result code left in the tool call log?
• Is there a flag to disable when origin trial expires and specifications change?

Definition of Done: If one read-only WebMCP tool is called normally in the origin trial environment and all failure, unsupported, and user rejection cases are confirmed through the existing UI fallback and audit log, the first verification is considered completed.

If I were you, I would not sell WebMCP as a “must-have SEO feature this year.” Instead, we will use this as an opportunity to organize the main actions of the site in preparation for the future introduction of browser agents. Commerce and SaaS in particular must now document action lists, permission boundaries, and user verification policies. Conversely, it is not recommended to immediately expose payment, deletion, or personal information changes before the standard is stabilized.

Reference material

• W3C Web Machine Learning Community Group: WebMCP Draft Community Group Report (Confirmed 2026-06-17)
• GitHub: webmachinelearning/webmcp specification repository (Confirmed 2026-06-24)
• InfoWorld: WebMCP API extends web apps to AI agents (confirmed 2026-06)
• Microsoft Edge Origin Trials: WebMCP (Confirmed 2026-06-24)
• NoHacks: What is WebMCP? (Updated 2026-06-09)