Bikeshedding the global name

Opening this issue to decide on a name for the main object going forward.

The current API proposal uses window.agent. window.mcp has been proposed elsewhere and I'd like to suggest switching to this.

agent (singular) may not be the best choice of name since it assumes there's only one agent. Support for multiple different agent clients has come up recently in issues like #20, #16. Even a single agent product (i.e. Claude, Copilot, Gemini) can have multiple different conversations which can be thought of as unique clients from the page's point of view. So agent seems less appropriate than it did when first drafting the explainer.

mcp sounds good to me too.

agent sounds good to me too.

To be clear, the suggestion is mcp instead of agent.

Oops, sorry. Fixed the comment and still LGTM.

Re: window / navigator -> I think it's worth looking permissions as a similar structure / context.

I recommend attaching this API to the navigator object rather than window as window is also used as the global namespace and anything we place there is at a high risk of causing conflicts.

I would also recommend against using an acronym here and prefer something like agentContext or toolRegistry.

Summary of the discussion today, no resolution yet.

08:31 Anssi: window.mcp is gaining support
08:32 Thomas: wanted to bring a point that Apple brought up feedback that web is something that will be here for tens of years to come and we should strive for neutral names for globals that stand the test of time
08:32 q+
08:32 * Zakim sees kush on the speaker queue
08:32 ack kush
08:32 * Zakim sees no one on the speaker queue
08:32 q+
08:32 * Zakim sees reillyg on the speaker queue
08:32 Khushal: I hear you, MCP is parallel to GL in terms of naming, we don't know how long this primitive lives
08:33 ack reillyg
08:33 * Zakim sees no one on the speaker queue
08:33 Reilly: adding to window object makes it part of global
08:33 ... has a decent likelyhood to collide with JS obfuscators
08:34 ... mediating between the agent and user, putting this on navigator would be preferred
08:35 Jason: wanted to mention that as Reilly mentioned, agent registry or a collective object skirts the issue for window.agent where you may have multiple agents down the road
08:35 q?
08:35 * Zakim sees no one on the speaker queue
08:36 Anssi: does this issue block some experimental implementation?
08:36 Khushal: there's an experimental implementation currently that depends on our naming discussion
08:37 q+
08:37 * Zakim sees brwalder on the speaker queue
08:37 Khushal: is there consensus to put this on navigator object?
08:37 ack brwalder
08:37 * Zakim sees no one on the speaker queue
08:37 *** Joon (~Joon@ed1fd930.publics.cloak) has quit (Joon)
08:38 Brandon: we got internal feedback that navigator is associated with the entire browser, not specific window or page, thus going with window initially
08:39 Reilly: document object would make more sense than window
08:40 Jason: parallels to permissions interface?
08:40 Reilly: exactly
08:40 Anssi: proposal to drive consensus via GH issue discussion in the issue #24 to converge on naming and where to hang it off of: window, document, navigator

As a third option, I would also consider window.agent with a nested window.agent.tools, or something similar. While the spec is focused on MCP, I think many sites will have their 1P agent implementations, for which it would be nice to have a standard interface to discover and interact with — e.g. window.agent.query() as a generic "let me ask you a question" and you decide how to fulfill it. The agent can also then expose a set of tools that the buyer agent/LLM can call directly.

In short, agent-to-agent should be a thing and have a standard namespace, exposed tools are properties of site's agent.

@reillyeon

Proposal:

Move the API to the Navigator/WorkerNavigator object, with the name .agentContext.

I was originally skeptical about using Navigator but I see that there's plenty of precedent for storing origin/site specific stuff there (i.e. permissions, USB, media sessions, etc.) As pointed out, this will also help keep the global namespace clean. I know that Document was also suggested as an alternative to Window during the community group meeting, but using Navigator instead of Document will come in handy if we decide to move forward with service worker support so this would be my preference.

As for the property name, .agentContext as suggested by @reillyeon avoids using an acronym and also addresses the original concern I raised in this thread. Unlike agent, agentContext doesn't make any assumptions about the number or kind of agents interacting with the site. This is also more generic than something like toolRegistry and leaves the door open for other kinds of MCP-like artifacts beyond tools. For example, resources as suggested in #29

Thumb-up / down to approve or disapprove. Happy to hear feedback or other alternatives too.

maybe its still worth treating the tools list like a registry, similar to a CustomElementsRegistry.

basically following roughly the same interface:

define(name: string, def: ToolDefinition): void;
get(name: string): ToolDefinition | undefined;
whenDefined(name: string): Promise<ToolDefinition>;

which would mean it'd be agent.tools.define(name, def) or some such thing

just a thought since the work that went into defining the CE registry probably involved a lot of similar discussions as any other registry would (like this one). so its good prior art

though i fully understand we might want to provide a larger context than just tools too. if thats very likely, probably best to ignore me! as we'd need a "context registry" of sorts then instead, which is far more complex than a CE registry.

Keeping things tidy and aligning with prior art using something like a .tools sub-object is a good idea. We already have some good discussion on what tool registration should look like in #15 which might be a better place to discuss that.

