SEP-1975: Conversation Event Subscriptions#1975
SEP-1975: Conversation Event Subscriptions#1975varun29ankuS wants to merge 3 commits intomodelcontextprotocol:mainfrom
Conversation
Add capability for MCP servers to subscribe to conversation events, enabling automatic context injection for memory systems, knowledge bases, and context-aware assistants.
localden
changed the title
|
@varun29ankuS this SEP does not have an assigned sponsor. Are you looking to continue working on it and find sponsorship? |
|
@localden Yes, I want to continue. I'm building memory for AI agents (shodh-memory). The problem: memory only works if it can see what's happening. Right now, MCP servers are deaf unless the LLM decides to call a tool. Human memory doesn't wait to be asked — relevant context surfaces automatically. That's what this enables. Other memory servers face the same limitation (mem0, basic-memory). Even Claude Code uses hooks for memory injection — the pattern clearly works, it just needs protocol support. Happy to iterate on the spec. Would you be open to sponsoring, or could you point me to someone who might? Looking forward to your reply. |
|
Related: RFC #2043 (Memory Portability Tools) These proposals are complementary:
Together they form a complete memory layer for MCP. |
|
Gentle bump on this. We've been shipping shodh-memory (now at v0.1.75) and the lack of conversation event subscriptions remains the biggest gap — memory servers have to rely on hooks/workarounds instead of a proper protocol-level integration. Happy to iterate on the spec if there's feedback, or adjust scope to find a sponsor. What would help move this forward? |
3 participants
Summary
This SEP proposes adding an optional
conversationEventscapability that allows MCP servers to subscribe to conversation-level events. When a user sends a message, subscribed servers receive the content and can respond with context to inject into the LLM's prompt.Motivation
Building a memory system for AI assistants, I hit a wall: MCP servers only receive data when the LLM explicitly calls a tool. If it doesn't call
recall(), the memory system is blind.Workarounds like strong tool descriptions, piggybacking on other tools, or client-side hooks don't reliably solve this. The protocol needs to support automatic context injection.
Use Cases
Key Points
conversationEventscapability withonUserMessagesubscriptionFull specification in the SEP file.
Happy to iterate on the details. The core ask: let servers see the conversation so they can provide automatic context.