Skip to content

Conversation

@felixweinberger
Copy link
Contributor

Summary

Introduce method overloading for createMessage to preserve backwards compatibility while supporting the new tools feature from SEP-1577.

  • When called without tools, returns CreateMessageResult with single content (backwards compatible)
  • When called with tools, returns CreateMessageResultWithTools which allows array content

Motivation and Context

SEP-1577 changes CreateMessageResult.content from single to single | array. This would be a breaking change for existing SDK users. To avoid requiring a major version bump (v2.0), this PR diverges from the schema for v1.x backwards compatibility.

The schema divergence is documented with a FixSpecCreateMessageResult wrapper in spec.types.test.ts, following the existing pattern for other intentional divergences.

How Has This Been Tested?

  • All 1436 existing tests pass
  • Updated tests for CreateMessageResult to use appropriate schemas
  • Type compatibility tests verify the FixSpec wrapper works

Breaking Changes

None for v1.x users. Existing code that doesn't use tools continues to work unchanged.

Note: v2.0 will align CreateMessageResult with the schema (array content).

Types of changes

  • New feature (non-breaking change which adds functionality)

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

Introduce method overloading for createMessage to preserve backwards
compatibility while supporting the new tools feature from SEP-1577.

When called without tools, createMessage returns CreateMessageResult
with single content (backwards compatible). When called with tools,
it returns CreateMessageResultWithTools which allows array content.

This allows existing code that doesn't use tools to continue working
without any changes, while new code using tools gets the appropriate
type that handles array content.

Changes:
- Add SamplingContentSchema for basic content types (no tool use)
- Add CreateMessageResultWithToolsSchema for tool-enabled responses
- Add CreateMessageRequestParamsBase/WithTools types for overloads
- Add method overloads to Server.createMessage()
- Update tests to use appropriate schemas
- Simplify example that doesn't use tools
@pkg-pr-new
Copy link

pkg-pr-new bot commented Dec 2, 2025

Open in StackBlitz

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/sdk@1212

commit: 373cd2c

@felixweinberger felixweinberger force-pushed the fweinberger/backwards-compat-sampling branch from 85d79bc to d3ead26 Compare December 2, 2025 11:29
Document the intentional divergence between SDK's CreateMessageResult
(single content for v1.x backwards compat) and the spec's version
(array content per SEP-1577).

The full array-capable type is available as CreateMessageResultWithTools.
This will be aligned with schema in v2.0.
@felixweinberger felixweinberger force-pushed the fweinberger/backwards-compat-sampling branch from d3ead26 to 102f4a1 Compare December 2, 2025 11:31
@felixweinberger felixweinberger marked this pull request as ready for review December 2, 2025 11:33
@felixweinberger felixweinberger requested a review from a team as a code owner December 2, 2025 11:33
@felixweinberger felixweinberger mentioned this pull request Dec 2, 2025
23 tasks
@felixweinberger
Copy link
Contributor Author

I also added this to the list of things to clean up for v2: #809

@felixweinberger felixweinberger force-pushed the fweinberger/backwards-compat-sampling branch from ad0ec5c to 5dca8f3 Compare December 2, 2025 13:17
@felixweinberger felixweinberger enabled auto-merge (squash) December 2, 2025 13:17
@felixweinberger felixweinberger merged commit cf51343 into main Dec 2, 2025
10 checks passed
@felixweinberger felixweinberger deleted the fweinberger/backwards-compat-sampling branch December 2, 2025 13:18
Copy link
Contributor

@bhosmer-ant bhosmer-ant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you @felixweinberger - feels like the best solution given the SDK version/spec rev timelines

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.

4 participants