Skip to content

Conversation

@felixweinberger
Copy link

Moves task-related functionality into an experimental/tasks module to clearly mark it as experimental and separate it from stable APIs.

Motivation and Context

Tasks are still experimental and subject to change. This refactor isolates them into a dedicated experimental/ namespace so users understand the stability guarantees.

How Has This Been Tested?

  • All existing tests pass
  • Build and lint pass

Breaking Changes

  • Task APIs are now accessed via client.experimental.tasks.* and server.experimental.tasks.* instead of directly on the client/server

Types of changes

  • Breaking change (fix or feature that would cause existing functionality to change)

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

This is a follow-up to modelcontextprotocol#1041 to organize the experimental task APIs.

@pkg-pr-new
Copy link

pkg-pr-new bot commented Nov 26, 2025

Open in StackBlitz

npm i https://pkg.pr.new/LucaButBoring/mcp-ts-sdk/@modelcontextprotocol/sdk@3

commit: 797e23e

@LucaButBoring
Copy link
Owner

Discussed on Discord — I'm aligned with this as long as we ensure callToolStream can still be used on non-task tool calls, so it can remain a drop-in replacement for callTool for applications that opt into it. We'll have a couple extra tests to validate this.

Phase 1-2 of tasks experimental isolation:
- Create src/experimental/tasks/ directory structure
- Move TaskStore, TaskMessageQueue, and related interfaces to experimental/tasks/interfaces.ts
- Add experimental/tasks/types.ts for re-exporting spec types
- Update shared/task.ts to re-export from experimental for backward compatibility
- Add barrel exports for experimental module

All tests pass (1399 tests).
Restore callTool() to its original implementation instead of delegating
to experimental.tasks.callToolStream(). This aligns with Python SDK's
approach where call_tool() is task-unaware and call_tool_as_task() is
the explicit experimental method.

Changes:
- Add guard for taskSupport: 'required' tools with clear error message
- Restore original output schema validation logic
- Add _cachedRequiredTaskTools to track required-only task tools
- Remove unused takeResult import

Tools with taskSupport: 'optional' work normally with callTool() since
the server returns CallToolResult. Only 'required' tools need the
experimental API.
@felixweinberger felixweinberger force-pushed the fweinberger/tasks-experimental-isolation branch from 6993f64 to 4128d4d Compare November 27, 2025 11:16
@felixweinberger
Copy link
Author

Discussed on Discord — I'm aligned with this as long as we ensure callToolStream can still be used on non-task tool calls, so it can remain a drop-in replacement for callTool for applications that opt into it. We'll have a couple extra tests to validate this.

Added

@LucaButBoring LucaButBoring merged commit 0e89248 into LucaButBoring:feat/tasks Nov 27, 2025
6 checks passed
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.

2 participants