Compare WebMCP In-Page Tools vs MCP Before Origin Trial

Browser agents that click visible UI elements fail when labels change or a redesign ships. WebMCP is a contract that lets the open page publish tools an in-browser agent can discover and invoke. It is not a reason to delete server-side MCP.

📑Table of Contents

1. WebMCP Publishes In-Page Tools; It Does Not Replace MCP
2. Choose registerTool or a Declarative Form
3. Test Chrome Origin Trial 149 Before a Production Token
4. Compare WebMCP, Server MCP, and Screen Agents
5. Limits and Tool Safety Before You Adopt
6. Author Perspective
7. FAQ
8. Summary

Choose WebMCP or backend MCP first

• Use WebMCP when the agent needs tab state such as login, cart, or filters.
• Keep backend MCP for headless APIs.

You can start today with the Chrome 149 origin trial, or with chrome://flags/#enable-webmcp-testing, using one read-only look tool.

---

WebMCP Publishes In-Page Tools; It Does Not Replace MCP

What the page publishes

WebMCP exposes page JavaScript functions as tools with a name, description, JSON Schema, and execute handler. The W3C WebMCP draft compares such a page to an MCP server whose tools run in client-side script. Invokers include browser agents and assistive technologies. The human and the agent stay on the same interface.

---

Non-goals and session inheritance

The goal is fewer screenshot and DOM-click guesses. The official GitHub explainer lists non-goals: fully autonomous work without a human, headless-first use, replacing backend MCP, and removing the human UI. Server MCP talks to APIs outside the browser session. WebMCP tools inherit the open tab’s login, cart, filters, and unsaved drafts.

---

Decide with tab state

Decide first whether the job needs tab state. If it does, use WebMCP. If it needs a batch API with no visible browser, use MCP. If you need both, split the roles. Host, client, and server roles for MCP itself belong in the related MCP architecture article. This piece stays focused on the browser API and the adoption call.

---

Choose registerTool or a Declarative Form

Imperative registerTool

The imperative path is document.modelContext.registerTool.

• Tool names are 1–128 characters of ASCII alphanumerics plus _, -, and ..
• Unregister by aborting the AbortSignal passed at registration. From Chrome 153, unregister can leave in-flight executions alone.
• Discovery uses getTools() (same-origin by default). Execution uses executeTool(tool, jsonString).
• Cross-origin discovery needs both fromOrigins and exposedTo.

const controller = new AbortController();
await document.modelContext.registerTool({
  name: "search_catalog",
  description: "Search products currently visible on this page.",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", description: "Search keyword" }
    },
    required: ["query"]
  },
  annotations: { readOnlyHint: true },
  execute: async ({ query }) => JSON.stringify({ query, matches: [] })
}, { signal: controller.signal });

---

Declarative HTML forms

The declarative path annotates an existing HTML form with toolname and tooldescription. The agent focuses the form and fills fields. The default is a human Submit. Auto-submit needs toolautosubmit. The page can inspect SubmitEvent.agentInvoked and reply with respondWith(). Use the form path for static search or contact flows. Use registerTool for dynamic filters and state changes.

Sources: Chrome Imperative API, Chrome Declarative API, W3C WebMCP draft (as of September 2026)

---

Test Chrome Origin Trial 149 Before a Production Token

Run one tool locally before attaching a production origin-trial token.

Local trial steps

1. Register for the WebMCP origin trial (Chrome 149 onward).
2. For local testing, set chrome://flags/#enable-webmcp-testing to Enabled and relaunch.
3. Use the Model Context Tool Inspector to list tools, inspect schemas, and invoke them. The default model is gemini-3-flash-preview.
4. Ship the first tool as a look tool that returns JSON and does not mutate state.

---

Public trial window

Independent write-ups describe the public trial as Chrome 149 through 156 (No Hacks, Spronta). Recheck the flag and Chrome Status after that window.

---

API entry point and origin isolation

API migration points:

• The entry point is document.modelContext. navigator.modelContext is a deprecated alias as of Chrome 150.
• provideContext / clearContext were removed because a third-party script could overwrite the whole tool list.
• registerTool is additive and throws on a name collision.

---

Origin isolation and permissions

Limits:

• Origin isolation is required. The API is disabled when document.domain is enabled or Origin-Agent-Cluster: ?0 is set.
• The tools Permissions Policy defaults to self. Cross-origin iframes need allow="tools".

