WebMCP is about browser actions, not another backend integration
WebMCP is a proposed web standard for describing actions on a page as structured tools that an AI agent can call in the browser. Instead of guessing its way through buttons, labels and changing layouts, an agent can receive a defined action, its expected inputs and a controlled result. That makes it relevant for customer portals with complex forms, guided support requests or account workflows.
It is important not to confuse this with a server-side Model Context Protocol integration. A backend MCP server gives an agent access to systems and data through a controlled service. WebMCP lives in the user’s browser tab and is intended for user-present interaction with the web application itself. The two can complement each other, but they need different permission, testing and support models.
Start with a human-visible, low-risk portal task
The first WebMCP candidate should be a workflow that is valuable when filled correctly, easy for a person to review and harmless to abandon. A support request, a product search, a service booking draft or a pre-filled application is usually a better pilot than changing billing details, accepting legal terms or completing a payment.
The right question is not whether an agent can click through the existing UI. It is whether the portal can express one real user intention in a compact, understandable contract. If the team cannot describe the inputs, validation rules, result and owner of a workflow, the workflow is not ready to expose as a tool.
- Choose one user journey with clear inputs, validation and an observable outcome.
- Keep the normal portal UI fully usable without an agent.
- Make the agent-filled state visible so the user can inspect it.
- Require a person to review sensitive or consequential submissions.
- Offer cancellation, correction and a clear support route before final submission.
Use forms and schemas to remove ambiguity, not user control
WebMCP’s declarative direction builds on ordinary HTML forms: the page can provide a tool name, a description and input-level meaning so a browser can derive a structured schema. This is useful because a field labelled for a human may not tell an agent whether it expects a contract number, a preferred date or a free-text explanation.
A schema improves the shape of the request, not the safety of the action by itself. Teams should validate every value on the server, use the same authorization checks as the human UI and show the pending data in the portal before a submission matters. For a sensitive action, confirmation belongs in the product flow rather than being assumed from a tool call.
Treat permissions, data and tool output as security boundaries
A browser agent works in a logged-in user context, so an exposed action must never become a shortcut around ordinary product controls. Keep each tool narrowly scoped, derive access from the active user session and prevent agents from setting fields that the human interface would not allow. For embedded portal modules, review iframe permissions deliberately instead of enabling cross-origin access by default.
Tool descriptions, page content and returned data can influence an AI system. That means untrusted text should not be treated as instructions, and a tool should return only the data needed to complete the current task. Audit logs should record the tool name, requester, user-visible confirmation, result and failure state without creating a new store of unnecessary sensitive prompts.
- Use the same server-side authorization and validation as the normal portal route.
- Expose the smallest useful action instead of a general-purpose admin operation.
- Separate read-only discovery from state-changing actions.
- Limit returned data to the current task and avoid secrets in tool output.
- Log intent, confirmation and outcome so support can reconstruct a failed flow.
Plan WebMCP as progressive enhancement
WebMCP is still under active standardisation and browser experimentation. Chrome documents an origin trial and local testing path, while other browser-engine discussions raise concerns about portability, semantics, privacy and security. A portal should therefore remain complete and accessible without WebMCP, with feature detection and a clean no-agent fallback.
A practical rollout starts in a test environment with one read-only or draft-producing journey. Test the normal user journey first, then tool registration, invalid inputs, cancellation, session expiry, permission boundaries and the confirmation state. Measure completion quality and support burden before expanding scope. If browser support or the proposal changes, the portal remains useful because the underlying form and server workflow were the product investment.
A decision checklist for product teams
For EDS Labs projects, WebMCP is currently a discovery and pilot topic rather than a default platform requirement. It can be worthwhile when a customer portal has repeatable, user-present tasks that agents struggle to complete reliably through the visual interface alone. It is not a reason to duplicate a product’s whole API or weaken an existing approval model.
The strongest outcome is modest and reviewable: a well-structured portal flow that works for people, assistive technology and conventional automation, with an optional agent-facing layer only where it removes real ambiguity. That leaves the product ready to learn from the emerging browser ecosystem without betting the core journey on an unfinished standard.