Skip to content

Conversation

@koic
Copy link
Member

@koic koic commented Nov 11, 2025

Motivation and Context

For example, the title introduced in #109 is not supported in the latest stable protocol version "2025-06-18": https://modelcontextprotocol.io/specification/2025-06-18

It is supported in the Draft of the next version:
https://modelcontextprotocol.io/specification/draft

In other words, the fact that the Ruby SDK treats "2025-06-18" as the default protocol version while title is only supported in the Draft results in an inconsistency.

Because of this, a new version "Draft" has been added to the list of supported versions. Its value follows the schema below and is defined as DRAFT-2025-v3: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/14ec41c/schema/draft/schema.ts#L15

It was also considered to continue using the latest stable version "2025-06-18" as the Ruby SDK default instead of the Draft. However, in that case, users would need to explicitly specify MCP::Server.new(protocol_version: 'DRAFT-2025-v3'), which adds extra burden. In this PR, Draft is made the default in order to provide the following benefits:

  • Users are likely to prefer using the Draft version over the latest stable version
  • No need to specify the protocol_version option when initializing MCP::Server
  • Users generally do not need to know the internal development value DRAFT-2025-v3

The primary case for specifying protocol_version explicitly is when strict adherence to a particular version is required. However, it seems more practical to prioritize use cases where backward-compatible features, including those from the Draft, are desirable. This is the rationale behind making the Draft version the default.

In addition, making the Draft version the default protocol version preserves backward compatibility for MCP::Server.

How Has This Been Tested?

Added new tests, and all tests, including the existing ones, are passing.

Breaking Changes

When no version is specified for protocol_version, features from the draft version are still allowed by default.
On the other hand, when a version is specified for protocol_version, only features that strictly conform to the corresponding specification are permitted.

It is assumed that users typically don't specify protocol_version and this doesn't cause breaking changes for that.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

NOTE: DRAFT-2025-v3 is a development code, so its value cannot be set externally. It is applied either when protocol_version is omitted or when nil is set explicitly, such as with MCP::Configuration.new(protocol_version: nil). This prevents users from creating implementations that depend on development codes like DRAFT-2025-v3.

For example, the `title` introduced in modelcontextprotocol#109 is not supported in the latest stable protocol version "2025-06-18":
https://modelcontextprotocol.io/specification/2025-06-18

It is supported in the Draft of the next version:
https://modelcontextprotocol.io/specification/draft

In other words, the fact that the Ruby SDK treats "2025-06-18" as the default protocol version while `title` is
only supported in the Draft results in an inconsistency.

Because of this, a new version `"Draft"` has been added to the list of supported versions.
Its value follows the schema below and is defined as `DRAFT-2025-v3`:
https://github.com/modelcontextprotocol/modelcontextprotocol/blob/14ec41c/schema/draft/schema.ts#L15

It was also considered to continue using the latest stable version "2025-06-18" as the Ruby SDK default instead of the Draft.
However, in that case, users would need to explicitly specify `MCP::Server.new(protocol_version: 'DRAFT-2025-v3')`,
which adds extra burden. In this PR, Draft is made the default in order to provide the following benefits:

- Users are likely to prefer using the Draft version over the latest stable version
- No need to specify the `protocol_version` option when initializing `MCP::Server`
- Users generally do not need to know the internal development value `DRAFT-2025-v3`

The primary case for specifying `protocol_version` explicitly is when strict adherence to a particular version is required.
However, it seems more practical to prioritize use cases where backward-compatible features, including those from the Draft,
are desirable. This is the rationale behind making the Draft version the default.

In addition, making the Draft version the default protocol version preserves backward compatibility for `MCP::Server`.

NOTE: `DRAFT-2025-v3` is a development code, so its value cannot be set externally.
It is applied either when `protocol_version` is omitted or when `nil` is set explicitly,
such as with `MCP::Configuration.new(protocol_version: nil)`.
This prevents users from creating implementations that depend on development codes like `DRAFT-2025-v3`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant