AI Drupal Development Security UX

WebMCP and MCP: what is the difference and when should a website use each?

šŸŽ§ Listen to every article back to back

WebMCP is an emerging proposal for cooperation between a web page and a browser agent. It is not a new name for MCP and it is not a replacement. A practical rule is simple: MCP belongs near servers and data; WebMCP belongs near the live page and the workflow the user can see.

At the end of August 2026, WebMCP is not something every production website should rush into every form. But it is worth understanding now, because the direction is right: an AI agent should not have to guess buttons and click through a website like a brittle automation script. A web application can declare which actions an agent may use and what structured inputs those actions expect.

That distinction matters.

A normal browser agent sees a page roughly as a user or automation tool sees it: headings, form fields, buttons, the DOM, the accessibility tree and sometimes a screenshot. If it needs to fill in a contact or booking form, it has to infer what each field means. When the design changes, the workflow may break.

WebMCP tries to reduce that uncertainty. A page can register a tool such as submit_contact_request, filter_products or start_audit, and describe its inputs with JSON Schema. The agent no longer has to ask "where is the button?". It can ask "which tool is available for this action?".

That does not mean everything should move to WebMCP. Chrome for Developers' comparison of WebMCP and MCP says the same thing quite directly: WebMCP and MCP solve different layers. MCP is backend. WebMCP is frontend.

MCP: A Persistent Tool Layer for Servers and Data

MCP, or Model Context Protocol, fits when an agent needs to work with things that do not live only in an open browser tab:

  • files and repositories;
  • databases;
  • CRMs, document stores and internal APIs;
  • longer analysis or publishing workflows;
  • tools the agent must use even when a specific web page is not open.

WebPro's own blog workflow is a good example. Through MCP, an agent can search articles, open them, edit a draft, validate content, show a diff and prepare publishing. That does not depend on the user currently viewing the public blog page. The tool works with source files and the release process.

WebMCP would not be the right main layer for that work. The blog source file, build, tests, commit, backup and deployment are not actions inside a browser form. They are parts of the release process.

WebMCP: An Agent Interface for the Open Page

The WebMCP GitHub project describes WebMCP as a way for a web page to expose JavaScript functions or HTML forms as tools for agents. It is a browser-and-page layer, not a separate server protocol.

In practice, that means two kinds of API:

  • an imperative API where page JavaScript registers a tool;
  • a declarative form API where an HTML form gets a tool name, a description and field descriptions.

The declarative side is especially interesting for ordinary websites. If a contact form has fields for name, email, website and message, the form itself could say: "this is the request submission tool; these fields are required; before submission, the user must see what has been filled in."

This fits places where a person and an agent work on the same page at the same time:

  • contact forms;
  • support request forms;
  • e-commerce product search or cart flows;
  • booking flows;
  • calculators;
  • website audit tools;
  • complex editorial interfaces.

WebMCP's strength is context. The agent sees the same session, the same page state and the same work in progress as the user. When a tool runs, the page can use its normal logic to update the UI, show the result and ask for human confirmation when needed.

The Useful Difference: Where Does the Action Live?

A simple decision rule:

  • if the action must happen on a server, in a database, in files or in another system, start with MCP;
  • if the action must happen inside the UI of an open web page, consider WebMCP;
  • if you need both, use both, but keep the responsibilities separate.

For example, on a Drupal site an MCP tool might request the content model, read articles through JSON:API, compare translations or create a proposed content change. WebMCP could meanwhile help a user inside the Drupal admin interface or a public tool by filling a specific form, using a filter or updating a preview.

The two are not competitors. They are two different contracts for the agent.

MCP says: "here is a persistent service through which you can use data and actions."

WebMCP says: "this specific page, currently open in the browser, offers these tools."

What This Means for Drupal

For Drupal, the first question is not "should we add WebMCP?". The first question is: which action is the agent allowed to perform at all?

If a Drupal site is a service portal, school website, municipality site or e-commerce store, at least three surfaces should be separated.

The public page. An agent may help the user find a service, fill in a request form or start a public audit. WebMCP may fit here because the action happens on the visible page.

