MCP 與 WebMCP 有何不同？面向 AI 智能體與網頁的協議解析

As the web shifts from human navigation to agentic workflows, a major architectural question faces developers: How do AI agents talk to systems and web pages?

If you’ve been keeping up with AI engineering, you have likely encountered terms like MCP (Model Context Protocol) and WebMCP (Web Model Context Protocol). While they share a similar name and vocabulary, they operate at completely different layers of the software stack.

Understanding the functionality and uses of each of these standards can be essential for building modern web applications that are ready for AI-driven assistants and autonomous shoppers.

1. What is MCP (Model Context Protocol)?

MCP is an open standard used for connecting large language models (LLMs) to external resources such as data sources and applications. By themselves, AI applications are only limited to their own training data, but MCP allows them to read files, access information in databases, and call into applications to utilize their functions, allowing AI models to perform automated tasks or assist with developing code.

• The Architecture: MCP uses a client-server architecture. An AI client communicates with local or remote MCP servers via standard transport layers (like JSON-RPC over stdio or Streamable HTTP).

• Core Primitives: MCP servers expose three main capabilities to an AI model:

  • Tools: Callable functions the model can execute (e.g., query a database, call an external API, write a log).
  • Resources: Read-only context the model can pull in (e.g., documentation, database snapshots).
  • Prompts: Reusable templates and workflows.

• The Lifecycle: Persistent and long-running. An MCP server works continuously in the background, regardless of whether or not it's being used.

2. What is WebMCP (Web Model Context Protocol)?

WebMCP is a proposed browser standard (currently in early preview) that lets your website declare, in a machine-readable way, what actions an AI agent can take on the page. Agents can't reliably tell what a human-designed interface is meant to do, so instead a site can expose its own set of specialized tools that the agent can call, with the browser mediating between the page and the agent.

WebMCP utilizes two APIs to register tools: the declarative API, where tools are defined within the site's HTML, and the imperative API, which can provide tools in JavaScript for more complex and dynamic interactions.

• The Architecture: Client-side and browser-mediated. Instead of setting up a separate backend server process, web applications register tools directly within the page context using JavaScript APIs (document.modelContext.registerTool()).

• The Lifecycle: Tools are bound to the active tab and last only while it's open. When the user closes or navigates away from the tab, the tools disappear.

  3. Side-by-Side Comparison: MCP vs. WebMCP

  The distinction that matters most for store owners is where the code runs: MCP lives on your backend server, WebMCP lives in the user's open browser tab.

Chrome frames the difference with a call-center analogy:

• MCP is the call center; available anywhere, anytime.

• WebMCP is the in-store expert; only providing help to the customer while within the shop.

  4. How They Work Together: The Complementary Stack

  MCP and WebMCP aren't opposites—they're options with different jobs. MCP works in the background to manage your site's data and systems regardless of whether anyone is interacting with the page: inventory, payment processing, order history. WebMCP, by contrast, handles the live user interface: the cart, the form, and the product options the user has selected. A complete agentic experience uses both.

• MCP gives an agent your services and data. It handles persistent business logic, CRM queries, and background operations.

• WebMCP gives an agent your user's open tab. It handles real-time UI states, active shopping carts, and in-page form workflows.

A Real-World E-Commerce Example

A user tells their browser agent, "Reorder my usual coffee beans." The agent opens your store. WebMCP lets it call a tool (reorder_last_purchase) directly on the page—no guessing which button to click, and the tool can read the current cart state and fill the quantity. That tool then calls your backend MCP server, which checks warehouse inventory, applies the user's loyalty discount, and authorizes payment. The result flows back to the page, and the cart is updated.

WebMCP handles the page, while MCP handles the data and logic behind it.

Connecting Back to GEO

The same pattern applies to structured data. JSON-LD separates what a product is (price, brand, availability) from how the page looks. WebMCP does the same thing for actions—it separates what a page can do from how the UI is designed. Chrome's documentation notes that WebMCP tools connect to application logic, not design, so you can redesign your storefront without breaking an agent's tools. Both layers are declarative, invisible to human visitors, and fail silently if omitted.

Your AI-readiness stack now has two layers working in parallel: JSON-LD tells a parser what your page contains, and WebMCP tells a browser agent what your page can do.

Summary

As agentic web standards mature, understanding where execution happens is everything.

• Use MCP when your agent needs to reach data that exists independently of any open browser tab.
• Use WebMCP when you want the agent to work cleanly with the page displayed to the user. Most real shopping flows will use both.