ruby-sdk/lib/mcp/server/transports/stdio_transport.rb
Koichi ITO a97e391353 Support notifications/cancelled per MCP specification
## Motivation and Context

The MCP specification defines `notifications/cancelled` so either party can stop
a previously-issued in-flight request. The Ruby SDK declared the method constant
but had no receive logic, no in-flight tracking, and no way for handlers to participate
in cancellation; cancellation notifications fell through to the unsupported-method path.

This PR implements the **server-side** half of the spec. The server stops processing
the targeted request cooperatively and suppresses its JSON-RPC response, matching
the Python SDK's anyio `CancelScope` and the TypeScript SDK's `RequestHandlerExtra.signal`.
Cancellation is observable by every user-overridable request handler:

- `Tool.call` (tools/call)
- prompt templates (prompts/get)
- blocks registered via `resources_read_handler` / `completion_handler` /
  `resources_subscribe_handler` / `resources_unsubscribe_handler` / `define_custom_method`

Each handler opts in by declaring a `server_context:` keyword and polls `server_context.cancelled?`
or calls `server_context.raise_if_cancelled!` (raising `MCP::CancelledError`) inside long-running work.
Handlers that keep their existing `|params|` (or `|args|`) signature continue to work unchanged.

On `StreamableHTTPTransport`, cancelling a parent `tools/call` automatically cancels n
ested server-to-client requests (`sampling/createMessage`, `elicitation/create`);
the nested `send_request` raises `MCP::CancelledError` and a cancel notification is routed to
the peer on the parent's POST response stream. `StdioTransport` is single-threaded and blocks on `$stdin.gets`,
so it deliberately does not propagate nested cancellation.
Tools running on stdio still observe cancellation between calls via `server_context.cancelled?`.

The design is cooperative-only (no `Thread#raise`) because preemptive cancellation is unsafe
across Rack adapters and arbitrary handler code. The `initialize` request is never cancellable,
satisfying the spec rule that it MUST NOT be cancelled. Unknown / completed / duplicate cancel notifications
are silently ignored per the spec.

`MCP::Client#cancel` (an equivalent that aborts the calling thread's synchronous wait) is deferred to a follow-up PR.

Ref: https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/cancellation

## How Has This Been Tested?

`test/mcp/cancellation_test.rb` covers the `MCP::Cancellation` token contract.

`test/mcp/server_cancellation_test.rb` covers end-to-end cancellation:

- A handler spins on `cancelled?` in a background thread; the test sends `notifications/cancelled`
  and asserts the handler observed cancellation and the JSON-RPC response was suppressed.
  Each user-overridable handler type (tool, prompt template, resources/read, completion, custom method)
  has its own regression test.
- `initialize` is not cancellable; unknown / duplicate / late-after-completion cancels are silently ignored.
- The `reason` propagates into the `cancellation_reason` instrumentation field.
- Custom transports implementing only the abstract `(method, params = nil)` contract keep working;
  the new kwargs (`session_id:`, `related_request_id:`, `parent_cancellation:`, `server_session:`)
  are silently dropped when the transport's signature does not declare them.

`StreamableHTTPTransport` tests cover nested cancellation, hook deregistration after normal completion
(so a late parent cancel does not emit a stray `notifications/cancelled`), and the first-writer-wins race
when a real response and a cancel arrive concurrently.

## Breaking Change

None. `MCP::ServerContext#initialize` gains an optional `cancellation:` keyword (defaults to `nil`),
and `StreamableHTTPTransport#send_request` / `#send_notification` gain optional cancellation kwargs.
The abstract `Transport` base class and `StdioTransport` keep their existing `(method, params = nil)` signatures,
and custom transports following those signatures continue to work. `StreamableHTTPTransport` now dispatches
client-originated notifications through `ServerSession#handle_json` before returning 202;
previously these were accepted without dispatch, but the existing handlers for `notifications/initialized`
and `notifications/progress` were already no-ops, so no user-visible effect is expected.
Adding `server_context:` to a handler block is strictly opt-in.
2026-05-03 04:02:22 +09:00

101 lines
3.4 KiB
Ruby

# frozen_string_literal: true
require "json"
require_relative "../../transport"
module MCP
class Server
module Transports
class StdioTransport < Transport
STATUS_INTERRUPTED = Signal.list["INT"] + 128
def initialize(server)
super(server)
@open = false
@session = nil
$stdin.set_encoding("UTF-8")
$stdout.set_encoding("UTF-8")
end
def open
@open = true
@session = ServerSession.new(server: @server, transport: self)
while @open && (line = $stdin.gets)
response = @session.handle_json(line.strip)
send_response(response) if response
end
rescue Interrupt
warn("\nExiting...")
exit(STATUS_INTERRUPTED)
end
def close
@open = false
end
def send_response(message)
json_message = message.is_a?(String) ? message : JSON.generate(message)
$stdout.puts(json_message)
$stdout.flush
end
def send_notification(method, params = nil)
notification = {
jsonrpc: "2.0",
method: method,
}
notification[:params] = params if params
send_response(notification)
true
rescue => e
MCP.configuration.exception_reporter.call(e, { error: "Failed to send notification" })
false
end
# NOTE: This signature deliberately matches the abstract `Transport#send_request` contract
# (`method, params = nil`) without the cancellation kwargs that `StreamableHTTPTransport#send_request` accepts.
# On Ruby 2.7 the project's supported minimum a method that mixes a positional `params` Hash with
# explicit keyword arguments cannot be called as `send_request(method, { ... })` - the trailing Hash would be
# auto-promoted to keyword arguments. Stdio is single-threaded and blocks on `$stdin.gets`, so nested-request
# cancellation has very limited value here regardless; servers that need cancellation propagation for nested
# server-to-client requests should use `StreamableHTTPTransport`.
def send_request(method, params = nil)
request_id = generate_request_id
request = { jsonrpc: "2.0", id: request_id, method: method }
request[:params] = params if params
begin
send_response(request)
rescue => e
MCP.configuration.exception_reporter.call(e, { error: "Failed to send request" })
raise
end
while @open && (line = $stdin.gets)
begin
parsed = JSON.parse(line.strip, symbolize_names: true)
rescue JSON::ParserError => e
MCP.configuration.exception_reporter.call(e, { error: "Failed to parse response" })
raise
end
if parsed[:id] == request_id && !parsed.key?(:method)
if parsed[:error]
raise StandardError, "Client returned an error for #{method} request (code: #{parsed[:error][:code]}): #{parsed[:error][:message]}"
end
return parsed[:result]
else
response = @session ? @session.handle(parsed) : @server.handle(parsed)
send_response(response) if response
end
end
raise "Transport closed while waiting for response to #{method} request."
end
end
end
end
end