Back to blog

WebMCP for Software Products: Preparing Websites for AI Agents

AIAPI DesignSoftware ArchitectureGovernance

AI agents often operate web applications as humans do today: they read pages, interpret forms, and simulate clicks. This works for simple flows, but becomes unreliable across dynamic interfaces, multi-step processes, and sensitive actions. WebMCP is intended to let websites expose structured tools that browser agents can understand and execute directly.

What WebMCP Changes for Web Applications

WebMCP is a proposed web standard, not a finished replacement for APIs. A page registers actions with a name, description, and JSON Schema inside the browser. An agent can discover these tools and invoke them in the visible page context instead of navigating DOM structures and changing buttons.

The approach complements conventional backend integrations:

  • Shared context: User, agent, and application work with the same authenticated session and visible state.
  • Explicit actions: A tool such as filter_orders or prepare_refund describes a business purpose rather than only a UI element.
  • Less fragile automation: Structured inputs replace some screenshot interpretation and simulated clicking.
  • Progressive enhancement: The human interface remains in place and gains an additional interaction layer for agents.

WebMCP is still at an early stage. The draft is being developed in the W3C Web Machine Learning Community Group and tested experimentally in Chrome. Teams should learn and prototype, but should not yet make a critical product strategy depend on stable browser support.

Where Teams Should Start With WebMCP

A good pilot is a frequent, clearly bounded flow with a visible outcome, such as collecting support details, applying search filters, or preparing a draft. Financial transactions, permission changes, and irreversible actions are poor starting points.

A simple tool can reuse existing frontend logic:

await document.modelContext.registerTool({
  name: "prepare_refund",
  description: "Prepare a refund for review without submitting it",
  inputSchema: {
    type: "object",
    properties: { orderId: { type: "string" } }, required: ["orderId"]
  },
  execute: ({ orderId }) => openRefundDraft(orderId)
})

The tool description is not a security boundary. The backend must still enforce authorisation, tenant isolation, input validation, idempotency, and audit logging.

Before a pilot, teams should clarify several points:

  • Tool scope: Small actions with an unambiguous business purpose are easier to review than a generic execute_task.
  • Approvals: Drafting, previewing, and final execution need separate permissions and visible confirmation.
  • Error behaviour: The agent needs structured, actionable errors rather than messages written only for humans.
  • Measurement: Completion rates, drop-offs, incorrect tool calls, and manual corrections show whether the flow actually becomes more reliable.
  • Fallback: The web application must remain fully usable without WebMCP while browser support and the specification are not stable.

Why This Matters

WebMCP turns the agent-readiness of a website into a deliberate product and architecture decision. Structured actions can reduce support effort and interaction errors. Exposing existing frontend functions as tools without review creates new paths into sensitive business processes.

For technical decision-makers, the economic value is therefore not in the new protocol itself. It appears when users complete a clear process with fewer steps, fewer failures, and traceable approvals. An Architecture & AI Review can identify suitable WebMCP pilots and the backend boundaries that need strengthening first.