Keeping the agent in-sync with the page's context

[yoavweiss]

Playing around with WebMCP, I find myself in situations where the agent is not aware of the page's context. The human user has visuals and text that help them understand what page they are on. The agent needs to use snapshots and DOM/a11y tree walking to get similar context.

Context changes can be a result of tool calls, but can also be the result of a human user interaction with the page or time-based context changes (e.g. video ended and a new one starts playing). Tool output can help provide contexts in the first case, but not others.

It might be good to enable developers with the means to:

• Let the agent know that the context has changed (due to a hard navigation, soft navigation or some other interaction).
• Provide the current page context to agents, and potentially add extra details about it.

Example use cases:

• A product page could provide high-level details about the product, allowing the agent to have more context when the user asks it basic questions about it, even before calling tools that provide more detailed descriptions.
• A checkout page with multiple different shipping addresses can provide them as context for the agent, allowing it to offer contextual shortcut enabling the user to indicate preference for one versus the other (instead of the user typing in a full address that's already on file).

[beaufortfrancois]

I'd like to jump in and share some practical thoughts on how this could work for in-page agents. Providing both static and dynamic mechanisms for pages to declare contextual state would allow the agent runtime to prepend or inject it into its prompts.

For static or server-rendered pages, authors could expose high-level context via <meta name="model-context-state" content="Product page: Pixel 9 Pro. Key specs: 16GB RAM, Tensor G4.">. On initial navigation/page load, the in-page agent would read the meta tag and inject the content as contextual framing into the prompt context.

For soft navigations, client-side state transitions, or async user interactions, developers could use a registered callback to be invoked by the agent immediately before constructing a prompt turn:

document.modelContext.registerContextProvider(async () => {
  return {
    view: "product_detail",
    selectedVariant: { sku: "G9P-128", inStock: true },
    activeTab: "tech_specs"
  };
});

[Kulikowski]

I like the proposal! In-page agent assuming its shipped by the website provider will have access to state anyway right? So it's more for 3rd party embedded agents and extension/browser-based ones?

[rohit-binaried]

Even an app-owned agent benefits from an explicit projection: access to React state does not tell it which fields are relevant, current, or appropriate to send to a model. For the shipping-address example, that projection could expose a selected address ID and approved display labels without serializing the entire account object.

I maintain RCIP, where consumers read application snapshots and subscribe to changes. A human UI update can therefore change the consumer-visible context without a tool call. Consumer contract.

For this proposal, I would separate “context changed” notification from “read current context,” so a consumer can coalesce updates before its next turn. RCIP is an in-process implementation, not WebMCP compatibility evidence; mapping that behavior across a browser/extension boundary remains integration work.