SEP: Context update mechanism

[idosal]

An app-generated event to update the agent's context without requiring a follow-up action (e.g., a prompt) has many use cases (for example see SEP PR by @PederHP, @tschei-di, and others).

That’s the original intent behind notify, but there are semantic differences between MCP-UI’s notify (which updates the context) and the proposed notifications/message (which MCP describes as general logging).

We should decide how to handle it (e.g., use a different event, define different semantics, or use an alternative mechanism).

[idosal]

Please see #125.

[idosal]

@antonpk1 raised a good point - appending every UI-driven update into the model’s context can pollute the context in some use cases (e.g., an email composer where we mostly care about “the current draft”, not an ever-growing log of keystrokes). In those cases, a mutable “latest snapshot” seems like a better fit than an append-only stream.

• Mutable state (replace semantics) - A single “current state” object that overwrites previous state.
  • Useful when the model only needs the latest state
  • The app must maintain history
  • Easier context management
• Notification pattern (append log/stream) - Send context updates to the Host as they happen, accumulating as an append-only log.
  • Apps don't need to maintain state (or rehydrate from the host)
  • Risk of context pollution

Both mechanisms have their use cases. Theoretically, mutable state can answer all of them, at the price of app-based state management.
We should prioritize a direction for the MVP. A few ways forward -

1. Start with write-only mutable state - Apps can write the latest snapshot, but they can't maintain history
2. Flexible mutable state - Apps can write AND persist previous state, so that they can merge them into one snapshot. This requires adding a persistence mechanism
3. Continue with the notification pattern

Ideas and feedback are more than welcome!

[idosal]

After further discussions, for the MVP, we propose clarifying that ui/update-model-context will overwrite the previous state.
In the future, following community feedback and requirements, we can extend it to enable maintaining history and other enhancements.

[unity]

A useful distinction, for further evolutions comes from CQRS and Event sourcing patterns, and differenciate between an event and a command:

An event carries a state mutation, and merely broadcasts the fact that it happened (and can optionally contain a copy of the full state, and/or a diff object, a list of from / to values) whereas a command asks the recipient to perform something.

Here, update-model-context would be a command, asking the recipient to update the context, whereas notifications/message is more of an event, telling recipients that the context was updated

In event sourcing, it's expected that the recipient reconstruct the state from the stream of events, but that's not a light pattern on the recipient side. Some patterns describe embedding the state in the event so that the recipient can either fully replace it or historize them

[ochafik]

Fixed by #125, also see follow up #319 re/ notification vs. ack semantics (would be good to know if / when the context is actually read by the model).