Fixes servlet transport error serialization so servlet transports write JSON-RPC error responses for McpError instead of serializing the Java exception object.
Some servlet transport error paths currently serialize McpError directly. Since McpError extends RuntimeException, the response body can include exception-shaped fields such as stackTrace, cause, localizedMessage, and jsonRpcError.
This makes servlet error responses inconsistent with the JSON-RPC error response shape expected by MCP clients.
Before:
After:
How Has This Been Tested?
Added servlet transport tests covering JSON-RPC error serialization for:
stateless servlet transport errors
streamable servlet transport errors
SSE servlet transport errors
parsed request id preservation
no-id transport-level rejection paths
I also verified the behavior locally with a small servlet server and Postman using the same request before and after the fix.
Breaking Changes
None intended.
The existing HTTP status behavior for transport-level rejections is preserved. The response body is changed to the expected JSON-RPC error envelope instead of serializing the McpError exception object.
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)
This change keeps the existing servlet transport status-code behavior for transport-level rejections, but writes a JSON-RPC error response body consistently.
When the request id has already been parsed, the response preserves it. For transport-level rejection paths where no request id is available, the response omits the id field.
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
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.
Fixes servlet transport error serialization so servlet transports write JSON-RPC error responses for McpError instead of serializing the Java exception object.
Fixes #955
Motivation and Context
Some servlet transport error paths currently serialize McpError directly. Since McpError extends RuntimeException, the response body can include exception-shaped fields such as stackTrace, cause, localizedMessage, and jsonRpcError.
This makes servlet error responses inconsistent with the JSON-RPC error response shape expected by MCP clients.
Before:
After:
How Has This Been Tested?
Added servlet transport tests covering JSON-RPC error serialization for:
I also verified the behavior locally with a small servlet server and Postman using the same request before and after the fix.
Breaking Changes
None intended.
The existing HTTP status behavior for transport-level rejections is preserved. The response body is changed to the expected JSON-RPC error envelope instead of serializing the McpError exception object.
Types of changes
Checklist
Additional context
This change keeps the existing servlet transport status-code behavior for transport-level rejections, but writes a JSON-RPC error response body consistently.
When the request id has already been parsed, the response preserves it. For transport-level rejection paths where no request id is available, the response omits the id field.
References: