fix: prevent task-augmented tool errors from being masked#1440
Open
codewithkenzo wants to merge 1 commit intomodelcontextprotocol:mainfrom
Open
fix: prevent task-augmented tool errors from being masked#1440codewithkenzo wants to merge 1 commit intomodelcontextprotocol:mainfrom
codewithkenzo wants to merge 1 commit intomodelcontextprotocol:mainfrom
Conversation
Re-throw McpErrors for task-augmented requests to avoid masking them with 'Invalid task creation result' errors in server.ts validation. The issue occurs when a task-augmented tools/call request fails validation: 1. Error is caught in mcp.ts and wrapped via createToolError() 2. Result is validated against CreateTaskResultSchema in server.ts 3. Validation fails because the error result lacks a task property 4. User sees 'Invalid task creation result' instead of the actual error This fix re-throws all McpError types for task-augmented requests, allowing the actual error to propagate instead of being masked. Fixes modelcontextprotocol#1385
🦋 Changeset detectedLatest commit: 1c50f99 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
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 |
Author
|
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. |
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #1385
When a task-augmented
tools/callrequest fails validation, the error was being masked by "Invalid task creation result" instead of showing the actual error message.The Problem
InvalidParams)mcp.tsand wrapped viacreateToolError()→ returns{ isError: true }server.ts, result is validated againstCreateTaskResultSchema{ isError: true }doesn't have ataskpropertyThe Fix
Re-throw all
McpErrortypes for task-augmented requests instead of wrapping them increateToolError(). This allows protocol-level errors to propagate correctly rather than being masked by task result validation.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:
isError: true(so LLM can see and self-correct)Task result validation failures fall into the "exceptional conditions" category and should propagate as protocol errors.
Testing
authExtensions.test.tsis unrelated (exists onmain)