Larry Maccherone

I am willing to take a stab at drafting one. I have a reference implementation in the works so I can draw from that learning.

Question for everyone on this thread... @crholm's original suggestion was for both **Websockets for full-duplex communication** and **Simple HTTP request/response for stateless operations**. I'm working on the draft SEP right...

OK. Here it is: https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1288 Please provide feedback either to the PR review (if you have that permission) or comments here, to the PR, or the issue. Not sure which...

Whoops, I thought my branch merge was from different branches in my own PR. I did not intend to try to merge this into the main for this project. Apologies.

@Kludex, we are down to a few design decisions that interplay: a) Envelope or not? b) Cookies or not? c) Server or client generates the mcpSessionId. Here are the options...

I have some time today. I'm going to move forward with creating a reference implementation based upon Option 1.

Some learning, but not good news. We cannot smuggle the mcpSessionId back on the subprotocol response. It works in some browsers but not in Node.js or Chrome. This leaves us...

OK. That's super helpful. I'm wondering if you would be open to a phone call to discuss MCP sessions with me wrt to WebSockets. I would prefer to have a...

I like this concept, but I recommend it use [RFC-7396 JSON Merge Patch](https://datatracker.ietf.org/doc/html/rfc7396) rather than [RFC-6902 JSON Patch](http://tools.ietf.org/html/rfc6902) that fast-json-patch implements for several reasons: 1. JSON Merge Patch is simplier...