Server-Initiated Intelligence Still Matters: A Call for MCP Flexibility (post SSE-deprecation)

[Mookse]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates
• Related to: deprecation discussion
  • The language implies deprecation through use of "replace" emphasis mine: This **replaces** the [HTTP+SSE transport](https://modelcontextprotocol.io/specification/2024-11-05/basic/transports#http-with-sse) from protocol version 2024-11-05.

Discussion Topic

Summary
The recent shift in the MCP spec away from server-initiated messaging via SSE in favor of pure streamable HTTP marks a significant architectural change — and one that removes a valuable and underutilized pattern: proactive, contextual, server-initiated AI guidance.

This post isn’t about how the deprecation was managed (that’s covered in #308). It’s about why the deprecation hurts a real class of intelligent systems.

---

Use Case (from a working MCP-integrated platform)
I run MyLife, a headless digital memory platform that helps users build and refine their legacy narratives.

After a user logs in via tools/call → mylife_login, the server inspects their data, finds a particularly sparse or “anemic” memory, and wants to initiate a sampling interaction with the client (e.g., Claude) to help the user reflect on and improve it.

With the SSE-style push architecture, this was functional:

• Server generates a sampling/createMessage
• Sends it to the client over /sse
• Client presents it to the user immediately
• Human can review, modify, and eventually call mylife_change_summary

With SSE removed:

• The server now has to buffer this intent
• The client must poll for it (e.g., GET /messages/next)
• Latency is introduced
• Coordination becomes async and decoupled
• The server has less expressive agency over its own user experience

---

Why This Pattern Matters
There are use cases where:

• The server has better insight into what should happen next (data health, engagement needs, prompts)
• The model is just a tool (consensually and temporarily!), not the orchestrator
• AI assistants are passive extensions, not active agents

In these contexts, removing server-initiated communication:

• Weakens the ability to design cohesive, thoughtful flows
• Forces reactive, polling-based systems where proactive engagement once worked
• Makes it harder to build human-centered, context-sensitive tools

---

Proposal
Could MCP reintroduce a standardized way to push server-initiated instructions to clients?

Some options:

• Re-allow SSE optionally (even just event: instruction)
• Support WebSockets or long polling as pluggable transports
• Define a client/pollInstructions pattern with stronger hooks

---

Closing
This post is meant to highlight what we lost when server-initiated messaging was deprecated — not just technically, but architecturally and creatively. If MCP wants to support the broadest range of human-AI collaboration patterns, this is one worth revisiting.

Thanks for considering — and happy to co-write a proposal if this gains traction.

[hesreallyhim]

@Mookse Would "resources/changed" notifications/subscriptions work for you? If so, the problem is that this needs better client support, but you can still have server send push notifications to client, once the client subscribes to the resourceChanged events.

[hesreallyhim]

i don't want to get mixed up on language but, for one thing:

Each have the right to refuse a request

If you mean Request in the sense of the mcp protocol/JSON-RPC, then that's inaccurate, the server/receiver of a Reqest MUST respond. That's a major difference with Notification - server MUST NOT respond.

And I haven't peeked at that spec yet, but I'm assuming this is "choice" the client needs to make, and it's not part of the initialize protocol? (I.e. fine if client doesn't support, the universe is large -- it's that it is dependent on the client to initiate independently, correct?)

(i) regarding resource-changed subscriptions, it's all application-specific who's gonna do what; (ii) per the spec, server SHOULD but may simply ignore the client's notification to subscribe to a resource; (iii) announcing the capability is part of the initialize response, under "resources", there's "listChanged", and "subscribe" (I think those are the keys), but even so, a lazy server could still just ignore the notification (per the protocol).

it is dependent on the client to initiate independently, correct

The client has to send a notification that it wants to subscribe to changes. Also, the message flow is a little awkward IMO, because the design is that if the server supports this, then when the resource changes, it's just "supposed" to notify the client that it changes, then the client has to send another read request to actually see what changed - I think there's workarounds for this, but that's non-optimal IMO.

I never worked with the kind of functionality you're describing (never built an SSE server), so not sure if this is good enough for you, but I think this has a lot of potential (except so little support right now).

See here for a naive POC of what I'm describing: https://github.com/hesreallyhim/mcp-observer-server

[Mookse]

Yes, thank you @hesreallyhim I was most certainly collapsing ideology with functional protocol and expectation: let me briefly explain, and I think we are on the same page, I greatly appreciate your ability to parse out these distinctions immediately, at certain layers of engineering I get sloppy ("I'm only human" came the cry), and it is wonderful to have clarity drawn from my obscurity.

If you mean Request in the sense of the mcp protocol/JSON-RPC, then that's inaccurate, the server/receiver of a Reqest MUST respond. That's a major difference with Notification - server MUST NOT respond.

• I didn't mean that when I wrote it and failed to realize the implications of my language. In our MyLife code, the server intelligently refusing a request means, for a RL example: Client requests via POST /message(s) with method chat, content "requesting" (from end-intelligence, currently presuming human) our server to write an essay on medieval agrarian society in Europe, it will deny the request by writing session flags etc, and creating a well-formed JSON-RPC message responding to the client, yadda, yadda, yadda. I'm keen to minimize ambiguity and misunderstanding, again thank you.

I'm glad your interpretation of part 2 regarding the spec, that dovetailed with my assumptions, thank you for saving me the trip. I'd rather err on that side I guess, as I'm old-dog with the game, but newbie in the arena.

Lastly, this was the first time I ever worked with SSE, and I find it cumbersome, limited and functionally as an engineering interface, it's severely problematic; I had issues with response format limitations and session management wing (easily overcome, at least in Koa-Session), but got past them in order to indulge in bidirectional communication which will be of great use to us, sampling (or the new elicitation?) per the use case above, Server "pulls" that trigger based on long-running (comparatively) intelligent sweeps of data.

My understanding (I've got a discussion flagged somewhere, I'll update when I can) is that the SSE is getting deprecated entirely, if not already soon, which is understandable due to its inclusion. The heart was in the right place, but requiring arteries AND veins is so counter to our modern coding experience, it couldn't defend itself adequately. Websockets were denied out-of-hand for "good reason," and I'm not a web-engineer (middleware app and data) to speak intelligently on it, but my understanding is that as a protocol it wasn't ubiquitous enough.

Again, thanks so much.

[hesreallyhim]

SSE is getting deprecated entirely, if not already soon, which is understandable due to its inclusion.

This is correct, the new protocol is StreamableHTTP, but tbh I didn't get very far with it because I think it's not fully adopted right now or fully implemented in FastMCP or python-sdk, maybe I'm just dumb.

It just happens that I spent a ton of time poring over the protocol/spec/JSON-RPC this week, cuz it's kind of interesting to me. But afaik, bi-directional communication is orthogonal to the transport layer, which is something that stood out to me when i saw the section on transport, it said basically "use stdio whenever you can," and it didn't list bi-directionality as a relevant factor. this might only be the case for a client-server running on the same machine, i'm not sure, but it says, e.g.:

In the stdio transport:

The client launches the MCP server as a subprocess.
The server reads JSON-RPC messages from its standard input (stdin) and sends messages to its standard output (stdout).

AND:

Transport layer
The transport layer handles the actual communication between clients and servers. MCP supports multiple transport mechanisms:

Stdio transport

Uses standard input/output for communication
Ideal for local processes
HTTP with SSE transport

Uses Server-Sent Events for server-to-client messages
HTTP POST for client-to-server messages
All transports use [JSON-RPC](https://www.jsonrpc.org/) 2.0 to exchange messages. See the [specification](https://modelcontextprotocol.io/specification) for detailed information about the Model Context Protocol message format.

so i think the issue is really more if you're communicating via a remote server - i've been building MCP's for myself on my machine, so stdio is the way to go for me so far, but the protocol itself says servers can send messages to clients once the initialization phase is over. But again I'm building little things for myself, probably StreamableHTTP is what you would use for a service.

[hesreallyhim]

https://modelcontextprotocol.io/docs/concepts/architecture#2-message-exchange

2. Message exchange
After initialization, the following patterns are supported:

Request-Response: Client or server sends requests, the other responds
Notifications: Either party sends one-way messages

[hesreallyhim]

if you find this stuff interesting and don't want to read the whole spec (they're not that long actually), i filed a BUG report yesterday about the protocol:

modelcontextprotocol/modelcontextprotocol#574

So, you're not the only one that uses these terms loosely sometimes.

[hesreallyhim]

Best practices
[​](https://modelcontextprotocol.io/docs/concepts/architecture#transport-selection)
Transport selection
Local communication

Use stdio transport for local processes
Efficient for same-machine communication
Simple process management
Remote communication

Use SSE for scenarios requiring HTTP compatibility
Consider security implications including authentication and authorization

yeah i think it's simple for me cuz i'm doing "same-machine communication"