streamable server support

[stallent]

So now that we have the client working pretty well with the latest streamable http spec, i'm starting to work on upgrading our servers to support the server side of said spec.

I believe we may have a design issue, or maybe (hopefully) i'm missing something. The current design of the client->transport ->->-> a server works fine because typically a client app would have a single instance of a client (per server to connect to). That coupling becomes an issue on the server side, though. A server needs to allow more than one client to connect to it, and then any given client needs to be able to have multiple connections open within its session.

I've been studying the official TS streamable server code and of course while the syntax will be vastly different, i think i have a handle on the direction we need to go to do it properly. Basically, the server needs to allow multiple transports to be added (vs just one like it is currently). Each connection from a client would create a new transport which would be added to the server for that session. The GETs (which are all just one direction, server->client) would sit in there and all general messages would get written to all of them. The POSTs would also add their own transports to that session's server, but they would be shorter lived and let the server write to just that one transport, identified by the incoming id of the POST request. The spec explicitly states a client can have mutliple connections open so while we don't necessarily have to match the exact approach of the TS implementation, we must do something at least remotely similar.

Have you given this area much thought and if so, what are the thoughts? If not, I may go ahead and work on a POC in my fork

[mattt]

Hi @stallent. Thanks for giving this some thought.

My mental model is that server transport will manage a pool of connections to one or more clients. The specific implementation of that transport will depend on which web framework you build on top of. But at a high-level, it should look similar to this Swift NIO example chat server, where you have a dictionary of channels by client ID.

Does that track for you?

[stallent]

Partially. I think my struggles with that approach is you now have to maintain a fully functioning HTTP Server in front of it. Is that something that is within the scope or purview of this framework? I have a hunch devs wanting to deploy Swift servers are gonna prefer to go with the Vapor/Hummingbird frameworks where they already have all the things needed for HTTP (auth, sessions, persistence, middleware blah blah blah). Our are all containerized Hummingbird servers deployed to various clouds and k8 clusters

[mattt]

@stallent Yeah, I think that's correct. Instead of pulling in Vapor or Hummingbird into this SDK, you'd install a hummingbird-mcp or vapor-mcp package, which would provide a transport and APIs to mount MCP servers at a particular route.

[stallent]

Correct. In fact, creating a mcp-hummingbird is exactly what i was going to do. But i think we would require some changes to the Server regardless, though. Either the server needs allow multiple transports, or we need to be able to inject some state into the server (the latter would be so we can have a server/transport per connection, but don't wanna re-init each server). Several ways to skin that cat, so to speak, but i believe changes in the server class will be required regardless.

[stallent]

i'll proceed with a POC on a fork for us to look at and assess. Won't open a PR or anything.

[mattt]

@stallent Sounds good! Excited to see what you come up with.

[stallent]

making solid progress. should have POS POC up tomorrow at some point

[stallent]

Alright. I have something minimal to look at that supports the streamable server spec and hopefully spurs discussion.

I used the official TS server and transport code as an implementation guide so my code somewhat mimics that. Its worth noting that the TS client puts a lot more of the mcp types and knowledge in the transport vs being exclusively in the server. To mimic that for the moment i had to add some redundant json decoding in the transport. Figured i'd start with that vs making larger changes to the Server class.

The changes to the swift-sdk are in the streamable_server branch of my fork here:
https://github.com/stallent/swift-sdk/tree/streamable_server

with the specific changes being this commit:
stallent@164ec48

The Hummingbird part isn't yet in a re-usable package for and at the moment, but otherwise should illustrate full usage.
https://github.com/stallent/hummingbird-mcp