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

Locate the servlet-based transport implementations that call request.getReader(), then compare their request-body handling with the StdioServerTransportProvider fix in PR 826. Add regression coverage using a non-ASCII JSON-RPC value and verify that requests without an explicit charset preserve the original characters.