The editorial workspace. An agent may help fill a form, summarize content or check fields. WebMCP is interesting here, but permissions and confirmations must be very clear. Drupal already has roles, permissions, workflows and revisions for this.

The technical release workflow. An agent may analyze code, compare configuration, check tests or prepare changes. That belongs more to MCP, CLI and the development environment than to WebMCP.

Good architecture does not try to solve everything with one protocol. A public form, an editorial workflow and deployment do not need the same tool layer.

The WebPro Site Example

WebPro currently has two different things that should not be confused.

First, there is an MCP-based article workflow. It fits content files and publishing because the process needs to check source files, translations, build output, tests and deployment. That is the right place for a persistent agent tool.

Second, the public site has forms and a Drupal audit tool. These are exactly the kind of places where WebMCP fits a first low-risk experiment. The WebPro contact form and audit forms already receive declarative tool descriptions: the contact form still requires human review before submission, while the public audit pre-check can be launched automatically and return the result to the page.

That does not mean the agent should be able to make unlimited requests or submit forms automatically. For a contact form, audit tool or checkout, the same principle should remain: the tool may help, but sensitive or final actions need human confirmation.

Status in August 2026

WebMCP is still an emerging standards proposal. The WebMCP implementation status shows support in ChatGPT Desktop, a Chrome 149 Origin Trial, an Edge 150 Origin Trial and experimental Brave Leo support as of late August 2026. For Firefox and Safari, the visible status is standards-position discussion, not broad finished support.

That is enough for prototyping. It is not enough to build an entire critical web workflow only on WebMCP.

So the practical approach should be restrained:

  • do not break existing semantic HTML;
  • do not assume every browser or agent supports WebMCP;
  • do not give the agent more rights than the user has;
  • validate WebMCP inputs the same way you validate normal form or API inputs;
  • keep an audit trail;
  • make human confirmation visible for sensitive actions.

If WebMCP is absent, the page must still work. If WebMCP is available, the agent can use a clearer, faster and less fragile path.

The Security Risk Does Not Disappear

WebMCP can reduce UI interpretation errors, but it does not make an agent automatically safe.

Every argument an agent passes to a tool is still input. It must be validated. If the tool calls the backend, the backend must check permissions again. If an action may submit a form, change an order, make a purchase or publish content, the confirmation must be understandable.

At the browser level, this discussion involves same-origin rules, permissions policy limits and which parties can discover the tools. These are necessary mechanisms, but they do not replace business rules.

On a Drupal site, this is especially clear: a WebMCP tool must not bypass Drupal permissions, CSRF protection, content workflow or logging. If the tool calls a Drupal API, that API must be built as carefully as any other public or authenticated endpoint.

Where to Start

If you run Drupal or another complex web application, do not start by adding WebMCP attributes. Start by choosing the workflow.

A good first candidate is an action that is:

  • visible to the user;
  • repeated often;
  • connected to a form or filter;
  • low risk;
  • easy to validate;
  • completed with human confirmation.

Examples include contact form prefill, audit URL checks, support request drafting or product search filtering.

On the MCP side, start where the agent needs persistent background access: content analysis, translation comparison, audit report preparation, backlog creation, or checking files and configuration.

If both layers need to work together, the boundary should be clear. WebMCP controls the action on the open page. MCP brings the required context from servers or organisational systems.

Summary

WebMCP is not a new version of MCP. MCP is a persistent tool layer for backend systems, data and services. WebMCP is a tool layer for the open browser page, helping agents use the same UI the person is currently seeing.

For a Drupal site owner, the practical question is simple: which actions should agents see, and in which layer? A public form or tool may fit WebMCP. The content model, configuration, files and release process usually fit MCP.

WebPro can help evaluate that boundary through AI and Drupal workflows, automated testing and technical audit. Permissions, control and responsibility need to come first. Only then does it make sense to choose whether a tool belongs in the browser, on the server or in both.

Subscribe via RSS
Kaido Toomingas, WebPro technical leadWebPro Company OƜ Technical lead: Kaido Toomingas

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us