Sources: Chrome WebMCP (overview updated 2026-08-07), Jangwook origin-trial notes

---

Compare WebMCP, Server MCP, and Screen Agents

The adoption table shows where code runs and which session it inherits. Keep screenshot or accessibility-tree agents as a fallback for sites that do not publish tools. When the site author has published a contract, structured tools fail less often than click guessing.

Adoption table

Approach	Runs in	Session	Good for	Poor for
WebMCP	JS / forms on the open page	Inherits the logged-in tab	Filters, drafts, support forms, look/act	Headless batches with no browser
Server MCP	Backend APIs	Separate auth and state copy	Server search, internal APIs, headless agents	Cart or unsaved on-screen UI state
Screenshot / a11y actuation	Vision or DOM guessing	Sees the page without a site contract	Fallback when WebMCP is missing	Ambiguous labels and frequent UI churn

---

Look versus act

Sources (August–September 2026):

• WebMCP GitHub
• Chrome WebMCP
• HackerNoon
• Tarsk

Split published tools into look (return page state as JSON) and act (change the UI). Purchases, deletes, and submits need a confirmation dialog. Tarsk reports Shopify hosted storefronts enabling WebMCP while keeping payment as a human step with no payment tool. ChatGPT desktop site tools are covered in the related article.

---

Limits and Tool Safety Before You Adopt

Hints and character budgets

Chrome states that it cannot guarantee safety inside an LLM. Mark UGC and external data with untrustedContentHint: true. Mark non-mutating tools with readOnlyHint: true. Character budgets are about 500 for descriptions, 150 for parameter descriptions, 30 for names, and 1.5K for one tool result. Other sites and cross-origin iframes do not see tools by default. Keep exposedTo to trusted https origins, or omit it.

---

Injection and discovery limits

Independent sources warn that tool descriptions and results can carry prompt-injection text. Put costly actions behind confirmation. Clients must visit the site to discover tools, so headless-first operations are a poor fit. The spec is a W3C Web Machine Learning Community Group draft, not a Standards Track document. Native Edge support was unconfirmed in the independent sources used here.

---

Pre-adoption checklist

• ✓ One tool ran from Inspector under the origin trial or local flag
• ✓ look and act are split; destructive act tools require confirmation
• ✓ untrustedContentHint / readOnlyHint are set
• ✓ exposedTo is minimal or omitted
• ✓ Work that a server MCP already covers is not copied into WebMCP

Sources: Chrome secure tools (updated 2026-07-01), botmonster

---

Author Perspective

The fork is whether tab state is required, not whether the API is new. Duplicating a cart or filter into a server MCP so an agent can see it requires more work than a look tool on the page. Putting overnight batches on WebMCP will fail because those jobs assume no human tab.

Keep the first implementation to one read-only look tool. When you add act tools, do not mix purchase, delete, and outbound submit in the same handler. During the origin trial, record the flag and token expiry, then recheck Chrome Status before any wider rollout.

---

FAQ

Adoption

Q. Can we drop MCP servers once WebMCP ships?

A. No. The GitHub non-goals reject replacing backend MCP. Tab-external APIs stay on MCP. In-tab UI stays on WebMCP.

Q. Is this ready for production traffic?

A. It is a Community Group draft, not Standards Track. Chrome is in an origin trial. Do not ship without flag testing and confirmation dialogs on consequential actions.

---

Implementation boundaries

Q. Are declarative forms enough?

A. Yes for existing HTML search or contact forms. Dynamic state changes need registerTool. Auto-submit needs toolautosubmit.

Q. Does this work outside Chrome?

A. The documented public origin trial starts at Chrome 149. Native Edge support was unconfirmed in independent sources. Check GitHub Implementation Status for other browsers.

Q. May a cross-origin iframe publish tools?

A. Not by default. You need both allow="tools" and exposedTo. Choose origins with the same bar you use for sharing user data.

---

Related articles:

• 13647
• 13644

Summary

WebMCP is an in-page tool contract authored by the site. It fails less often than click guessing. It is not a superset of MCP. Next: run one look tool in Inspector under the flag or origin trial, keep act tools behind confirmation, and write down the split with server MCP. Recheck the trial window and API names before you publish, because both the draft and Chrome docs are still moving.