This specific issue is for coming to a resolution about the home of the "root" object that WebMCP will be exposed on. Settling on something like navigator.agentContext as the root doesn't preclude having something like navigator.agentContext.tools.

The argument for agentContext resonates. It also doesn't work against having scopes / namespaces, or different permissions for different agents, etc - or other similar developments that might happen in the future.

@igrigorik

@igrigorik you raised a good point about extensibility for interaction with an Agent on the site. Filed #31 to dig deeper into that. The example you mentioned, window.agent.query() as a generic "let me ask you a question" and you decide how to fulfill it. sounds like it could be another tool. The tool's implementation is a site's internal detail and it could be backed by an LLM. So I didn't see what's missing from the API for this use-case. But protocols like agent-to-agent have targeted this use-case separately from MCP so I'm sure it's worth looking into.

Conceptually this object is meant to expose primitives that the author can provide to an external agent. Right now we only have tools but others have come up: #29 for context and #21 for coordination/interleaving Agent and user control. So the name should reflect that purpose.

The con I see with agent now is based on what @igrigorik said, "window.agent.query() as a generic". It could be misconstrued as the site's agent. As opposed to functionality intended for another agent to consume.

How does agentHost or agentBridge sound? agentContext makes it seem limited to just context but there's more functionality in scope.

How does agentHost or agentBridge sound? agentContext makes it seem limited to just context but there's more functionality in scope.

Going by the precedent that Model Context Protocol established, "Context" is the generic term for any kind of stuff being exposed to an agent. Tools, resources, and prompts are all examples of context.

+1 for something along the lines of agentConext with a preference for modelContext instead considering the working group is currently called WebMCP.

RESOLUTION: navigator.modelContext is the "root" object name

Respectful counter proposal:

I’ve only discovered this API proposal about six or eight hours ago and not really dug into the MCP spec much before that. But finding this proposal and as someone who uses MCP quite a bit I have spent them last several hours going over the current specs trying to absorb what I could and also this thread. So if my following queries or ideas have been covered, my apologies because my searching missed it.

Precursor: This may seem like it goes off topic quite a bit, but this is merely because the Navigator API is quite broad and covers quite a few areas. I also go into how this will run in different scenarios. Ultimately it all comes together towards the end. If you feel it goes off topic too much feel free just to address my questions and ideas that are relevant 🙂.

I like the xxx.mcp.xxx naming, here's why:

I still favour explicit protocol namespacing on the Web surface. The following call shape is clear at a glance, easy to grep, and future friendly:

window.mcp.agent.query()
navigator.mcp.agentContext.description
navigator.mcp.agentContext.tools.listTools()

That style self-documents intent in reviews and logs and leaves space for v2 to vN upgrades and for parallel protocols later.

Placement: Worker-first, minimal Window shim

Long-lived agent sessions and tool orchestration fit Workers better than the Window. Workers have their own global scope, event loop, and WorkerNavigator. A Worker-first surface with a small Window shim keeps the interface responsive and the plumbing isolated.

For intra-origin coordination, use standard channels rather than inventing a new transport. A SharedWorker can hold client state for many tabs. BroadcastChannel or MessageChannel can fan updates and requests between tabs and workers. A service worker can broker across tabs and keep a single stream open when the page is backgrounded.

Privacy, permissions, and fingerprinting

Navigator already exposes many powerful features. MCP should follow platform norms: secure contexts, explicit user consent, and origin scoping through Permissions Policy. Avoid passive environment hints on the API objects. Discoverability should happen only after consent. Storage, keys, and logs should be partitioned per origin.

For manageability, please consider a first-class settings surface:

Settings → Site settings → Permissions → MCP

Per-site and per-tool toggles. Session-only grants. A clear-all control. A recent-usage list with a simple export of an audit log. This helps users and enterprise admins reason about risk.

Transport-specific scenarios that map to real products

A. `stdio` for local and extension bridges

stdio is ideal when the client can launch or attach to a local process. Pages cannot speak stdio directly for security reasons, but extensions and native shells can bridge to a local MCP server.

• Browser extensions can use Native Messaging to talk to a registered host over standard input and output. The extension’s service worker holds the session; content scripts present the interface and message the worker. This gives a clean path for a local MCP server with per-site consent.
• Electron and similar shells can host the same MCP server over stdio. The renderer side posts messages to the host bridge; no new Web surface is required.

Practical answer to a common question: could stdio help tabs interoperate. Inside a normal page, no. Use a SharedWorker or service worker plus BroadcastChannel inside the origin, and use Streamable HTTP to reach servers. stdio remains the right fit for extensions and native shells.

B. `Streamable HTTP` for cloud or local servers, with optional SSE

One endpoint on the server handles both POST and GET.
• POST sends one JSON-RPC message. The server responds with either a single JSON object or opens an SSE stream for multiple server messages.
• GET can open a long-lived SSE stream for unsolicited server-to-client events.
• Session headers and resumable streams are defined, which matters on flaky mobile networks. Include protocol version and session headers on subsequent requests.

Patterns that work well:

