Repository navigation
#dom-modelcontext-registertool could send an observation #230
Description
https://webmachinelearning.github.io/webmcp/#dom-modelcontext-registertool currently only notifies other documents of the tool change; sending an observation to the browser agent is left open and presumably done as part of the implementation defined part of when to send an observation, but it seems to me that doing it on a tool change always makes sense and is worth mandating with MUST.
Especially if something like application driven observation were to be added, since if the spec mandates an observation on tool change, the app then can rely on that and avoid sending it's own.
Activity
[-]#dom-modelcontext-registertool should send an observation[/-][+]#dom-modelcontext-registertool could send an observation[/+]domfarolino commentedon Jul 29, 2026
I definitely don't think requiring a new observation on each tool is the right model here. We can discuss more coarse observation checkpoints in #229, but forcing observations on each tool registration is definitely not the right model, and likely leads to much more thrashing and doesn't coincide well with natural "turns" in the conversation.
gterzian commentedon Jul 29, 2026
How does the agent learn about the tool if not by receiving an observation?
I think here you are assuming that an "observation" means a certain type of data that always has to be sent, but what I mean is that in the case of a registering a new tool, an observation should be sent only containing the info pertaining to that newly registered tool (so not the whole tool map, and neither other stuff). This assumes observations can contain different data based on what triggered them.
If an application can dynamically register new tools, then that should definitely trigger some kind of new turn so the agent can become aware of the new tool.
domfarolino commentedon Jul 29, 2026
It learns about tools through observations. Observations can happen whenever the agent wants. The agent can perform an observation on each tool registration, if it wants to be really aggressive, or it can only produce observations on each turn of the conversation, which is how a lot of agents work right now. Same goes for MCP Apps tools and
update-host-contextmessage. The best that the app can do is put things in a place where agents can reach them, but it's up to the agent to determine how often and when to reach them.domfarolino commentedon Jul 29, 2026
That's not how Gemini-in-Chrome works today, and that's not a bug.
gterzian commentedon Jul 29, 2026
I think you meant to link to https://github.com/modelcontextprotocol/ext-apps/blob/92f46a574568a3ddac7600343b7d3c4c4ed7b588/specification/draft/apps.mdx#tool-lifecycle instead. The assumption, from the examples at least, seem to be that the default is meant to always immediately notify of tool changes, although
listChangedis optional and would need to be set to true for that to happen.I can imagine delaying the tool observation to the next turn, but that appears like a marginal optimization to me (unless a large amount of tools are registered and often never used), that could also be a source of deadlock-like bugs (like an app adding a tool with a description for it to be called immediately, even if just for testing).