Description:

The current implementation of MCP's remote invocation only supports Server-Sent Events (SSE) for communication, which is suboptimal. When the MCP client calls the MCP server, it sends an HTTP request to the server, which merely echoes the request back. The actual response to the client is then delivered via an SSE channel to the frontend.

This approach has several drawbacks:

Redundant Overhead: The initial HTTP request from the client to the server is redundant because the server does not process the request meaningfully—it merely forwards it.
Connection Maintenance: Maintaining SSE connections requires the server to keep connections open indefinitely until they are closed by the client, which introduces unnecessary complexity and resource usage.
Non-Elegant Design: The current pattern effectively acts as an indirect request-response mechanism, where the server delegates the response to the client via SSE. This deviates from a standard request-response workflow, complicating both client and server logic.

Proposal:

I recommend adopting a direct request-response pattern for MCP's remote invocations. This would:

Eliminate redundant HTTP requests and SSE-based round-trips.
Simplify the communication flow by allowing the server to process and respond directly to the client's request in a single interaction.
Preserve SSE's benefits (e.g., real-time updates) for scenarios where subscriptions or asynchronous notifications are required, while separating them from core request-response workflows.
Key Rationale:

The current design forces the client to act as an intermediary for responses, which is inefficient. A traditional request-response model would streamline interactions, reduce latency, and align with standard API best practices. SSE can still be used for its intended purpose—pushing real-time updates—without conflating it with basic request handling.