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

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

定位调用 request.getReader() 的基于 servlet 的传输实现，然后将它们对请求正文的处理与 PR 826 中 StdioServerTransportProvider 的修复进行比较。使用一个非 ASCII 的 JSON-RPC 值添加回归测试覆盖，并验证未显式指定 charset 的请求能够保留原始字符。