mcp 0.8.0 → 0.9.0

data/CHANGELOG.md

@@ -1,168 +0,0 @@
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
-and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
-
-## [Unreleased]
-
-## [0.8.0] - 2026-03-03
-
-### Added
-
-- `Content::EmbeddedResource` class for embedded resource content type (#244)
-- `Content::Audio` class for audio content type (#243)
-- `$ref` support in `Tool::Schema` for protocol version 2025-11-25 (#242)
-- MCP conformance test suite (#248)
-
-### Fixed
-
-- Handle `Errno::ECONNRESET` in SSE stream operations (#249)
-- Fix default handler return values to comply with MCP spec (#247)
-- Fix `Prompt#validate_arguments!` crash when arguments are `nil` (#246)
-- Return 202 Accepted for SSE responses per MCP spec (#245)
-- Fix `Content::Image#to_h` to return `mimeType` (camelCase) per MCP spec (#241)
-
-## [0.7.1] - 2026-02-21
-
-### Fixed
-
-- Fix `Resource::Contents#to_h` to use correct property names per MCP spec (#235)
-- Return JSON-RPC protocol errors for unknown tool calls (#231)
-- Fix `logging/setLevel` to return empty hash per MCP specification (#230)
-
-## [0.7.0] - 2026-02-14
-
-### Added
-
-- `logging` support (#103)
-- Protocol version negotiation to server initialization (#223)
-- Tool arguments to instrumentation data (#218)
-- Client info to instrumentation callback (#221)
-- `resource_templates` to `MCP::Client` (#225)
-
-### Changed
-
-- Extract `MCP::Annotations` into a dedicated file (#224)
-
-### Fixed
-
-- `Resource::Embedded` not setting `@resource` in `initialize` (#220)
-
-## [0.6.0] - 2026-01-16
-
-### Changed
-
-- Update licensing to Apache 2.0 for new contributions (#213)
-
-### Fixed
-
-- Omit `icons` from responses when empty or nil to reduce context window usage (#212)
-
-## [0.5.0] - 2026-01-11
-
-### Added
-
-- Protocol specification version "2025-11-25" support (#184)
-- `icons` parameter support (#205)
-- `websiteUrl` parameter in `serverInfo` (#188)
-- `description` parameter in `serverInfo` (#201)
-- `additionalProperties` support for schema validation (#198)
-- "Draft" protocol version to supported versions (#179)
-- `stateless` mode for high availability (#101)
-- Exception messages for tool call errors (#194)
-- Elicitation skeleton (#178)
-- `prompts/list` and `prompts/get` support to client (#163)
-- Accept header validation for HTTP client transport (#207)
-- Ruby 2.7 - Ruby 3.1 support (#206)
-
-### Changed
-
-- Make tool names stricter (#204)
-
-### Fixed
-
-- Symlink path comparison in schema validation (#193)
-- Duplicate tool names across namespaces now raise an error (#199)
-- Tool error handling to follow MCP spec (#165)
-- XSS vulnerability in json_rpc_handler (#175)
-
-## [0.4.0] - 2025-10-15
-
-### Added
-
-- Client resources support with `resources/list` and `resources/read` methods (#160)
-- `_meta` field support for Tool schema (#124)
-- `_meta` field support for Prompt
-- `title` field support for prompt arguments
-- `call_tool_raw` method to client for accessing full tool responses (#149)
-- Structured content support in tool responses (#147)
-- AGENTS.md development guidance documentation (#134)
-- Dependabot configuration for automated dependency updates (#138)
-
-### Changed
-
-- Set default `content` to empty array instead of `nil` (#150)
-- Improved prompt spec compliance (#153)
-- Allow output schema to be array of objects (#144)
-- Return 202 response code for accepted JSON-RPC notifications (#114)
-- Added validation to `MCP::Configuration` setters (#145)
-- Updated metaschema URI format for cross-OS compatibility
-
-### Fixed
-
-- Client tools functionality and test coverage (#166)
-- Client resources test for empty responses (#162)
-- Documentation typos and incorrect examples (#157, #146)
-- Removed redundant transport requires (#154)
-- Cleaned up unused block parameters and magic comments
-
-## [0.3.0] - 2025-09-14
-
-### Added
-
-- Tool output schema support with comprehensive validation (#122)
-- HTTP client transport layer for MCP clients (#28)
-- Tool annotations validation for protocol compatibility (#122)
-- Server instructions support (#87)
-- Title support in server info (#119)
-- Default values for tool annotation hints (#118)
-- Notifications/initialized method implementation (#84)
-
-### Changed
-
-- Make default protocol version the latest specification version (#83)
-- Protocol version validation to ensure valid values (#80)
-- Improved tool handling for tools with no arguments (#85, #86)
-- Better error handling and response API (#109)
-
-### Fixed
-
-- JSON-RPC notification format in Streamable HTTP transport (#91)
-- Errors when title is not specified (#126)
-- Tools with missing arguments handling (#86)
-- Namespacing issues in README examples (#89)
-
-## [0.2.0] - 2025-07-15
-
-### Added
-
-- Custom methods support via `define_custom_method` (#75)
-- Streamable HTTP transport implementation (#33)
-- Tool argument validation against schemas (#43)
-
-### Changed
-
-- Server context is now optional for Tools and Prompts (#54)
-- Improved capability handling and removed automatic capability determination (#61, #63)
-- Refactored architecture in preparation for client support (#27)
-
-### Fixed
-
-- Input schema validation for schemas without required fields (#73)
-- Error handling when sending notifications (#70)
-
-## [0.1.0] - 2025-05-30
-
-Initial release in collaboration with Shopify

data/CODE_OF_CONDUCT.md

@@ -1,74 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, gender identity and expression, level of experience,
-nationality, personal appearance, race, religion, or sexual identity and
-orientation.
-
-## Our Standards
-
-Examples of behavior that contributes to creating a positive environment
-include:
-
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
-
-Examples of unacceptable behavior by participants include:
-
-* The use of sexualized language or imagery and unwelcome sexual attention or
-advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
-  address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-## Our Responsibilities
-
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
-
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
-
-## Scope
-
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an appointed
-representative at an online or offline event. Representation of a project may be
-further defined and clarified by project maintainers.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at topher.bullock@shopify.com. All
-complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at [http://contributor-covenant.org/version/1/4][version]
-
-[homepage]: http://contributor-covenant.org
-[version]: http://contributor-covenant.org/version/1/4/

data/Gemfile

@@ -1,29 +0,0 @@
-# frozen_string_literal: true
-
-source "https://rubygems.org"
-
-# Specify runtime dependencies in the gemspec
-gemspec
-
-# Specify development dependencies below
-gem "rubocop-minitest", require: false
-gem "rubocop-rake", require: false
-gem "rubocop-shopify", ">= 2.18", require: false if RUBY_VERSION >= "3.1"
-
-gem "puma", ">= 5.0.0"
-gem "rackup", ">= 2.1.0"
-
-gem "activesupport"
-# Fix io-console install error when Ruby 3.0.
-gem "debug" if RUBY_VERSION >= "3.1"
-gem "rake", "~> 13.0"
-gem "sorbet-static-and-runtime" if RUBY_VERSION >= "3.0"
-gem "yard", "~> 0.9"
-gem "yard-sorbet", "~> 0.9" if RUBY_VERSION >= "3.1"
-
-group :test do
-  gem "faraday", ">= 2.0"
-  gem "minitest", "~> 5.1", require: false
-  gem "mocha"
-  gem "webmock"
-end

data/RELEASE.md

@@ -1,12 +0,0 @@
-## Releases
-
-This gem is published to [RubyGems.org](https://rubygems.org/gems/mcp)
-
-Releases are triggered by PRs to the `main` branch updating the version number in `lib/mcp/version.rb`.
-
-1. **Update the version number** in `lib/mcp/version.rb`, following [semver](https://semver.org/)
-2. **Update CHANGELOG.md**, backfilling the changes since the last release if necessary, and adding a new section for the new version, clearing out the Unreleased section
-3. **Create a PR and get approval from a maintainer**
-4. **Merge your PR to the main branch** - This will automatically trigger the release workflow via GitHub Actions
-
-When changes are merged to the `main` branch, the GitHub Actions workflow (`.github/workflows/release.yml`) is triggered and the gem is published to RubyGems.

data/Rakefile

@@ -1,56 +0,0 @@
-# frozen_string_literal: true
-
-require "bundler/gem_tasks"
-require "rake/testtask"
-
-Rake::TestTask.new(:test) do |t|
-  t.ruby_opts = ["-W0", "-W:deprecated"]
-  t.libs << "test"
-  t.libs << "lib"
-  t.test_files = FileList["test/**/*_test.rb"]
-end
-
-require "rubocop/rake_task"
-
-RuboCop::RakeTask.new
-
-task default: [:rubocop, :test, :conformance]
-
-desc "Run MCP conformance tests (PORT, SCENARIO, SPEC_VERSION, VERBOSE)"
-task :conformance do |t|
-  next unless npx_available?(t.name)
-
-  require_relative "conformance/runner"
-
-  options = {}
-  options[:port] = Integer(ENV["PORT"]) if ENV["PORT"]
-  options[:scenario] = ENV["SCENARIO"] if ENV["SCENARIO"]
-  options[:spec_version] = ENV["SPEC_VERSION"] if ENV["SPEC_VERSION"]
-  options[:verbose] = true if ENV["VERBOSE"]
-
-  Conformance::Runner.new(**options).run
-end
-
-desc "List available conformance scenarios"
-task :conformance_list do |t|
-  next unless npx_available?(t.name)
-
-  system("npx", "--yes", "@modelcontextprotocol/conformance", "list", "--server")
-end
-
-desc "Start the conformance server (PORT)"
-task :conformance_server do
-  require_relative "conformance/server"
-
-  options = {}
-  options[:port] = Integer(ENV["PORT"]) if ENV["PORT"]
-
-  Conformance::Server.new(**options).start
-end
-
-def npx_available?(task_name)
-  return true if system("which", "npx", out: File::NULL, err: File::NULL)
-
-  warn("Skipping #{task_name}: npx is not installed. Install Node.js to run this task: https://nodejs.org/")
-  false
-end

data/SECURITY.md

@@ -1,21 +0,0 @@
-# Security Policy
-
-Thank you for helping keep the Model Context Protocol and its ecosystem secure.
-
-## Reporting Security Issues
-
-If you discover a security vulnerability in this repository, please report it through
-the [GitHub Security Advisory process](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability)
-for this repository.
-
-Please **do not** report security vulnerabilities through public GitHub issues, discussions,
-or pull requests.
-
-## What to Include
-
-To help us triage and respond quickly, please include:
-
-- A description of the vulnerability
-- Steps to reproduce the issue
-- The potential impact
-- Any suggested fixes (optional)

data/bin/console

@@ -1,15 +0,0 @@
-#!/usr/bin/env ruby
-# frozen_string_literal: true
-
-require "bundler/setup"
-require "mcp"
-
-# You can add fixtures and/or initialization code here to make experimenting
-# with your gem easier. You can also use a different console, if you like.
-
-# (If you use this, don't forget to add pry to your Gemfile!)
-# require "pry"
-# Pry.start
-
-require "irb"
-IRB.start(__FILE__)

data/bin/generate-gh-pages.sh

@@ -1,119 +0,0 @@
-#!/bin/bash
-set -e
-
-# Generates versioned documentation links and commits to gh-pages branch
-#
-# PURPOSE:
-#   This script generates a landing page with links to API documentation on
-#   RubyDoc.info for a specific version tag. This script is invoked by the
-#   publish-gh-pages job in the GitHub Actions workflow
-#   (.github/workflows/release.yml) when a release is published.
-#
-# HOW IT WORKS:
-#   - Creates isolated git worktrees for the specified tag and gh-pages branch
-#   - Copies static Jekyll template files from docs/
-#   - Generates _data/versions.yml with list of versions
-#   - Commits changes to gh-pages (does not push automatically)
-#
-# WORKFLOW:
-#   1. Run this script with a tag name: `generate-gh-pages.sh v1.2.3`
-#   2. Script generates docs and commits to local gh-pages branch
-#   3. Push gh-pages branch to deploy: `git push origin gh-pages`
-
-# Parse semantic version from tag name (ignoring arbitrary prefixes)
-if [[ "${1}" =~ ([0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.-]+)?)$ ]]; then
-  VERSION="v${BASH_REMATCH[1]}"
-else
-  echo "Error: Must specify a tag name that contains a valid semantic version"
-  echo "Usage: ${0} <tag-name>"
-  echo "Examples:"
-  echo "  ${0} 1.2.3"
-  echo "  ${0} v2.0.0-rc.1"
-  exit 1
-fi
-
-TAG_NAME="${1}"
-REPO_ROOT="$(git rev-parse --show-toplevel)"
-
-echo "Generating documentation for tag: ${TAG_NAME}"
-
-# Create temporary directories for both worktrees
-WORKTREE_DIR=$(mktemp -d)
-GHPAGES_WORKTREE_DIR=$(mktemp -d)
-
-# Set up trap to clean up both worktrees on exit
-trap 'git worktree remove --force "${WORKTREE_DIR}" 2>/dev/null || true; \
-      git worktree remove --force "${GHPAGES_WORKTREE_DIR}" 2>/dev/null || true' EXIT
-
-echo "Creating worktree for ${TAG_NAME}..."
-git worktree add --quiet "${WORKTREE_DIR}" "${TAG_NAME}"
-
-# Check if gh-pages branch exists
-if git show-ref --verify --quiet refs/heads/gh-pages; then
-  echo "Creating worktree for existing gh-pages branch..."
-  git worktree add --quiet "${GHPAGES_WORKTREE_DIR}" gh-pages
-elif git ls-remote --exit-code --heads origin gh-pages > /dev/null 2>&1; then
-  echo "Creating worktree for gh-pages branch from remote..."
-  git worktree add --quiet "${GHPAGES_WORKTREE_DIR}" -b gh-pages origin/gh-pages
-else
-  echo "Creating worktree for new orphan gh-pages branch..."
-  git worktree add --quiet --detach "${GHPAGES_WORKTREE_DIR}"
-  git -C "${GHPAGES_WORKTREE_DIR}" checkout --orphan gh-pages
-  git -C "${GHPAGES_WORKTREE_DIR}" rm -rf . > /dev/null 2>&1 || true
-fi
-
-# Change to gh-pages worktree
-cd "${GHPAGES_WORKTREE_DIR}"
-
-# Determine if this tag is the latest version
-echo "Determining if ${VERSION} is the latest version..."
-
-# Get all existing version tags from the repository (reverse sorted, newest first)
-ALL_VERSIONS=$(
-  git -C "${REPO_ROOT}" tag --list | \
-  sed -nE 's/^[^0-9]*([0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.-]+)?)$/v\1/p' | \
-  sort -Vr
-)
-
-# Get the latest version from all version tags
-LATEST_VERSION=$(echo "${ALL_VERSIONS}" | head -n 1)
-
-if [ "${VERSION}" = "${LATEST_VERSION}" ]; then
-  echo "${VERSION} is the latest version"
-else
-  echo "${VERSION} is not the latest version (latest is ${LATEST_VERSION})"
-fi
-
-# Update custom documentation for latest version
-if [ "${VERSION}" = "${LATEST_VERSION}" ]; then
-  echo "Updating custom documentation..."
-
-  # Clean up old custom docs from gh-pages root
-  echo "Cleaning gh-pages root..."
-  git ls-tree --name-only HEAD | xargs -r git rm -rf
-
-  # Copy custom docs from docs/ directory
-  echo "Copying custom docs from ${WORKTREE_DIR}/docs/..."
-  cp -r "${WORKTREE_DIR}/docs/." "${GHPAGES_WORKTREE_DIR}/"
-fi
-
-# Generate version data for Jekyll
-echo "Generating _data/versions.yml..."
-mkdir -p _data
-echo "${ALL_VERSIONS}" | sed 's/^v/- /' > _data/versions.yml
-
-# Stage all changes
-git add .
-
-# Commit if there are changes
-if git diff --staged --quiet; then
-  echo "No changes to commit"
-else
-  echo "Committing documentation for ${VERSION}..."
-  git commit -m "Add ${VERSION} docs"
-
-  echo "Documentation committed to gh-pages branch!"
-  echo "Push to remote to deploy to GitHub Pages"
-fi
-
-echo "Done!"

data/bin/rake

@@ -1,31 +0,0 @@
-#!/usr/bin/env ruby
-# frozen_string_literal: true
-
-#
-# This file was generated by Bundler.
-#
-# The application 'rake' is installed as part of a gem, and
-# this file is here to facilitate running it.
-#
-
-require "pathname"
-ENV["BUNDLE_GEMFILE"] ||= File.expand_path(
-  "../../Gemfile",
-  Pathname.new(__FILE__).realpath,
-)
-
-bundle_binstub = File.expand_path("../bundle", __FILE__)
-
-if File.file?(bundle_binstub)
-  if File.read(bundle_binstub, 300) =~ /This file was generated by Bundler/
-    load(bundle_binstub)
-  else
-    abort("Your `bin/bundle` was not generated by Bundler, so this binstub cannot run.
-Replace `bin/bundle` by running `bundle binstubs bundler --force`, then run this command again.")
-  end
-end
-
-require "rubygems"
-require "bundler/setup"
-
-load Gem.bin_path("rake", "rake")

data/bin/setup

@@ -1,8 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-IFS=$'\n\t'
-set -vx
-
-bundle install
-
-# Do any other automated setup that you need to do here

data/conformance/README.md

@@ -1,103 +0,0 @@
-# MCP Conformance Tests
-
-Validates the Ruby SDK's conformance to the MCP specification using [`@modelcontextprotocol/conformance`](https://github.com/modelcontextprotocol/conformance).
-
-## Prerequisites
-
-- Node.js (for `npx`)
-- `bundle install` completed
-
-## Running the Tests
-
-### Run all scenarios
-
-```bash
-bundle exec rake conformance
-```
-
-Starts the conformance server, runs all active scenarios against it, prints a pass/fail
-summary for each scenario, and exits with a non-zero status code if any unexpected failures
-are detected. Scenarios listed in `expected_failures.yml` are allowed to fail without
-affecting the exit code.
-
-### Environment variables
-
-| Variable       | Description                          | Default |
-|----------------|--------------------------------------|---------|
-| `PORT`         | Server port                          | `9292`  |
-| `SCENARIO`     | Run a single scenario by name        | (all)   |
-| `SPEC_VERSION` | Filter scenarios by spec version     | (all)   |
-| `VERBOSE`      | Show raw JSON output when set        | (off)   |
-
-```bash
-# Run a single scenario
-bundle exec rake conformance SCENARIO=ping
-
-# Use a different port with verbose output
-bundle exec rake conformance PORT=3000 VERBOSE=1
-
-# Start the server on a specific port
-bundle exec rake conformance_server PORT=3000
-```
-
-### Start the server and test separately
-
-```bash
-# Terminal 1: start the server
-bundle exec rake conformance_server
-
-# Terminal 2: run all scenarios
-npx @modelcontextprotocol/conformance server --url http://localhost:9292/mcp
-
-# Terminal 2: run a single scenario
-npx @modelcontextprotocol/conformance server --url http://localhost:9292/mcp --scenario ping
-```
-
-Keeps the server alive between test runs, which avoids the startup overhead when iterating
-on a single scenario. Stop the server with Ctrl+C when done.
-
-### List available scenarios
-
-```bash
-bundle exec rake conformance_list
-```
-
-Prints all scenario names that can be passed to `SCENARIO`.
-
-## SDK Tier Report
-
-The [MCP SDK Tier system](https://modelcontextprotocol.io/community/sdk-tiers) requires SDK
-maintainers to self-assess and report results to the SDK Working Group via
-[modelcontextprotocol/modelcontextprotocol issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues).
-
-To generate a full tier assessment report, use the `/mcp-sdk-tier-audit` slash command from
-the [modelcontextprotocol/conformance](https://github.com/modelcontextprotocol/conformance)
-repository with the conformance server running:
-
-```bash
-# Terminal 1 (this repository): start the conformance server
-bundle exec rake conformance_server
-
-# Terminal 2 (conformance repository): run the tier audit skill as a slash command in Claude Code
-/mcp-sdk-tier-audit /path/to/modelcontextprotocol/ruby-sdk http://localhost:9292/mcp
-```
-
-The skill evaluates conformance pass rate, issue label taxonomy, triage metrics, documentation
-coverage, and policy compliance, then produces a markdown report suitable for tier advancement
-submissions.
-
-## File Structure
-
-```
-conformance/
-  server.rb              # Conformance server (Rack + Puma, default port 9292)
-  runner.rb              # Starts the server, runs npx conformance, exits with result code
-  expected_failures.yml  # Baseline of known-failing scenarios
-  README.md              # This file
-```
-
-## Known Limitations
-
-Known-failing scenarios are registered in `conformance/expected_failures.yml`. They are allowed to
-fail without affecting the exit code and are tracked to catch regressions.
-These are shown in the output of `bundle exec rake conformance`.

data/conformance/expected_failures.yml

@@ -1,9 +0,0 @@
-server:
-  # TODO: Server-to-client requests (sampling/createMessage, elicitation/create) are not implemented.
-  # `Transport#send_request` does not exist in the current SDK.
-  - tools-call-sampling
-  - tools-call-elicitation
-  - elicitation-sep1034-defaults
-  - elicitation-sep1330-enums
-  # TODO: The SDK does not extract `_meta.progressToken` from tool call requests or deliver `notifications/progress` to tools.
-  - tools-call-with-progress