Add SSEEdgeTransport

[imownbey]

Adds a transport which can be used in environments like Vercel and Cloudflare Workers. I called this SSEEdgeTransport but imagine there is some better naming.

I also added documentation to the readme on how to use it (with Hono which is a popular web framework for Cloudflare) and a section on using it with Cloudflare Durable Objects to keep track of different servers.

Motivation and Context

The current documentation & transport only really work with Node or Express which is pretty limiting in my experience. I think Durable Objects offer a viable quick way to get something spun up, and regardless a Transport which works in Edge environments is useful.

How Has This Been Tested?

Ran locally, deployed to cloudflare and tested with Cursor and a basic MCP Server (the greeting one).

I didn't test disconnects too much because I am not super familiar with MCP's reconnection protocol. But assuming the client keeps sending the same SessionID it will get directed to the same Durable Object (as described in the README, this is independent of the actual code change).

Breaking Changes

None

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

[stonega]

The doc is not correct here, maybe we need to pass c(Context) to handlePostMessage?

[imownbey]

Oh yeah you are correct! Will fix

[imownbey]

Since testing this over a long amount of time I have discovered that the DO implementation breaks due to timeouts. Do MCP clients have a concept of reconnect? Is there something I need to implement in my transport? Right now Cursor just assumes the server is down and never tries again (although maybe that is a cursor problem?).

Sadly CF's story for SSE is not great.

[geelen]

I've been playing with SSE over DO (based on this transport, thank you for pushing it!) and reconnection is definitely an issue, not just for Cloudflare/DO and SSE but any remote server talking SSE or WS. It might happen more often on CF due to our architecture but connections will drop, and Cursor (or any client) needs to reestablish them.

I think a sessionId query param should be added to the spec for SSE/WS but actually, once clients support authentication, we can actually use the information encoded in the auth_token as a stopgap:

const app = new Hono();
app.all('*', async (c) => {
	const userJwt = decodeTokenIfPresent(c.req.header('Authorization'))
	const sessionId = c.req.query('sessionId')
	const ns = c.env.MCP_OBJECT
	const doId = sessionId ? ns.idFromString(sessionId) : userJwt ? ns.idFromString(userJwt.userId) : ns.newUniqueId()
	return object.fetch(c.req.raw);
});

The exact strategy depends on the kinds of auth tokens you're issuing but thankfully that's all internal to the server, so you can make that consistent with the way you're addressing the DOs (one DO per user might be fine, for example).

[geelen]

Oh! Just saw #158 has been merged and released in 1.7.0. So hopefully we'll be able to rely on sessionID being present in all cases to resume connections.

[gching]

Might be unrelated, but I've been using WS on Cloudflare Workers for my users without much hassle and haven't heard too many complaints. Not saying we shouldn't do SSE with CF/DO, but might just much more simpler to support WS for edge as its been working for me

EDIT: If theres enough interest, I can push up my Transport either here or in another repo

[QuantGeekDev]

Might be unrelated, but I've been using WS on Cloudflare Workers for my users without much hassle and haven't heard too many complaints. Not saying we shouldn't do SSE with CF/DO, but might just much more simpler to support WS for edge as its been working for me

EDIT: If theres enough interest, I can push up my Transport either here or in another repo

Please push it. I've been "wrangling" cloudflare workers for a day trying to find a workaround. WS makes sense. Would love to see your take on its implementation

[jspahrsummers]

We'd prefer to focus efforts on the new Streamable HTTP transport in the SDK going forward.