Update send_notification method to properly construct JSON-RPC notification objects with jsonrpc version and method fields.
This ensures notifications conform to the JSON-RPC 2.0 specification when sent over HTTP transport.
https://www.jsonrpc.org/specification#notification
Another goal is to standardise the `send_notification` interface.
Before the revision, it was sufficient to pass the method and parameters in the case of stdio.
However, in the case of Streamable, a hash based on the JSON-RPC specification must be passed.
Currently, MCP has three versions: 2024-11-05, 2025-03-26, and 2025-06-18.
- https://modelcontextprotocol.io/specification/2024-11-05/basic/transports (stdio and HTTP with SSE)
- https://modelcontextprotocol.io/specification/2025-03-26/basic/transports (stdio and Streamable HTTP)
- https://modelcontextprotocol.io/specification/2025-06-18/basic/transports (stdio and Streamable HTTP)
The newer specification supports stdio and Streamable HTTP as transport mechanisms.
Only the oldest version, 2024-11-05, supports stdin and HTTP with SSE,
but that version is now considered legacy.
Given the current behavior of the Ruby SDK, it likely makes more sense to set
the default protocol version to the latest one, 2025-06-18, rather than the oldest, 2024-11-05.
Ideally, the implementation should adjust its behavior based on the version,
but this PR is limited to updating the default protocol version only.
## Motivation and Context
Currently, MCP supports the following three protocol versions:
"2025-06-18", "2025-03-26", and "2024-11-05".
https://modelcontextprotocol.io/introduction
As shown in the changes to `test/mcp/configuration_test.rb`,
the `protocol_version` value is not currently being validated,
which allows unexpected `protocol_version` values to be accepted.
This PR ensures that only supported protocol versions are accepted.
## How Has This Been Tested?
Existing tests have been updated and new tests have been added.
## Breaking Changes
None. If it becomes an issue, it means a value that was not originally intended has been used.
## Additional context
While one possible approach might be to fall back to a default protocol version
when an invalid `protocol_version` value is provided,
this PR opts to reject invalid `protocol_version` values explicitly.
The reasoning is that encouraging users to provide intentional,
valid input is preferable to silently falling back to a default,
which could lead to unexpected behavior.
`handle_request` already adds the `method` to the instrumentation data,
so there is no need to repeat this. Moreover, consumers can override
these anyway.
The reason for the change is that a NameError occurs when a POST request is made while the stream is closed because ModelContextProtocol is undefined.
I have also added test cases to check the behaviour when IOError and Errno::EPIPE occurs.
- Updated `call` method in `MCP::Tool` and `MCP::Prompt` to accept `server_context` as an optional parameter.
- Refactored `MCP::Server` to streamline argument handling for tool and prompt calls, introducing helper methods `call_tool_with_args` and `call_prompt_template_with_args`.
- Adjusted tests to reflect changes in method signatures and ensure compatibility with optional `server_context` parameter.
Follow-up to #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_transport"` 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#50.
This PR suppresses the following backtrace of `Interrupt` (Ctrl+c) exception for stdio server:
## Before
```console
$ ./examples/stdio_server.rb
^C/Users/koic/src/github.com/modelcontextprotocol/ruby-sdk/lib/mcp/server/transports/stdio_transport.rb:20:
in 'IO#gets': Interrupt
from /Users/koic/src/github.com/modelcontextprotocol/ruby-sdk/lib/mcp/server/transports/stdio_transport.rb:20:
in 'MCP::Server::Transports::StdioTransport#open'
from ./examples/stdio_server.rb:95:in '<main>'
$ echo $?
130
```
## After
```console
$ ./examples/stdio_server.rb
^C
Exiting...
$ echo $?
130
```
This change should prevent unexpected backtrace from appearing when running the example:
https://github.com/modelcontextprotocol/ruby-sdk?tab=readme-ov-file#stdio-transport
Refactor capabilities handling into MCP::Server::Capabilities to improve
code organization and separation of concerns. This provides a cleaner API
for configuring server capabilities including prompts, resources, tools,
completions, logging, and experimental features.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Follow-up to #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 #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.
