The idea
WebMCP and MCP
You know MCP, or you have heard of it, and you want to know whether WebMCP is the same thing. It is the same idea in a different place, and the place changes almost everything that matters.
Same idea, different place
The Model Context Protocol (MCP) connects an agent’s host to servers. A server offers tools — each with a name, a description and an input schema — and the host calls them on the agent’s behalf. The server is a program you run: a local process the host starts, or a remote service it connects to.
WebMCP offers the same shape of thing — named tools with descriptions, schemas and behavioural hints — from a web page. There is no server to run. The page registers its tools when it loads, and an agent whose host is running the page in a browser can call them.
Side by side
| MCP | WebMCP | |
|---|---|---|
| Where the tool’s code runs | In your server process | In your page, in the person’s browser |
| Whose identity a call carries | Whatever credentials the server is configured with | The person’s own signed-in session on your site |
| How tools are found | The host is configured to connect to your server | The host lists what the open page has registered |
| How long tools exist | As long as the server runs | As long as the page is open |
| What you deploy | A server, and its authorisation | A script on pages you already serve |
| Who decides what may run | The host’s configuration and approvals | The person, per site, when an agent first asks |
Two rows do most of the work. Because a WebMCP tool runs in the page, it acts as the person who is signed in, through the same code path as the button they would have clicked — your existing permission checks apply and nothing new needs securing. And because it lives only while the page is open, the person can see your application while the agent works in it.
When MCP is the better choice
- The operation has no page to run in: a batch job, a back-office system with no user interface, a data pipeline.
- The tool must work when nobody has your application open.
- You are integrating with agent hosts that do not run a browser.
- The operation needs a service identity rather than a person’s.
When WebMCP is the better choice
- The operation already exists in your user interface.
- It must happen as the signed-in person, with exactly their permissions.
- You want the person to watch your application while an agent works in it.
- You would rather not run, authorise and secure another service.
They compose
Offering one does not rule out the other. A product can run an MCP server for unattended back-office work and declare WebMCP tools on its pages for the work a person does with an agent beside them. The tool design advice in this section — one tool per job, descriptions that state outcomes and boundaries, honest hints — applies to both.
The rest of this section is about the WebMCP half: what it looks like when many applications plug into one host, and how to build your first tool.