Fix registerToolTask's getTask and getTaskResult handlers not being invoked

[LucaButBoring]

This PR fixes a bug where custom getTask and getTaskResult handlers registered via registerToolTask were never invoked. The Protocol class's task handlers bypassed them entirely and used TaskStore directly. This was a refactoring oversight that was missed due to (1) the existing tests not explicitly checking if those handlers were called, and (2) setTimeout being used in createTask in many tests inadvertently masking the issue.

This also removes the argument-forwarding to getTask and getTaskResult, as that was originally built before the current TaskStore design was finalized, which broke the assumption that the original request would reliably be stored by the implementor. The current TaskStore design allows the Request to be saved, but does not require that, and also exposes no way to directly retrieve it in getTask or getTaskResult (it was possible but no longer intended at the time of the rewrite).

getTask and getTaskResult now only have the extra argument.

Motivation and Context

When using registerToolTask, developers could provide custom getTask and getTaskResult handlers:

mcpServer.experimental.tasks.registerToolTask('test-tool', options, {
    createTask: async (args, extra) => { /* ... */ },
    getTask: async (args, extra) => { /* not called */ },
    getTaskResult: async (args, extra) => { /* not called */ }
});

These handlers were never invoked because:

1. The Protocol class's tasks/get and tasks/result handlers directly called TaskStore instead of forwarding to the custom handlers.
2. McpServer's backwards-compat polling wrapper also bypassed the custom handlers
3. Tests used setTimeout to complete tasks and did not explicitly assert on the handlers being called, inadvertently masking the issue since tasks completed regardless of whether handlers were invoked

How Has This Been Tested?

Updated unit tests with stricter/more robust assertions.

Breaking Changes

Yes, due to args no longer being passed to getTask or getTaskResult.

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

[changeset-bot]

⚠️ No Changeset found

Latest commit: e9a89c6

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

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

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

commit: e9a89c6

[LucaButBoring]

Either this or #1315 will need to be rebased after the other is merged.

[KKonstantinov]

hi, is this something to be backported to v1 as well?