Skip to content

Conversation

@madevoge
Copy link

@madevoge madevoge commented Mar 2, 2025

Motivation and Context

This formalized transport proposal aims to optimize Server to Server communication (hosted clients), focused on long-running sessions and operations.

To make MCP work for long running tasks like deep analysis, this proposal defines a transport that leverages http webhooks and callbacks for bidirectionality.

So whilst the SSE transport enables remote servers, a webhook based approach enables remoteness without the need of long-lived open socket connections.

As an extension of this transport, we could introduce an (optional) SSE endpoint to enable message streaming for reduced latency. However, it is critical to not bind the lifetime of the session to this request lifetime.

This transport ensures that the full feature set of MCP remains functional, whilst allowing servers to leverage short lived http connections.

How Has This Been Tested?

The proposed transport has been implemented and validated as a custom transport.

We aim to bring this proposal to see whether there is enough value and consensus to uplift the transport from a custom transport to a standard, given the integration patterns it unlocks.

Breaking Changes

Additive change - new transport

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

This transport proposal aims to optimize Server to Server communication (hosted clients), especially around long-running sessions and operations.

To make MCP work for long running tasks like deep analysis, this proposal defines a transport that leverages http webhooks for bidirectionality.

So whilst the SSE transport enables remote servers, a webhook based approach enables remoteness without the need of long-lived open socket connections.

As an extension of this transport, we could introduce an (optional) SSE endpoint for message streaming for reduced latency. However, it is critical to not bind the lifetime of the session to the request lifetime.
@jspahrsummers
Copy link
Member

We really want to avoid a proliferation of different official transports, as each new transport multiplies the overall compatibility matrix and makes the ecosystem more complex.

We have a forthcoming proposal that should simplify + replace the SSE transport, while also addressing the concerns here, so I'll go ahead and close this.

I want to thank you for writing this up, though! Really appreciate the time you've put in here. 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

No open projects
Status: Rejected

Development

Successfully merging this pull request may close these issues.

3 participants