• PWA captures and reacts to events. A worker opens a GET with Accept: text/event-stream to receive tool notifications and progress, while pages come and go.
• Incremental results. A POST that returns text/event-stream lets the interface render tokens or steps as they arrive, then show the final JSON-RPC response.
• Cross-tab coordinator. A SharedWorker or service worker owns the SSE connection and broadcasts updates to tabs via BroadcastChannel, so you avoid many parallel streams.

C. Streaming media example: live translation

A worker captures audio frames from a media element or capture API, batches them, and POSTs to the MCP endpoint. The server streams back partial transcripts as SSE, then final segments, then English translations, then optional text-to-speech pointers. The page prints subtitles as text or swaps the audio track with overdub output. One endpoint, one long-lived GET for events, and one POST per control request. This is a good fit for news, sport, or lectures.

WebGPU and native runtimes side by side

This proposal does not force a single runtime choice. A PWA can run a compact model in the page using WebGPU for quick local tasks, yet still call out through MCP to a richer native or cloud runtime when needed. WebGPU’s entry point lives on navigator.gpu, and there are mature browser frameworks that show transformer-style inference in page for private, on-device processing.

On Android there are native options that an MCP client can wrap, such as AICore with Gemini Nano or MediaPipe Solutions. These complement the WebGPU route. With an explicit navigator.mcp, the Web surface stays consistent while the runtime behind it can be page GPU, app service, or cloud.

Extensions and PWAs together

Extensions can act as MCP hubs across sites. The MV3 background is a service worker. Use Native Messaging to reach a local server over stdio. Keep per-site state in a SharedWorker. Share with tabs via BroadcastChannel. These are well understood and review-friendly building blocks.

Why the explicit namespace still helps

Protocol name in the path enables clean feature detection, readable intent, and fewer surprises if a future protocol arrives. If another agent protocol or MCP v2 shows up, both can live side by side without collisions. That mirrors how navigator.gpu and navigator.bluetooth grew.

Questions for the group

Is a Worker-first surface on the table, with a minimal Window shim, so long-lived sessions and streams live off the main thread.
Would you consider navigator.mcp and a matching Worker-scoped surface, so the same calls work in both page and worker contexts.
For Streamable HTTP, is the plan to recommend a service worker or shared worker as the single SSE holder per origin to cut duplicate streams.
Would you support an explicit MCP permission and Permissions Policy token, plus a browser settings page with per-site and per-tool toggles and an exportable audit log.
For extensions, is Native Messaging plus stdio the expected bridge for local servers, with guidance on cross-origin consent prompts when tools span tabs.
For cross-tab within one origin, is the recommended pattern to keep streams and state in a worker and use BroadcastChannel or MessageChannel for fan-out.

In short: navigator.mcp or a Worker-scoped self.mcp gives clear call sites; Workers give the right lifecycle; the transports already map to deployable shapes. stdio for local and extensions. Streamable HTTP for servers. SSE inside that for progressive results and notifications. The remaining work is placement and permissioning so the surface is explicit, auditable, and easy to govern.

Sorry for the long post, very interesting addition if done correctly just right, But then you have the fear of it becoming a jack of all trades, yet masters nothing.

Thanks.

Seems we've settled on a global name! Going through the backlog of issues, I think we can close this. Feel free to comment or re-open if you disagree.

Navigation Menu

Repository navigation

Bikeshedding the global name #24

Respectful counter proposal:

I like the xxx.mcp.xxx naming, here's why:

Placement: Worker-first, minimal Window shim

Privacy, permissions, and fingerprinting

Transport-specific scenarios that map to real products

A. `stdio` for local and extension bridges

B. `Streamable HTTP` for cloud or local servers, with optional SSE

C. Streaming media example: live translation

WebGPU and native runtimes side by side

Extensions and PWAs together

Why the explicit namespace still helps

Questions for the group

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Bikeshedding the global name #24

Description

Activity

khushalsagar commented on Sep 16, 2025

bwalderman commented on Sep 16, 2025

khushalsagar commented on Sep 16, 2025

jasonjmcghee commented on Sep 18, 2025

reillyeon commented on Sep 18, 2025

khushalsagar commented on Sep 18, 2025

igrigorik commented on Sep 20, 2025

bwalderman commented on Sep 23, 2025

43081j commented on Sep 24, 2025

bwalderman commented on Sep 24, 2025

jasonjmcghee commented on Sep 24, 2025

khushalsagar commented on Sep 26, 2025

bwalderman commented on Sep 30, 2025

MiguelsPizza commented on Oct 1, 2025

anssiko commented on Oct 2, 2025

SuperPauly commented on Oct 21, 2025

Respectful counter proposal:

I like the xxx.mcp.xxx naming, here's why:

Placement: Worker-first, minimal Window shim

Privacy, permissions, and fingerprinting

Transport-specific scenarios that map to real products

A. stdio for local and extension bridges

B. Streamable HTTP for cloud or local servers, with optional SSE

C. Streaming media example: live translation

WebGPU and native runtimes side by side

Extensions and PWAs together

Why the explicit namespace still helps

Questions for the group

domfarolino commented on Mar 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

A. `stdio` for local and extension bridges

B. `Streamable HTTP` for cloud or local servers, with optional SSE