Repository navigation
SEP: Context update mechanism #61
Description
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).
Activity
[-]SEP: context update mechanism[/-][+]SEP: Context update mechanism[/+]idosal commentedon Dec 10, 2025
Please see #125.
idosal commentedon Dec 16, 2025
@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.
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 -
Ideas and feedback are more than welcome!
idosal commentedon Dec 18, 2025
After further discussions, for the MVP, we propose clarifying that
ui/update-model-contextwill overwrite the previous state.In the future, following community feedback and requirements, we can extend it to enable maintaining history and other enhancements.
unity commentedon Jan 7, 2026
A useful distinction, for further evolutions comes from CQRS and Event sourcing patterns, and differenciate between an
eventand acommand:An
eventcarries 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 offrom / tovalues) whereas acommandasks the recipient to perform something.Here,
update-model-contextwould be a command, asking the recipient to update the context, whereasnotifications/messageis more of an event, telling recipients that the context was updatedIn 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 commentedon Jan 21, 2026
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).