# WebMCP vs MCP: the difference, and how they fit together

Source: https://busymate.ai/articles/webmcp-vs-mcp-difference
Last modified: 2026-09-07
Published: 2026-09-07 · Busymate AI team · 7 min read

> MCP connects an AI agent to the systems your business runs on. WebMCP turns your website's own actions into buttons an agent can press. Both, explained.

Two standards, three letters apart, doing genuinely different jobs. **MCP is how an AI agent reaches the systems your business runs on** — your booking calendar, your orders, your customer records — through a server you keep online. **WebMCP is how an AI agent uses your website** — the buttons and forms already on the page — while a visitor is looking at it. Same underlying idea: give the agent named, described actions instead of making it guess. Opposite ends of your business.

## In one sentence each

| MCP — the back office | WebMCP — the front counter |
|---|---|
| **In one sentence:** an assistant can reach the systems your business runs on, through a server you (or your software provider) put online. | **In one sentence:** the things your web page can already do become buttons an assistant can press, while the visitor is on the page. |
| **For example:** a customer asks "is Thursday at 3pm free?" and your booking system answers with the real slots. | **For example:** your booking form becomes a button the assistant fills in and submits, with the visitor watching it happen. |
| **Who sets it up:** whoever runs your systems. | **Who sets it up:** whoever runs your website. |

<svg viewBox="0 0 720 210" role="img" dir="ltr" aria-label="An assistant in the middle reaches your website page on the left through WebMCP, and your systems on the right through MCP" xmlns="http://www.w3.org/2000/svg">
  <g style="fill:none;stroke:currentColor;stroke-width:1.5">
    <rect x="12" y="66" width="196" height="78" rx="12"/>
    <rect x="278" y="56" width="164" height="98" rx="14"/>
    <rect x="512" y="66" width="196" height="78" rx="12"/>
    <path d="M278,105 L208,105" opacity="0.6"/>
    <path d="M442,105 L512,105" opacity="0.6"/>
    <path d="M216,99 L208,105 L216,111" opacity="0.6"/>
    <path d="M504,99 L512,105 L504,111" opacity="0.6"/>
  </g>
  <g style="fill:currentColor;font-family:ui-sans-serif,system-ui,sans-serif;font-size:13px;text-anchor:middle">
    <text x="110" y="100">Your website page</text>
    <text x="110" y="120" opacity="0.7">its own buttons and forms</text>
    <text x="360" y="92">The visitor</text>
    <text x="360" y="112">and their assistant</text>
    <text x="610" y="100">Your systems</text>
    <text x="610" y="120" opacity="0.7">booking, orders, customers</text>
    <text x="243" y="88" opacity="0.7">WebMCP</text>
    <text x="477" y="88" opacity="0.7">MCP</text>
  </g>
</svg>

WebMCP is the counter at the front of the shop; MCP is the phone line to the back office. One assistant works both.

## What is actually different

| | MCP | WebMCP |
|---|---|---|
| Where it runs | on a server — "available on any platform at any time" | in the browser tab — "available only on your website" |
| Who hosts it | you, or the vendor of your software | your website itself, with nothing extra to host |
| How the agent finds it | you register the server with the assistant once | the page registers its tools each time it loads |
| Who can use it | any assistant you connect it to | whichever agent the visitor happens to be using |
| Sign-in | its own authorisation, normally a token sent with each call | the visitor's existing session on your site |
| Lifetime | persistent — the server keeps running | tab-bound: the tools exist only while your page is open |
| It also offers | reference data and reusable prompt templates, not only actions | actions only |
| Status | an open standard, already supported across major assistants | a proposal in W3C incubation, in a Chrome origin trial |

