For the past 30 years, our industry has built websites and web applications for people. Buttons, forms, menus, and dashboards were designed for humans to click and navigate. The next generation of web applications will be built for people and AI agents at the same time.

‍

This is the idea behind the dual-use web: every application, every page has a human interface and an agent interface. Humans interact through the UI, while AI agents discover and invoke the application's capabilities directly.

‍

The benefits of a dual-use web

‍

A dual-use application doesn't duplicate functionality. It exposes the same business capabilities through two different experiences.

‍

Instead of teaching an AI agent how scrape your web page and to simulate clicking on buttons and other controls, you can also expose some of the lower-level client-side JavaScript methods that it can call, not just the back-end API.

‍

The result is simpler automation, more reliable AI interactions, better user understanding of what the agent is doing, and reusable business logic that you've already developed for your users.

‍

MCP vs. WebMCP

‍

Model Context Protocol (MCP) defines a standard way for AI agents to discover and use external tools and data sources. Traditionally, MCP servers run as separate services that expose capabilities to AI clients.

‍

WebMCP applies the same concept inside the browser. A web application can expose its own capabilities directly to an AI agent running in the user's browser session, without requiring a dedicated server-side MCP implementation for every feature.

‍

As of now, WebMCP is still an emerging browser capability rather than a broadly available web standard. It is mainly available for experimentation in Chromium-based browsers such as Chrome and Edge through origin trials or testing flags, while Firefox and Safari do not yet provide general support, so production applications should treat WebMCP as a progressive enhancement rather than a dependency.

‍

More details:  https://github.com/webmachinelearning/webmcp

‍

Why SPFx Is an Ideal Platform

‍

SharePoint Framework (SPFx) is uniquely positioned for WebMCP because it already runs in the user's authenticated SharePoint session.

‍

That includes web parts, application customizers, command sets, field customizers, and other SPFx extensions. They already have access to:

• The user's identity and permissions.

• SharePoint REST APIs and Microsoft Graph.

• Site context and page context.

• Existing client-side business logic.

• Possibly other APIs.

‍

Instead of rebuilding SharePoint functionality in a separate AI service, an SPFx solution can expose meaningful capabilities through WebMCP while continuing to provide the same UI for users.

‍

Build Once, Use Twice

‍

This is the real opportunity.

‍

An SPFx solution can serve two audiences:

• Humans interact through the SharePoint interface.

• AI agents invoke the same capabilities through WebMCP.

‍

The UI is designed for human understanding, so describing a task to agents uses a common understanding of possible operations, and users can be more confident that the agent is doing what they would do.

‍

Existing SharePoint customizations become reusable AI tools, making SPFx applications ready for the next generation of agent-powered Microsoft 365 experiences.

‍

‍See it for yourself

‍

On September 3, 2026, my colleague Elio Struyf is giving a quick demo of how you can support WebMCP in an SPFx project, at the biweekly Viva Connections and SharePoint Framework community call.  You can get the invitation to this call here:  

‍

https://aka.ms/spdev-spfx-call

‍

‍

If the date has already passed, you can see the recording here

https://aka.ms/m365pnp/videos

‍