MCP vs WebMCP: choose where your website's agent acts

Choose the execution location, not just the protocol

MCP connects a compatible client to tools exposed by a server. WebMCP lets a rendered page expose tools to agents operating in that page. As Chrome's comparison explains, WebMCP is neither an extension nor a replacement for MCP. It is an evolving browser proposal, not a universal agent-discovery mechanism or an SEO ranking factor.

An MCP URL alone does not tell you where the work runs. An independently hosted service can execute backend operations without a user's tab; Bunkhouse instead routes calls from the user's MCP client to their connected browser tab. The MCP server being reachable does not make that tab available.

Start with accessible controls and your existing backend authorization. A documented API may already be enough for a known integration. Add MCP when compatible clients need tool discovery and calls; add page tools when the current UI and browser session matter. See the website readiness checklist for the broader foundation.

MCP, WebMCP and the Bunkhouse relay

On small screens, scroll the table horizontally. Keyboard users can focus the table and use the arrow keys.

Decision	Service-hosted MCP	Page-declared WebMCP	Bunkhouse MCP relay
Where work runs	Your service and backend business logic.	The page's JavaScript runtime; tools may call its backend.	The connected tab, using Bunkhouse skills and the same dispatcher as its in-page assistant.
Login and credentials	The server's configured credentials and authorization; no inherent browser session.	The user's current page session. Backend permissions still apply.	Bunkhouse OAuth authorizes the client; host operations use the signed-in user's tab session. Host credentials stay in the tab.
Open-tab requirement	None if your implementation is independent of the browser. Availability still depends on the service.	The page must remain available; closing or navigating away removes its tools.	A live connected tab is required. Page-control actions also need it visible; background tabs can be frozen or discarded.
Client prerequisites	A compatible MCP client configured for your server's transport and authorization.	A browser or agent integration that supports the page's WebMCP API. An MCP-only client is not enough.	A compatible remote MCP/OAuth client, external agents enabled on the site, user consent and a connected signed-in tab.
Write review	Implement confirmation and access control. MCP recommends human review; the protocol does not enforce a specific UI.	Review depends on the caller and tool implementation. Tool annotations are not authorization.	Writes and unknown effects require write scope and use the embed's review flow. Limited user-selected auto-approval may apply; see below.
Suitable tasks	Service data access and backend work that must not depend on a user's tab.	Explicit in-context actions in an open app, using its current state.	A user brings their own agent to operate an existing open app through its eligible skills and review UI.

This compares implementations, not a promise that all MCP servers are always on. MCP can also use local processes, and a service still needs its own scheduling, reliability and permission design. Sources: Chrome's lifecycle comparison, the MCP tools specification and the Bunkhouse external-agent contract.

One draft record, two different requirements

Suppose a user has a draft support response open and asks: “Change this draft's title to Delivery update; do not send it.” A page tool can expose that exact edit. Bunkhouse can offer an assistant inside the app, or relay the user's external agent to eligible skills in the connected tab. Check that only the draft title changes and that no send action occurs. This is a suggested evaluation task, not a claimed benchmark result.

Now change the requirement: “Update tomorrow's drafts at 02:00, even if I close the browser.” Choose a backend workflow with explicit permissions and, if needed, a service-hosted MCP interface. Neither page-level WebMCP nor Bunkhouse's live-tab relay supplies an unattended backend executor. Keeping a tab in the background is not a reliability plan.

Bunkhouse is a fit when you want the existing page, skill discovery, sandboxed execution and user review rather than building a separate assistant interaction. If you only need to expose a few explicit page functions to an already-supported browser agent, direct WebMCP may be sufficient. If you only need a known API integration, use that API. Bunkhouse adds an agent to a website; it does not build the website.

Three distinct Bunkhouse tool paths

