Add support for SSE

[elizabetht]

Describe the feature or problem you’d like to solve

As part of building interactive and responsive developer tools on top of the MCP server, we have a need to expose HTTP endpoints that can stream data incrementally to clients using Server-Sent Events (SSE). This is particularly useful for use cases like:

• Real-time progress updates for long-running tool executions
• Streaming logs or partial results as they become available
• Event-driven workflows triggered by tools or models

However, the current MCP server does not appear to support SSE-style HTTP streaming out of the box. Since SSE relies on keeping an HTTP connection open and continuously pushing updates using the text/event-stream content type, it requires explicit support at the server level to manage connection lifecycle and event formatting.

Without native support, it's challenging to build streaming, real-time experiences using MCP — which limits the kind of rich developer tools and UIs that can be built on top of it.

Proposed solution

Adding SSE support would unlock:

• Real-time user experiences (e.g., showing partial results or live updates)
• Streaming logs or status updates for tool execution
• Lower latency responses without requiring polling
• Simplified client-side implementations using native browser support (vs. websockets)

Additional context

SSE support would:

• Enhance Developer Experience: Provide users with more flexibility to build real-time tools or dashboards powered by MCP.
• Broaden Adoption: Many organizations have frontends or APIs that rely on streaming capabilities — this would make MCP compatible with those out-of-the-box.
• Improve Integration with AI/LLM Tooling: LLM-related use cases often benefit from streamed outputs (like token-by-token streaming) — SSE is ideal for that.
• Align with Open Standards: SSE is supported in most browsers and backend frameworks, making it easier to integrate across diverse ecosystems.
• Encourage Community Contributions: Clear extensibility via streaming would likely attract more usage and contributions in tool/plugin scenarios.

[elizabetht]

May be similar to #2?

[tonytrg]

cc @omgitsads