#dom-modelcontext-registertool could send an observation

[gterzian]

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.

[domfarolino]

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]

How does the agent learn about the tool if not by receiving an observation?

and likely leads to much more thrashing

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.

and doesn't coincide well with natural "turns" in the conversation

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]

How does the agent learn about the tool if not by receiving an observation?

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-context message. 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]

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.

That's not how Gemini-in-Chrome works today, and that's not a bug.

[gterzian]

Same goes for MCP Apps tools and update-host-context message.

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 listChanged is optional and would need to be set to true for that to happen.

That's not how Gemini-in-Chrome works today, and that's not a bug.

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).