Consume page tools: the Bunkhouse assistant discovers WebMCP tools your page declares, alongside page controls, observed requests and hints. Tools marked readOnlyHint: true are treated as reads; other WebMCP tools are consequential. Misclassifying a write as a read removes its review.
Publish eligible skills: enabling external agents lets the embed publish eligible skills to in-page WebMCP callers. Trusted exposure uses hints and published discovery cache; All live skills also includes live discovery. Page-declared WebMCP tools are not republished, avoiding a loop. In-page WebMCP callers are never offered run auto-approval.
Relay remote calls: a connected MCP client uses Bunkhouse's search_skills, describe_skill and execute tools. Calls execute in the live tab; eligible page-declared WebMCP tools are callable through this path. The relay uses no hosted model and consumes no Bunkhouse inference credits. The external client's own model costs and limits still apply.

These paths are not interchangeable. A WebMCP polyfill does not make every agent compatible, and publication does not mean an external client has connected. The skills guide explains discovery limits; the publication guide lists browser requirements and the bundled polyfill. The remote MCP relay does not require native WebMCP support.

Evaluate external access as a separate production integration

External agents are off by default. Begin with your production site's embed and signed-in identity integration, enable external agents, choose the exposed skills, and give users the site's MCP URL. Bunkhouse supplies the OAuth authorization server; you do not implement another one on your host. This is configuration on an existing installation, not a claim that adding an MCP URL creates the app's identity or authorization layer.

Check the actual client: it must support the documented registration and authorization-code flow with PKCE S256, state and the MCP URL as resource. Clients that omit required parameters or use unsupported redirect schemes cannot connect. Follow the client requirements, not an assumed compatibility list.
Keep the executor available: no connected tab returns no_live_tab. Hidden-tab page-control actions fail with tab_not_visible. API and WebMCP actions do not require visibility, but the browser may still freeze or discard the tab.
Review consequential work: reads require skills:read; writes and unknown effects require skills:write. Writes normally show the client-labelled approval dialog. If the site allows it, the user can enable limited auto-approval while that client is connected; it ends on disconnect, reload, sign-out or revocation. Identical repeated writes still ask again.
Keep the data boundary explicit: host credentials stay in the tab, but validated inputs, results and compact action outcomes travel through Bunkhouse to the client. “Credentials stay local” does not mean “no application data leaves the browser.” Keep server authorization and review what data each skill can return. Follow the security guide.
Test recovery, not just a happy call: verify a rejected edit leaves the draft unchanged, an approved edit changes only its title, a closed tab refuses work, and revocation stops further calls. On sign-out, call resetSession() for immediate disconnection. An ambiguous write result is not permission to replay it; follow the documented request-ID and outcome rules.

Use the external-agent setup and recovery guide for implementation. Production signup and billing terms are separate from the free trial; no inference-credit charge for relay calls does not imply a free production subscription.

Try the in-page task before choosing the integration

On a disposable page, create one dummy draft with a labelled title field and a Save button, with no send action or real customer data. Use Bunkhouse's free coding-agent trial to check discovery and in-page actions without a Bunkhouse account, card or model API key. Your coding agent must make HTTP requests and keep serving turns; it supplies the replies rather than Bunkhouse's hosted model.

Prompt for your coding agent

Read https://api.bunkhouse.ai/agent-trial.md and follow it to run a Bunkhouse agent trial on my dummy page at http://localhost:3000.

Use dummy data: page controls, messages and data the assistant reads travel through the service to your coding agent.

With auto-approval off, ask to change the draft title. Reject the write and confirm the saved title is unchanged. Reset the page, repeat and approve only that change; confirm the saved title is Delivery update and the pane reaches Done. The trial evaluation checklist explains how to distinguish an edited field from a saved result and what to do when a case fails.

The trial lasts 24 hours with 100 total turns; the live trial protocol defines all limits and setup steps. It evaluates the embed's discovery and actions on this dummy page. External agents are disabled for trial sites: this does not test remote-client OAuth, WebMCP publication, production permissions, hosted-model quality or unattended execution. If the in-page task fits, evaluate the separate production external-agent integration above before promising it to users.