Refactor in preparation for client support #27
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
|
Oops, forgot to move tests |
jcat4
changed the title
|
resolving merge conflicts 😰 |
jcat4
force-pushed
the
refactor-for-client-support
branch
from
2e101fd to
ea7a23e
Compare
jcat4
force-pushed
the
refactor-for-client-support
branch
from
ea7a23e to
d80b137
Compare
topherbullock
previously approved these changes
May 30, 2025
|
This has some changes that will cause conflicts for #33. Not to imply the structure I have there should be the one we use going forward, but this PR is moving around the folder where transport implementations reside. We'll need to stick to one layout or the other. No strong opinions, and feel this decision is best made by @topherbullock and @atesgoral. |
topherbullock
approved these changes
Jun 1, 2025
the gem need to implement StreamableHTTP, stdio, and any other transports for both client and server, so splitting out into |
|
Makes sense to me! I didn't realized prior to my comment that this was fulfilling this issue ❤️ |
koic
added a commit
to koic/ruby-sdk
that referenced
this pull request
Jun 4, 2025
Follow-up to modelcontextprotocol#27. This PR fixes the following build error: ```console $ bundle exec rake /Users/koic/.rbenv/versions/3.5-dev/lib/ruby/3.5.0+1/bundled_gems.rb:59:in 'Kernel.require': cannot load such file -- mcp/transports/stdio (LoadError) Did you mean? mcp/transports/stdio_transport_test from /Users/koic/.rbenv/versions/3.5-dev/lib/ruby/3.5.0+1/bundled_gems.rb:59:in 'block (2 levels) in Kernel#replace_require' from /Users/koic/src/github.com/modelcontextprotocol/ruby-sdk/test/mcp/transports/stdio_transport_test.rb:4:in '<top (required)>' from /Users/koic/.rbenv/versions/3.5-dev/lib/ruby/3.5.0+1/bundled_gems.rb:59:in 'Kernel.require' from /Users/koic/.rbenv/versions/3.5-dev/lib/ruby/3.5.0+1/bundled_gems.rb:59:in 'block (2 levels) in Kernel#replace_require' from /Users/koic/.rbenv/versions/3.5-dev/lib/ruby/gems/3.5.0+1/gems/rake-13.3.0/lib/rake/rake_test_loader.rb:21:in 'block in <main>' from /Users/koic/.rbenv/versions/3.5-dev/lib/ruby/gems/3.5.0+1/gems/rake-13.3.0/lib/rake/rake_test_loader.rb:6:in 'Array#select' from /Users/koic/.rbenv/versions/3.5-dev/lib/ruby/gems/3.5.0+1/gems/rake-13.3.0/lib/rake/rake_test_loader.rb:6:in '<main>' rake aborted! Command failed with status (1) /Users/koic/.rbenv/versions/3.5-dev/bin/bundle:25:in 'Kernel#load' /Users/koic/.rbenv/versions/3.5-dev/bin/bundle:25:in '<main>' Tasks: TOP => default => test (See full trace by running task with --trace) ``` https://github.com/modelcontextprotocol/ruby-sdk/actions/runs/15428236624/job/43420346011 The following is stated in modelcontextprotocol#27. > Breaking Changes > `MCP::Transports::StdioTransport` is now `MCP::Server::Transports::StdioTransport` What is shown here is the new name `MCP::Server::Transports::StdioTransport`, not `MCP::Server::Transports::Stdio`. Therefore, the file path has been updated from `lib/mcp/server/transports/stdio.rb` to `lib/mcp/server/transports/stdio_transport.rb` to match the module name. If `MCP::Server::Transports::Stdio` is preferred instead, please let me know and I will open a separate PR.
koic
added a commit
to koic/ruby-sdk
that referenced
this pull request
Jun 8, 2025
Follow-up to modelcontextprotocol#27. This PR adds a migration path for `Server::Transports::StdioTransport`. e.g., ```console $ cat /tmp/example.rb require "mcp/transports/stdio" MCP::Transports::StdioTransport ``` This change displays the following warning instead of raising an error for such cases, allowing execution to proceed: ```console $ bundle exec ruby /tmp/example.rb /tmp/example.rb:1: warning: Use `require "mcp/server/transports/stdio"` instead of `require "mcp/transports/stdio"`. Also use `MCP::Server::Transports::StdioTransport` instead of `MCP::Transports::StdioTransport`. This API is deprecated and will be removed in a future release. ``` Currently (v0.1.0), it results in an error without any warning. This MCP gem is not yet close to version 1.0, but introducing breaking changes to a published interface is undesirable. This compatibility code should be removed at some point after a few releases. Closes modelcontextprotocol#50.
9 tasks
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.
Motivation and Context
We want to implement client support for this lib. Currently, all the code isn't clearly organized between shared and server-specific code. To be more inline with other sdk's, I've organized the code into /server and /shared dirs.
Now we can relatively easily add a new /client dir and implement client support there.
How Has This Been Tested?
We tested on one of our internal applications, which has an MCP server. We used it from cursor using this version, and everything works just fine.
Breaking Changes
MCP::Transports::StdioTransportis nowMCP::Server::Transports::StdioTransportTypes of changes
Checklist
Additional context
1.0.0-previewappropriate? I was thinking the official1.0.0could be reserved for the client support. Or this could be1.0.0and the client support can be1.1.0? Since there are technically breaking changes, I don't want to do a minor bump.