The Publishing project

The introduction of the Web Model Context Protocol (WebMCP) and its deplyment in Chromium browsers reignites a longstanding debate over browser capabilities. At the heart of this discussion is a fundamental tension between empowering developers with rich web technologies and protecting users through restricted, highly secure browser sandboxes.

This post presents my analysis and opinion on the WebMCP conversation and ancillary information that may help developers and researchers understand its implications.

The Capability vs. Security Divide

While Google argues these APIs are necessary for the web to compete with native mobile apps, both Apple and Mozilla maintain that the web’s primary trust model, that a user can safely visit any URL without permanently compromising their machine, must not be broken.

However, there is a critical distinction between Apple and Mozilla’s historical positions. Mozilla does not control a dominant mobile operating system; its rejection of hardware APIs was purely security-driven. Apple, on the other hand, provides native equivalents for all of these “risky” APIs within iOS and iPadOS. The same fingerprinting and tracking potential exists on native apps if traffic is monitored, yet Apple permits them there. Because Apple tightly controls native app distribution and monetization, restricting these capabilities on the open web inevitably incentivizes developers to build native iOS applications instead.

This dynamic forces severe market fragmentation and a massive engineering tax. Consider a common web workflow: booking a flight. To deliver a feature-rich flight reservation experience, organizations are often pushed to maintain at least three separate codebases: a native Android app (where hardware and background features are supported), a native iOS app (to access the capabilities Apple denies to the web), and a web app (which requires complex fallbacks for non-supporting browsers like Safari). Paired with uneven support for Progressive Web App (PWA) features across different platforms, this funnels development toward proprietary storefronts, reinforcing ecosystem control and centralized application distribution models.

Now, WebMCP is stepping into this exact same crossfire. While Apple’s WebKit team has forcefully scrutinized WebMCP’s proposal to let developer-authored, client-side AI agents interface directly with web pages, Mozilla has notably refrained from declaring a formal position, leaving its standards position issue open and uncommitted. This hesitancy—whether reflecting cautious neutrality or ongoing internal debate—highlights the industry’s familiar dilemma: if WebMCP is universally adopted, booking that flight via an in-browser AI assistant becomes a seamless, standardized interaction across the open web. But if it is restricted or left in standards limbo, developers will once again be incentivized to build AI-agent capabilities exclusively into native applications, repeating the cycle of market fragmentation and walled-garden control.

Defining WebMCP

WebMCP introduces a standardized way for web pages to expose client-side tools directly to browser-based AI agents. To understand its role, it is essential to contrast WebMCP with the foundational Model Context Protocol (MCP).

Standard MCP is designed for server-side or local environment integrations—allowing AI models to interface with external databases, APIs, and backend microservices via transport mechanisms like stdio or HTTP/SSE. WebMCP, by contrast, brings this concept into the browser engine itself. It allows web applications running in the user’s browser to expose dynamic JavaScript functions and page state directly to client-side AI agents without requiring external backend round-trips.

The Architectural Critique

Critics of WebMCP, including representatives from WebKit, argue that the protocol fundamentally shifts the web’s interaction model. They posit that an agent acting on a user’s behalf is, in effect, assistive technology; it should operate a site as the user would, using existing accessibility trees (AT) rather than a specialized API. They argue that making “an agent is driving” an observable fact invites parity gaps where sites might withhold features from humans or provide “super-user” capabilities exclusively to agents.

The Case for Shared Semantics

Jason Grigsby, a noted proponent of inclusive web design, aligns with this perspective. He argues that when a site’s actions are hard for an AI agent to use, that is a gap in the site’s own semantics. His position is that we should first close those gaps in the platform’s shared layers (HTML and ARIA), where the user, assistive technology, and agents all benefit.

While Grigsby’s commitment to universal web standards is commendable, this position may rest on a category error. Human users navigate through subjective volition—evaluating visual layout cues, interactive date-picker widgets, and seating charts to book a flight. Agents follow programmatic instructions, operating via structured parameters (origin: SFO, destination: JFK, date: 2026-10-15, seatPreference: { position: "window", arrangement: "together" }). By attempting to force agents into the “assistive technology” box, we risk ignoring that agents are not merely helping a human see the page, they are acting as a new type of programmable interface. A bridge for a human is not the same as a bridge for a machine.

WebMCP does not attempt to standardize the web’s business logic. Instead, it provides a structured protocol wrapper for bespoke application features, custom code engineered by site developers to solve specific user tasks, like searching flight availability or processing a seat selection. From a web architecture perspective, WebMCP operates on the proven principle of progressive enhancement. If a visiting user agent lacks an AI assistant, the page remains fully functional through standard HTML forms and UI controls without penalty. If the browser makes WebMCP available to an active agent, the interaction is enhanced. Ultimately, this places responsibility back into developers’ hands: it is up to engineers to ensure that the agentic workflows they expose perform just as reliably, if not better, than the traditional UX.

Technical Implementation and Implementation Signals

WebMCP relies strictly on TypeScript/JavaScript and JSON Schema, providing a rigid, programmatic contract between the webpage and visiting AI agents.

Registering Custom Tools with WebMCP

Developers declare capabilities by registering tools with navigator.modelContext. Here is how an airline application exposes a flight search capability directly to a visiting AI agent, explicitly handling seating arrangements for multi-passenger bookings to prevent ambiguity:

