Servlet-based server transports read request body with wrong charset encoding

找出呼叫 request.getReader() 的 servlet 型傳輸實作，然後將它們對請求本文的處理方式與 PR 826 中 StdioServerTransportProvider 的修正進行比較。使用非 ASCII 的 JSON-RPC 值新增回歸測試涵蓋，並驗證未明確指定 charset 的請求能保留原始字元。

Bug description
The servlet-based server transports call request.getReader() without first calling request.setCharacterEncoding("UTF-8"). Per the Jakarta Servlet spec, getReader() defaults to ISO-8859-1 when the request's Content-Type doesn't include an explicit charset parameter. Since Content-Type: application/json (without charset) is standard and correct per RFC 8259, any non-ASCII characters in the JSON-RPC request body are silently corrupted.

This affects everything in the request payload — tool names, argument values, notification data — for any MCP client that doesn't redundantly declare charset=utf-8 in its Content-Type header. The analogous issue in StdioServerTransportProvider was fixed in https://github.com/modelcontextprotocol/java-sdk/pull/826.

Environment

• MCP Java SDK: 1.0.0
• Java: 21
• No Spring AI or vector store involved — this is a bug in the core servlet request reading logic, not specific to any framework or integration.

Steps to reproduce

1. Start an MCP server using any of the servlet-based transports
2. Send a tool call with a non-ASCII string argument, e.g. a unicode escape sequence like \u2014 (em dash —).
3. The server receives mojibake (e.g. — → â).

Expected behavior
Non-ASCII characters in the JSON-RPC request body (tool names, argument values, etc.) should be preserved correctly. JSON is UTF-8 by definition, so the server should decode request bodies as UTF-8 regardless of whether the client includes charset=utf-8 in the Content-Type header.

Related

• https://github.com/modelcontextprotocol/java-sdk/issues/260