WebMCP vs MCP: when to use the browser-level interface and when to keep actions on the server

# What these two protocols do

MCP and WebMCP solve different problems. MCP (Model Context Protocol) is a backend-facing contract. It gives an agent persistent access to data, files, repositories, databases and internal APIs. WebMCP is a frontend-facing contract. It lets a web page expose named tools and describe their inputs so an agent can operate inside the live browser session.

# How they differ in practice

MCP fits tasks that must run on servers or against persistent stores. Examples include searching article sources, editing drafts, running tests, preparing commits and deployments. These are actions that do not depend on a single open tab and usually work with APIs or storage outside the browser.

# A practical decision rule

Decide by asking: where must the action occur? If it must touch servers, databases, files or other systems outside the open page, start with MCP. If it must happen inside the visible UI and the user and agent are working on the same page state, consider WebMCP. For tasks that require both, combine them while keeping each layer focused on its own responsibilities.

# Why the distinction matters for sites like Drupal

# What WebMCP provides to the live page

WebMCP offers two API styles. The imperative API lets page JavaScript register functions as tools. The declarative API lets HTML forms carry a tool name, a description and field descriptions. The declarative form API is especially useful for ordinary websites because it lets the form itself state required fields and interaction expectations (for example that the user should see what has been filled in before submission).

# Current readiness (August 2026)

WebMCP is an emerging proposal and not a universal production requirement. It is worth understanding now because it reduces the fragility of agents that otherwise must infer UI structure. But it is not a blanket replacement for MCP. Implement WebMCP where UI-level cooperation is needed and MCP where backend persistence and broader workflows are required.

# Short checklist for implementers

• If action touches persistent data, files or internal APIs → MCP.
• If action must use the page's live session state or update the UI directly → WebMCP.
• If both are needed → use both and keep responsibilities separate.
• For forms, consider the declarative WebMCP form API with JSON Schema for clear field semantics.

# Final point