Add streamable HTTP transport for clients #70
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mattt
force-pushed
the
mattt/streamable-http-client
branch
from
519020b to
b3a3119
Compare
mattt
force-pushed
the
mattt/streamable-http-client
branch
from
8a241f8 to
593985a
Compare
mattt
force-pushed
the
mattt/streamable-http-client
branch
from
593985a to
55ab96d
Compare
github-project-automation
bot
moved this from In Progress
to Done
in 2025-03-26 Implementation
This was referenced Apr 15, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #20
https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http
Whereas stdio transport is symmetrical between client and server, streamable HTTP transport has very different requirements for each. It's fairly straightforward to implement HTTP client transport in Swift using Foundation networking (
URLSession). That's what this PR does.It's another thing entirely to implement HTTP server transport. Most paths to getting Swift on Server involve pulling in SwiftNIO as a dependency. SwiftNIO itself is too low-level to be used on its own, and requires either implementing a nontrivial amount of server logic or pulling in an additional dependency, like Hummingbird or Vapor.
I suspect that the vast majority of developers using this SDK are interested in connecting to remote MCP servers from their app. And among those who do want to run an MCP server in Swift, I suspect many would do so as a form of inter-process communication for an app (like iMCP) — in which case, the existing
NetworkTransportis sufficient. If we're prioritizing these use cases, it's hard to justify the cost of pulling in something on the order of a thousand additional Swift files from a dozen external packages for every installation.So for now, let's start with HTTP streaming transport for clients. If you have ideas for what we can or should do about server transport, please open a new issue — I'd love to hear what you think.