fix: prevent task-augmented tool errors from being masked

[codewithkenzo]

Summary

Fixes#1385

When a task-augmented tools/call request fails validation, the error was being masked by "Invalid task creation result" instead of showing the actual error message.

The Problem

1. Task-augmented request fails (e.g., InvalidParams)
2. Error is caught in mcp.ts and wrapped via createToolError() → returns { isError: true }
3. In server.ts, result is validated against CreateTaskResultSchema
4. Validation fails because { isError: true } doesn't have a task property
5. User sees: "Invalid task creation result: ..." instead of the actual validation error

The Fix

Re-throw allMcpError types for task-augmented requests instead of wrapping them in createToolError(). This allows protocol-level errors to propagate correctly rather than being masked by task result validation.

}catch(error){// For task-augmented requests, re-throw McpErrors to avoid masking// them with "Invalid task creation result" errors in server.tsif(request.params.task&&errorinstanceofMcpError){throwerror;}if(errorinstanceofMcpError&&error.code===ErrorCode.UrlElicitationRequired){throwerror;}returnthis.createToolError(errorinstanceofError ? error.message : String(error));}

Rationale

This follows established RPC patterns (JSON-RPC, gRPC, tRPC) where validation errors are protocol-level errors, not application results. The MCP spec also distinguishes between:

• Tool execution errors → isError: true (so LLM can see and self-correct)
• Protocol/exceptional errors → Protocol-level error response

Task result validation failures fall into the "exceptional conditions" category and should propagate as protocol errors.

Testing

• Typecheck passes
• Existing task lifecycle integration tests pass
• Pre-existing test failure in authExtensions.test.ts is unrelated (exists on main)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1c50f99

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/express	Patch
@modelcontextprotocol/hono	Patch
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

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

[codewithkenzo]

This follows up on my comment in #1385. Based on further analysis, I expanded the fix to re-throw all McpError types for task-augmented requests (not just InvalidParams) since any protocol-level error would hit the same masking issue.

Happy to adjust if maintainers prefer a narrower scope.

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 1c50f99

[felixweinberger]

Thanks for this. The approach (re-throw protocol errors for task-augmented calls) is correct, but this PR uses McpError/ErrorCode which were renamed to ProtocolError/ProtocolErrorCode in #1454. Consolidating on #1664 which uses the current types. Closing.

[codewithkenzo]

Summary

Fixes#1385

When a task-augmented tools/call request fails validation, the error was being masked by "Invalid task creation result" instead of showing the actual error message.

The Problem

1. Task-augmented request fails (e.g., InvalidParams)
2. Error is caught in mcp.ts and wrapped via createToolError() → returns { isError: true }
3. In server.ts, result is validated against CreateTaskResultSchema
4. Validation fails because { isError: true } doesn't have a task property
5. User sees: "Invalid task creation result: ..." instead of the actual validation error

The Fix

Re-throw allMcpError types for task-augmented requests instead of wrapping them in createToolError(). This allows protocol-level errors to propagate correctly rather than being masked by task result validation.

}catch(error){// For task-augmented requests, re-throw McpErrors to avoid masking// them with "Invalid task creation result" errors in server.tsif(request.params.task&&errorinstanceofMcpError){throwerror;}if(errorinstanceofMcpError&&error.code===ErrorCode.UrlElicitationRequired){throwerror;}returnthis.createToolError(errorinstanceofError ? error.message : String(error));}

Rationale

This follows established RPC patterns (JSON-RPC, gRPC, tRPC) where validation errors are protocol-level errors, not application results. The MCP spec also distinguishes between:

• Tool execution errors → isError: true (so LLM can see and self-correct)
• Protocol/exceptional errors → Protocol-level error response

Task result validation failures fall into the "exceptional conditions" category and should propagate as protocol errors.

Testing

• Typecheck passes
• Existing task lifecycle integration tests pass
• Pre-existing test failure in authExtensions.test.ts is unrelated (exists on main)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1c50f99

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/express	Patch
@modelcontextprotocol/hono	Patch
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

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

[codewithkenzo]

This follows up on my comment in #1385. Based on further analysis, I expanded the fix to re-throw all McpError types for task-augmented requests (not just InvalidParams) since any protocol-level error would hit the same masking issue.

Happy to adjust if maintainers prefer a narrower scope.

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 1c50f99

[felixweinberger]

Thanks for this. The approach (re-throw protocol errors for task-augmented calls) is correct, but this PR uses McpError/ErrorCode which were renamed to ProtocolError/ProtocolErrorCode in #1454. Consolidating on #1664 which uses the current types. Closing.

[codewithkenzo]

Summary

Fixes#1385

When a task-augmented tools/call request fails validation, the error was being masked by "Invalid task creation result" instead of showing the actual error message.

The Problem

1. Task-augmented request fails (e.g., InvalidParams)
2. Error is caught in mcp.ts and wrapped via createToolError() → returns { isError: true }
3. In server.ts, result is validated against CreateTaskResultSchema
4. Validation fails because { isError: true } doesn't have a task property
5. User sees: "Invalid task creation result: ..." instead of the actual validation error

The Fix

Re-throw allMcpError types for task-augmented requests instead of wrapping them in createToolError(). This allows protocol-level errors to propagate correctly rather than being masked by task result validation.

}catch(error){// For task-augmented requests, re-throw McpErrors to avoid masking// them with "Invalid task creation result" errors in server.tsif(request.params.task&&errorinstanceofMcpError){throwerror;}if(errorinstanceofMcpError&&error.code===ErrorCode.UrlElicitationRequired){throwerror;}returnthis.createToolError(errorinstanceofError ? error.message : String(error));}

Rationale

This follows established RPC patterns (JSON-RPC, gRPC, tRPC) where validation errors are protocol-level errors, not application results. The MCP spec also distinguishes between:

• Tool execution errors → isError: true (so LLM can see and self-correct)
• Protocol/exceptional errors → Protocol-level error response

Task result validation failures fall into the "exceptional conditions" category and should propagate as protocol errors.

Testing

• Typecheck passes
• Existing task lifecycle integration tests pass
• Pre-existing test failure in authExtensions.test.ts is unrelated (exists on main)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1c50f99

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/express	Patch
@modelcontextprotocol/hono	Patch
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

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

[codewithkenzo]

This follows up on my comment in #1385. Based on further analysis, I expanded the fix to re-throw all McpError types for task-augmented requests (not just InvalidParams) since any protocol-level error would hit the same masking issue.

Happy to adjust if maintainers prefer a narrower scope.

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 1c50f99

[felixweinberger]

Thanks for this. The approach (re-throw protocol errors for task-augmented calls) is correct, but this PR uses McpError/ErrorCode which were renamed to ProtocolError/ProtocolErrorCode in #1454. Consolidating on #1664 which uses the current types. Closing.

[codewithkenzo]

Summary

Fixes#1385

When a task-augmented tools/call request fails validation, the error was being masked by "Invalid task creation result" instead of showing the actual error message.

The Problem

1. Task-augmented request fails (e.g., InvalidParams)
2. Error is caught in mcp.ts and wrapped via createToolError() → returns { isError: true }
3. In server.ts, result is validated against CreateTaskResultSchema
4. Validation fails because { isError: true } doesn't have a task property
5. User sees: "Invalid task creation result: ..." instead of the actual validation error

The Fix

Re-throw allMcpError types for task-augmented requests instead of wrapping them in createToolError(). This allows protocol-level errors to propagate correctly rather than being masked by task result validation.

}catch(error){// For task-augmented requests, re-throw McpErrors to avoid masking// them with "Invalid task creation result" errors in server.tsif(request.params.task&&errorinstanceofMcpError){throwerror;}if(errorinstanceofMcpError&&error.code===ErrorCode.UrlElicitationRequired){throwerror;}returnthis.createToolError(errorinstanceofError ? error.message : String(error));}

Rationale

This follows established RPC patterns (JSON-RPC, gRPC, tRPC) where validation errors are protocol-level errors, not application results. The MCP spec also distinguishes between:

• Tool execution errors → isError: true (so LLM can see and self-correct)
• Protocol/exceptional errors → Protocol-level error response

Task result validation failures fall into the "exceptional conditions" category and should propagate as protocol errors.

Testing

• Typecheck passes
• Existing task lifecycle integration tests pass
• Pre-existing test failure in authExtensions.test.ts is unrelated (exists on main)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1c50f99

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/express	Patch
@modelcontextprotocol/hono	Patch
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

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

[codewithkenzo]

This follows up on my comment in #1385. Based on further analysis, I expanded the fix to re-throw all McpError types for task-augmented requests (not just InvalidParams) since any protocol-level error would hit the same masking issue.

Happy to adjust if maintainers prefer a narrower scope.

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 1c50f99

[felixweinberger]

Thanks for this. The approach (re-throw protocol errors for task-augmented calls) is correct, but this PR uses McpError/ErrorCode which were renamed to ProtocolError/ProtocolErrorCode in #1454. Consolidating on #1664 which uses the current types. Closing.

[codewithkenzo]

Summary

Fixes#1385

When a task-augmented tools/call request fails validation, the error was being masked by "Invalid task creation result" instead of showing the actual error message.

The Problem

1. Task-augmented request fails (e.g., InvalidParams)
2. Error is caught in mcp.ts and wrapped via createToolError() → returns { isError: true }
3. In server.ts, result is validated against CreateTaskResultSchema
4. Validation fails because { isError: true } doesn't have a task property
5. User sees: "Invalid task creation result: ..." instead of the actual validation error

The Fix

Re-throw allMcpError types for task-augmented requests instead of wrapping them in createToolError(). This allows protocol-level errors to propagate correctly rather than being masked by task result validation.

}catch(error){// For task-augmented requests, re-throw McpErrors to avoid masking// them with "Invalid task creation result" errors in server.tsif(request.params.task&&errorinstanceofMcpError){throwerror;}if(errorinstanceofMcpError&&error.code===ErrorCode.UrlElicitationRequired){throwerror;}returnthis.createToolError(errorinstanceofError ? error.message : String(error));}

Rationale

This follows established RPC patterns (JSON-RPC, gRPC, tRPC) where validation errors are protocol-level errors, not application results. The MCP spec also distinguishes between:

• Tool execution errors → isError: true (so LLM can see and self-correct)
• Protocol/exceptional errors → Protocol-level error response

Task result validation failures fall into the "exceptional conditions" category and should propagate as protocol errors.

Testing

• Typecheck passes
• Existing task lifecycle integration tests pass
• Pre-existing test failure in authExtensions.test.ts is unrelated (exists on main)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1c50f99

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/express	Patch
@modelcontextprotocol/hono	Patch
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

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

[codewithkenzo]

This follows up on my comment in #1385. Based on further analysis, I expanded the fix to re-throw all McpError types for task-augmented requests (not just InvalidParams) since any protocol-level error would hit the same masking issue.

Happy to adjust if maintainers prefer a narrower scope.

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 1c50f99

[felixweinberger]

Thanks for this. The approach (re-throw protocol errors for task-augmented calls) is correct, but this PR uses McpError/ErrorCode which were renamed to ProtocolError/ProtocolErrorCode in #1454. Consolidating on #1664 which uses the current types. Closing.

[codewithkenzo]

Summary

Fixes#1385

When a task-augmented tools/call request fails validation, the error was being masked by "Invalid task creation result" instead of showing the actual error message.

The Problem

1. Task-augmented request fails (e.g., InvalidParams)
2. Error is caught in mcp.ts and wrapped via createToolError() → returns { isError: true }
3. In server.ts, result is validated against CreateTaskResultSchema
4. Validation fails because { isError: true } doesn't have a task property
5. User sees: "Invalid task creation result: ..." instead of the actual validation error

The Fix

Re-throw allMcpError types for task-augmented requests instead of wrapping them in createToolError(). This allows protocol-level errors to propagate correctly rather than being masked by task result validation.

}catch(error){// For task-augmented requests, re-throw McpErrors to avoid masking// them with "Invalid task creation result" errors in server.tsif(request.params.task&&errorinstanceofMcpError){throwerror;}if(errorinstanceofMcpError&&error.code===ErrorCode.UrlElicitationRequired){throwerror;}returnthis.createToolError(errorinstanceofError ? error.message : String(error));}

Rationale

This follows established RPC patterns (JSON-RPC, gRPC, tRPC) where validation errors are protocol-level errors, not application results. The MCP spec also distinguishes between:

• Tool execution errors → isError: true (so LLM can see and self-correct)
• Protocol/exceptional errors → Protocol-level error response

Task result validation failures fall into the "exceptional conditions" category and should propagate as protocol errors.

Testing

• Typecheck passes
• Existing task lifecycle integration tests pass
• Pre-existing test failure in authExtensions.test.ts is unrelated (exists on main)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1c50f99

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/express	Patch
@modelcontextprotocol/hono	Patch
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

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

[codewithkenzo]

This follows up on my comment in #1385. Based on further analysis, I expanded the fix to re-throw all McpError types for task-augmented requests (not just InvalidParams) since any protocol-level error would hit the same masking issue.

Happy to adjust if maintainers prefer a narrower scope.

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 1c50f99

[felixweinberger]

Thanks for this. The approach (re-throw protocol errors for task-augmented calls) is correct, but this PR uses McpError/ErrorCode which were renamed to ProtocolError/ProtocolErrorCode in #1454. Consolidating on #1664 which uses the current types. Closing.

[codewithkenzo]

Summary

Fixes#1385

When a task-augmented tools/call request fails validation, the error was being masked by "Invalid task creation result" instead of showing the actual error message.

The Problem

1. Task-augmented request fails (e.g., InvalidParams)
2. Error is caught in mcp.ts and wrapped via createToolError() → returns { isError: true }
3. In server.ts, result is validated against CreateTaskResultSchema
4. Validation fails because { isError: true } doesn't have a task property
5. User sees: "Invalid task creation result: ..." instead of the actual validation error

The Fix

Re-throw allMcpError types for task-augmented requests instead of wrapping them in createToolError(). This allows protocol-level errors to propagate correctly rather than being masked by task result validation.

}catch(error){// For task-augmented requests, re-throw McpErrors to avoid masking// them with "Invalid task creation result" errors in server.tsif(request.params.task&&errorinstanceofMcpError){throwerror;}if(errorinstanceofMcpError&&error.code===ErrorCode.UrlElicitationRequired){throwerror;}returnthis.createToolError(errorinstanceofError ? error.message : String(error));}

Rationale

This follows established RPC patterns (JSON-RPC, gRPC, tRPC) where validation errors are protocol-level errors, not application results. The MCP spec also distinguishes between:

• Tool execution errors → isError: true (so LLM can see and self-correct)
• Protocol/exceptional errors → Protocol-level error response

Task result validation failures fall into the "exceptional conditions" category and should propagate as protocol errors.

Testing

• Typecheck passes
• Existing task lifecycle integration tests pass
• Pre-existing test failure in authExtensions.test.ts is unrelated (exists on main)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1c50f99

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/express	Patch
@modelcontextprotocol/hono	Patch
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

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

[codewithkenzo]

This follows up on my comment in #1385. Based on further analysis, I expanded the fix to re-throw all McpError types for task-augmented requests (not just InvalidParams) since any protocol-level error would hit the same masking issue.

Happy to adjust if maintainers prefer a narrower scope.

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 1c50f99

[felixweinberger]

Thanks for this. The approach (re-throw protocol errors for task-augmented calls) is correct, but this PR uses McpError/ErrorCode which were renamed to ProtocolError/ProtocolErrorCode in #1454. Consolidating on #1664 which uses the current types. Closing.

[codewithkenzo]

Summary

Fixes#1385

When a task-augmented tools/call request fails validation, the error was being masked by "Invalid task creation result" instead of showing the actual error message.

The Problem

1. Task-augmented request fails (e.g., InvalidParams)
2. Error is caught in mcp.ts and wrapped via createToolError() → returns { isError: true }
3. In server.ts, result is validated against CreateTaskResultSchema
4. Validation fails because { isError: true } doesn't have a task property
5. User sees: "Invalid task creation result: ..." instead of the actual validation error

The Fix

Re-throw allMcpError types for task-augmented requests instead of wrapping them in createToolError(). This allows protocol-level errors to propagate correctly rather than being masked by task result validation.

}catch(error){// For task-augmented requests, re-throw McpErrors to avoid masking// them with "Invalid task creation result" errors in server.tsif(request.params.task&&errorinstanceofMcpError){throwerror;}if(errorinstanceofMcpError&&error.code===ErrorCode.UrlElicitationRequired){throwerror;}returnthis.createToolError(errorinstanceofError ? error.message : String(error));}

Rationale

This follows established RPC patterns (JSON-RPC, gRPC, tRPC) where validation errors are protocol-level errors, not application results. The MCP spec also distinguishes between:

• Tool execution errors → isError: true (so LLM can see and self-correct)
• Protocol/exceptional errors → Protocol-level error response

Task result validation failures fall into the "exceptional conditions" category and should propagate as protocol errors.

Testing

• Typecheck passes
• Existing task lifecycle integration tests pass
• Pre-existing test failure in authExtensions.test.ts is unrelated (exists on main)

[changeset-bot]

🦋 Changeset detected

Latest commit: 1c50f99

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/express	Patch
@modelcontextprotocol/hono	Patch
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

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

[codewithkenzo]

This follows up on my comment in #1385. Based on further analysis, I expanded the fix to re-throw all McpError types for task-augmented requests (not just InvalidParams) since any protocol-level error would hit the same masking issue.

Happy to adjust if maintainers prefer a narrower scope.

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 1c50f99

[felixweinberger]

Thanks for this. The approach (re-throw protocol errors for task-augmented calls) is correct, but this PR uses McpError/ErrorCode which were renamed to ProtocolError/ProtocolErrorCode in #1454. Consolidating on #1664 which uses the current types. Closing.