The left column comes from the [Model Context Protocol docs](https://modelcontextprotocol.io/docs/learn/architecture), which define servers that expose *tools* (actions), *resources* (data) and *prompts* (templates), reached over a standard connection that carries normal HTTP authentication. The right column comes from [Chrome's own comparison](https://developer.chrome.com/docs/ai/webmcp/compare-mcp) and the [WebMCP explainer](https://github.com/webmachinelearning/webmcp), where a page calls `document.modelContext.registerTool()` to publish an action; Chrome ships it behind a flag with an origin trial from Chrome 149 ([Chrome for Developers](https://developer.chrome.com/docs/ai/webmcp)). ChatGPT already calls these Site tools in its desktop browser, and reviews each call before it runs ([ChatGPT docs](https://learn.chatgpt.com/docs/webmcp)).

## How they fit together

They are not rivals; they are the same shape at two distances.

- **One vocabulary.** Both describe an action identically: a name, a description written for a person, and a list of inputs. Learn it once and you can write either.

```text
Every tool — MCP or WebMCP — is only these three things:

  name          book_appointment
  description   Books a slot for a named service on a chosen date
  inputs        service, date, time, name, email
  runs at       https://[your-site]/book

If a new colleague could act on that description, an agent can too.
```

- **A page tool can front a server tool.** Your booking page already talks to your booking system. Publishing that page action as a WebMCP tool exposes the same capability without opening a second door.
- **One assistant consumes both.** The assistant on this site is an MCP server for the systems behind it, and its pages publish WebMCP tools for whatever agent is browsing them. Same catalogue, two exits. You can watch it happen in the [WebMCP inspector](https://busymate.ai/webmcp/inspect), test a page with the [WebMCP checker](https://busymate.ai/tools/webmcp-check), or point the [MCP checker](https://busymate.ai/tools/mcp-check) at a server before attaching it.

## Which one do you need

- **Neither, yet** — if your questions are answered by facts already published on your pages. Start with content; the [site knowledge service](https://busymate.ai/solutions/site-knowledge) covers that ground.
- **WebMCP** — if the useful next step is something a visitor does *on the page*: book, check, submit, start a return. This is the cheaper half, and the [page tools guide](https://busymate.ai/docs/guides/page-tools) is the setup. Background on the standard is on our [WebMCP overview](https://busymate.ai/webmcp), and the wider readiness picture is in the [agent-ready checklist](https://busymate.ai/articles/is-your-website-agent-ready-checklist).
- **MCP** — if the answer lives in a system rather than on a page: order status, real availability, account changes. [MCP for business owners](https://busymate.ai/articles/mcp-for-business-owners) is the non-technical version, and the [connect an MCP server guide](https://busymate.ai/docs/guides/connect-mcp-server) is the how.
- **Both** — if customers arrive with questions your pages answer *and* actions your systems own. That is most shops with a booking or an order behind them.

## Ask your assistant to do it

```text
Ask your AI assistant:
1. Read https://[your-site] and list the three actions a visitor most often
   takes on it. For each, write a tool name, a one-line description and the
   inputs it needs, then add it as a page tool and show me the result.
2. Then connect my MCP server at https://[your-site]/mcp, list every tool it
   exposes with its access level, and wait for my yes before saving anything.
Mark anything you had to guess with [CHECK].
```

Read the draft, fix the `[CHECK]` marks, and you have both halves scoped without writing an integration. Your mate shows the exact change and waits for your approval before anything is saved.

Neither standard makes you easier to *find* — that is still clear pages and a curated brief such as our own [/llms.txt](https://busymate.ai/llms.txt). What they change is what happens after an assistant arrives. The fastest way to see the difference is on your own pages: [build an assistant from your URL](https://busymate.ai/try) and ask it something only an action can answer. [Pricing](https://busymate.ai/pricing) is metered per business, so neither half is a tier you have to buy your way into.

## Questions

### Is WebMCP just MCP for websites?

Close enough to be useful, and different in one way that matters. Both describe an action the same way — a name, a plain-English description and a list of inputs — but an MCP server runs on a machine you keep online, while WebMCP tools live in the page and exist only while a visitor has it open.

### Do I need both?

Most small businesses need neither on day one and WebMCP first when they do. Page tools make the actions a visitor can already take usable by an assistant. An MCP server earns its place when the useful answer lives in a system rather than on a page.

### Can an agent use my WebMCP tools without visiting my site?

No, and that is by design. Chrome's documentation is explicit that clients and browsers must visit a site directly to know if it has callable tools, so page tools only exist inside a real visit to a real page.

### Will an agent buy or cancel something without asking?

Not if the action is built properly. WebMCP is designed for workflows with a human in the loop, ChatGPT reviews each tool call before it runs, and anything that charges, cancels or refunds should require the visitor to confirm it first.

### Which one do search engines and AI assistants prefer?

Neither is a ranking factor. They change what an assistant can do once it arrives, not whether it arrives. Being findable is a separate job, handled by clear pages, a sitemap and a curated brief such as an llms.txt file.