Should McpClient normalize JSON-RPC errors across stdio and Streamable HTTP

[chidozieononiwu]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

We are adding Streamable HTTP coverage to the Azure MCP Server and found that unsupported MCP methods produce different client exceptions depending on transport when using C# MCP SDK 2.1.0:

stdio: McpProtocolException with McpErrorCode.MethodNotFound
Streamable HTTP: HttpRequestException with HTTP 404
The HTTP response appears to contain a valid JSON-RPC error envelope with error code -32601. We understand that SEP-2575 maps MethodNotFound to HTTP 404, and that the client currently preserves most 404 responses as HttpRequestException for backward compatibility.

Is this transport-dependent client behavior intentional and part of the expected public contract?

More generally:

Should callers catch both McpProtocolException and HttpRequestException for the same logical MCP error?
Should a valid JSON-RPC error envelope take precedence over the HTTP status when choosing the client exception?
Is there a documented mapping of server errors to client exceptions for stdio and Streamable HTTP?
Which error scenarios are intentionally transport-specific?
This affects how we write transport-agnostic error handling and tests. We want to ensure that accommodating this case does not hide other incorrectly handled scenarios.