WebMCP elicitation via requestUserInteraction() (was: Human in the Loop support for non-browser clients)

[MiguelsPizza]

The current spec is geared toward Human-in-the-Loop which is unofficially interpreted as "the agent lives in the context of the browser" (browser's agent, extension agent, Iframe agent etc). We initially elected that external agent browser automation cases be out of scope (see #21 and the 2025-09-18 resolution) and that WebMCP focuses on human-in-the-loop use cases initially. However, from what I've seen, a large part of the excitement around this API is geared toward remote browser automation over things like WebDriver BiDi / CDP.

Source: Cloudflare supports WebMCP-enabled browsers on their Browser Run platform

They also released an interesting Human-in-the-Loop feature that got me thinking about what a first-party integration between WebMCP and a non-browser-native client might look like. The user might be present but driving from outside the browser, so does this fall into our Human-in-the-Loop domain?

It might look something like this:

[Idan-Levin]

Hi @MiguelsPizza,

I think there's an important question in the business domain to work through before the remote browser implementation, which is: do website owners actually want their site to be executable remotely?

I believe in many cases the answer would be no. E-commerce is a good example, a storefront owner would love users running an AI side panel while they're browsing his site, but I'm not sure he'd like the ability to scrape the catalog or perform operations on the site without human eyes present. And this eventually might prevent many of them to implement WebMCP.

So the question is can there be different treatment for a remote browser vs. a browser where a human is present?

[MiguelsPizza]

I appreciate your thoughts @Idan-Levin

do website owners actually want their site to be executable remotely

From my experience, yes and no. No as in LinkedIn and Amazon really do not want their websites driven by remote agents. But yes as in I have seen (and worked with) companies using remote browsers to drive internal web apps that do not have an API. Mostly RPA for the latter but increasingly making use of agents.

Human in the Loop is generally pretty hard to do in a remote browser with agents at the moment. You kind of have to just hope they call whatever "ask for human help" tool they have when they get stuck, but they don't do it reliably. A request-human-interaction integration via WebMCP for agents driving a remote browser would take that decision out of their hands.

So the question is can there be different treatment for a remote browser vs. a browser where a human is present?

I see remote agents scraping sites as an upstream issue, not a WebMCP one. If an unwanted agent has already made it to the page and loaded in, blocking it further isn't really our job. That fight belongs earlier in the stack (bot detection, fingerprinting, etc.). Not saying we want to enable it, but giving sites better tools to block remote agents altogether feels like a separate issue.

[Idan-Levin]

good points @MiguelsPizza

I agree that creating webMCP checkpoints for HITL will be a great value prop

[bwalderman]

@MiguelsPizza , do you have any thoughts on what the requestUserInteraction primitive would look like in the remote scenario? In the current proposal, it causes the agent to yield control of the browser tab back to the human user and the human user does something in the tab. If the user is interacting through some other non-browser client interface, then I guess requestUserInteraction or whatever primitive is used in its place would look more like MCP elicitation?

[MiguelsPizza]

@bwalderman yea exactly, it would be up to the (non-browser) client to focus the browser on the proper tab upon elicitation.

[domfarolino]

We'll need to consider how this works with non-native agents, like in-page ones built with JavaScript and iframes. These don't have the ability to impact browser UI and focus a tab that's backgrounded in the same way that a native agent would, so we need to see if methods on ModelContextClient (like requestUserInteraction()) should always result in browser UI being triggered (prone to abuse), or if the agent is responsible for handling this in the best way it can, in which case native ones would be able to do something that in-page ones just couldn't. I think that's fine though.

[anssiko]

RESOLUTION: Form a concrete design for user interaction to satisfy non-browser client Human-in-the-Loop use cases.

[bwalderman]

There was discussion on the call earlier today that WebMCP may need something different than requestUserInteraction in its current form to support these human-in-the-loop scenarios where the human and the browser aren't colocated.

Here's a proposal to bring MCP elicitation's Form and URL flows into WebMCP. I've renamed the proposed method to requestUserInput in these examples. I still see value in having an interactive mode for ellicitation because in local browsing scenarios, WebMCP has the unique advantage that tool calls executing in the page can elicit information directly from the user without needing to go through the agent at all.

Actors

Actor	Description
User	The human end-user
Agent Frontend	The conversational UI the user interacts with (local sidebar, mobile app, desktop app, etc.)
Agent	The WebMCP-based browsing agent that drives the page
Page	The web page running the WebMCP tool code

---

1. Interactive Flow (local browsing only)

The tool renders custom in-page UI and asks the agent to yield control to the user so they can input information directly into the page. Only available when the user has direct access to the browser.

const result = await client.requestUserInput({ mode: "interactive" }, async () => { ... });

Local Scenario

sequenceDiagram
    actor User
    participant AgentFrontend as Agent Frontend
    participant Agent
    participant Page

    Agent->>Page: Invoke WebMCP tool
    activate Page
    Page->>Page: requestUserInput({ mode: "interactive" }, callback)
    Page->>Agent: Elicitation request (interactive)
    Agent->>Agent: Unlock mouse/keyboard control
    Agent->>AgentFrontend: "example.com needs your input"
    AgentFrontend->>User: Display message

    Page->>Page: Execute callback — render in-page UI
    activate Page
    Note over Page: Page displays custom input UI

    User->>Page: Interact with in-page UI directly
    Note over Page: User data stays in-page,<br/>not exposed to the agent
    Page->>Page: Callback completes with user data
    deactivate Page

    Page->>Page: Tool code proceeds with user data
    Page->>Agent: Signal: elicitation complete
    Agent->>Agent: Re-lock mouse/keyboard control
    Page-->>Agent: Return tool result
    deactivate Page
    Agent->>AgentFrontend: Resume conversation

Loading

Remote Scenario

Not available. The user does not have direct access to the browser, so interactive in-page UI cannot be used.

---

2. Form Flow (local & remote)

The tool supplies a requestedSchema describing the data it needs. The agent frontend generates a form in the conversation window, collects the information from the user, and returns it to the tool in the page.

const result = await client.requestUserInput({ mode: "form", requestedSchema: { ... } });

sequenceDiagram
    actor User
    participant AgentFrontend as Agent Frontend<br/>(local or remote)
    participant Agent
    participant Page

    Agent->>Page: Invoke WebMCP tool
    activate Page
    Page->>Page: requestUserInput({ mode: "form", requestedSchema })
    Page->>Agent: Elicitation request (schema)
    Agent->>AgentFrontend: Forward schema for form generation

    AgentFrontend->>AgentFrontend: Render form UI from schema
    AgentFrontend->>User: Display form in conversation window
    User->>AgentFrontend: Fill out and submit form
    AgentFrontend->>Agent: Return form data
    Agent->>Page: Deliver form data to tool

    Page-->>Agent: Return tool result
    deactivate Page
    Agent->>AgentFrontend: Resume conversation with result

Loading

---

3. URL Flow (local & remote)

For sensitive flows where the site owner does not want user-provided information to flow through the agent but still wants to support remote browsing. The tool provides a URL; the agent frontend asks the user to navigate there and take action. The call returns as soon as the user accepts, declines, or cancels the navigation prompt. The tool detects completion and retrieves data through out-of-band means (e.g., a site backend callback via websocket).

// Set up out-of-band mechanism to await information from site backend
const result = await client.requestUserInput({ mode: "url", url: "https://example.com/authenticate?..." });
// Await the information while user visits the URL wherever they are.

sequenceDiagram
    actor User
    participant AgentFrontend as Agent Frontend<br/>(local or remote)
    participant Agent
    participant Page
    participant SiteBackend as Site Backend

    Agent->>Page: Invoke WebMCP tool
    activate Page
    Page->>Page: requestUserInput({ mode: "url", url })
    Page->>Agent: Elicitation request (url)
    Agent->>AgentFrontend: Present URL navigation prompt

    AgentFrontend->>User: "Please visit this URL to continue"

    alt User accepts
        User->>AgentFrontend: Accept
        AgentFrontend->>Agent: User accepted
        Agent->>Page: Return accepted

        Note over User: User opens URL in their<br/>own browser
        User->>SiteBackend: Navigate to URL & complete action
        SiteBackend->>SiteBackend: Record completion

        Page->>SiteBackend: Poll / await out-of-band signal
        SiteBackend-->>Page: Confirmation + data
    else User declines / cancels
        User->>AgentFrontend: Decline / Cancel
        AgentFrontend->>Agent: User declined
        Agent->>Page: Return declined
    end

    Page-->>Agent: Return tool result
    deactivate Page
    Agent->>AgentFrontend: Resume conversation with result

Loading

[domfarolino]

Thanks for detailing this out @bwalderman! This is exactly what myself and I think @bvandersloot assumed requestUserInteraction() would do for use cases (1) and (2) above. I haven't thought much about (3) yet. Before proceeding much further, do we think we can agree that requestUserInteraction() can be repurposed or scrapped in favor of supporting the use cases outlined above? I'm not sure what utility it has outside of what's described here.

[MiguelsPizza]

Thank @bwalderman and +1 @domfarolino

Might be worth looking into URL Mode Elicitation from MCP for option 3

[bwalderman]

@domfarolino, yes we can scrap requestUserInteraction if we decide to go with requestUserInput. The "interactive" mode is meant to work as requestUserInteraction would have.

@MiguelsPizza the Form and URL modes are lifted directly from the MCP Elicitation spec.

[bwalderman]

Open Question: What do the Form and URL flows look like for in-page agents?

The in-page agent needs to somehow be notified of an elicitation request that happens during a tool call it initiates. For form mode, it would be responsible for rendering a form and returning the result to the tool.

[domfarolino]

The "interactive" mode is meant to work as requestUserInteraction would have.

Well, mode: "interactive" actually surfaces the request to the agent to prompt the user for input to the site, where as the current explainer description of requestUserInteraction() never involves the agent, and leaves it up to the tool to just show some web content that tells the user to give more input, right? In that sense, the two seem slightly different.