// Registering a custom application tool with WebMCP
if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: "search_flights",
    description: "Searches available flights based on origin, destination, travel dates, passenger count, and explicit seating arrangements.",
    inputSchema: {
      type: "object",
      properties: {
        origin: {
          type: "string",
          description: "3-letter IATA airport code (e.g., SFO)"
        },
        destination: {
          type: "string",
          description: "3-letter IATA airport code (e.g., JFK)"
        },
        departureDate: {
          type: "string",
          format: "date",
          description: "Departure date in YYYY-MM-DD format"
        },
        passengers: {
          type: "integer",
          minimum: 1,
          default: 1
        },
        seatPreference: {
          type: "object",
          properties: {
            position: {
              type: "string",
              enum: [
                "window",
                "aisle",
                "middle",
                "no_preference"],
              default: "no_preference",
              description: "Primary seat location preference (e.g., window)"
            },
            arrangement: {
              type: "string",
              enum: [
                "together",
                "direct_across",
                "no_preference"
              ],
              default: "together",
              description: "Proximity requirement when booking for multiple passengers"
            }
          }
        }
      },
      required: [
        "origin",
        "destination",
        "departureDate"]
    },
    // The handler connects the agent's structured call directly to app state/APIs
    handler: async (params) => {
      const response = await fetch('/api/flights/search', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(params)
      });
      return await response.json();
    }
  });
}

Once registered, an active agent discovers these available tools and executes them deterministically without parsing the DOM:

// How a client-side agent discovers and executes registered webpage tools
const registeredTools = await navigator.modelContext.getTools();
const flightTool = registeredTools.find(tool => tool.name === "search_flights");

if (flightTool) {
  const flightResults = await navigator.modelContext.executeTool("search_flights", {
    origin: "SFO",
    destination: "JFK",
    departureDate: "2026-10-15",
    passengers: 2,
    seatPreference: {
      position: "window",
      arrangement: "together"
    }
  });
  console.log("Flight search completed via WebMCP:", flightResults);
  // Do something with the results, like present them on screen
  // for user's final approval
}

The Multi-Agent Reality and Model Variance

A critical caveat for web developers is that WebMCP standardizes the API contract, not the reasoning engine behind it. The resulting landscape mirrors the heavy cross-browser compatibility tax long familiar to web developers, much like the early days of HTML5 media where developers were forced to encode, test, and maintain multiple file formats (.mp4, .webm, .ogv) inside a <video> tag just to achieve basic playback parity across different browser engines.

WebMCP serves as the unified container, but developers face a similar maintenance burden across fragmented model engines. In an ecosystem where Safari leverages Apple Intelligence, Chromium embeds Gemini, and browsers like Opera or Firefox allow custom or sideloaded models, WebMCP acts strictly as the discovery layer. Even with strict JSON Schemas, different LLMs will interpret natural language tool descriptions differently. One model may eagerly invoke a tool based on implicit user context, while a smaller on-device model might fail to populate nested parameters or require more explicit prompting.

A strict schema guarantees that if an agent calls a function, the payload matches the expected data shape. However, ensuring functional parity across a multi-model ecosystem requires developers to continuously test, prompt-engineer, and refine their tool definitions for multiple browser AI targets—or decide explicitly which browser agents they refuse to support.

This limitation lies not within WebMCP, but in the non-deterministic nature of AI itself. Where deterministic precision is required, an LLM is simply the wrong tool for the job.

The Blink-Dev Perspective

Discussions in the Chromium blink-dev community reinforce the necessity of these structured contracts. The consensus highlights that screen-scraping—where an agent attempts to visually guess which calendar input or dropdown handles flight dates—is brittle, slow, and insecure. By providing a canonical declaration of capabilities, WebMCP allows developers to avoid the pitfalls of visual-based automation.

However, the blink-dev perspective presents a false dichotomy between visual DOM guessing and adopting WebMCP. In reality, existing Chromium built-in AI APIs (such as window.ai) already handle structured JSON tool-calling without specialized browser protocols.

Furthermore, this capability extends well beyond native browser APIs. Developers are already building AI-enabled browser extensions and decoupled web applications powered by third-party LLMs—whether making external API calls or running local quantized models directly in the browser via WebGPU and tools like Transformers.js. While these third-party implementations may face stricter resource limits or latency overhead compared to native browser APIs, they successfully execute complex agentic tool calls today using standard web architecture.

Because modern web applications separate visual rendering from underlying state, any active native or third-party agent can hook structured tool outputs directly into standard JavaScript functions, Custom Events, or module endpoints. WebMCP does not invent client-side function calling; it merely standardizes how those functions are discovered across isolated extensions and agent runtimes.

Conclusion

WebMCP sits at a defining crossroads for the web. While critics are right to be wary of the architectural implications of making “an agent is driving” an observable fact, the alternative, forcing AI-driven interactions into the same limited paradigms as human users, fails to account for the unique, programmatic nature of AI agents. If we do not provide a standardized, secure way for agents to interact with web pages, we risk repeating the mistakes of the mobile era. We will see AI capabilities siloed into native applications, widening the gap between the “app-first” mobile ecosystem and the open web. WebMCP offers a path toward a more capable, standardized, and interoperable web, provided the industry can move past the security-versus-capability impasse and agree on the fundamental way AI should live alongside the user in the browser.

Bibliography

Chrome for Developers. Compare WebMCP and MCP Accessed July 5, 2026.

Grigsby, Jason. Improvements to Web for AI Should Benefit All Users. Cloud Four. Accessed July 5, 2026.

Mozilla Standards Positions. WebMCP GitHub. Accessed July 29, 2026.

Web Machine Learning Working Group. Web Model Context Protocol (WebMCP). GitHub Pages. Accessed July 5, 2026.

WebKit Standards Positions. WebMCP GitHub. Accessed July 5, 2026.

Chromium Project. “Blink-dev Discussion: AI and the Web.” Google Groups. Accessed July 5, 2026. https://groups.google.com/a/chromium.org/g/blink-dev/c/iR6R7-nQeHI?pli=1.