Bump mcp.sdk.version to 2.0.1+ — unregistered/unknown JSON-RPC methods return HTTP 500 on stateless transports #6998

Is your feature request related to a problem? Please describe.

WebFluxStatelessServerTransport and WebMvcStatelessServerTransport return HTTP 500 with a raw
serialized-exception body when a client sends a JSON-RPC method that has no registered handler
(e.g. an unknown/typo'd method, or the new server/discover probe some clients send), instead of
a proper JSON-RPC -32601 (Method not found) response - inconsistent with the stateful/session
server handler.

Root cause

DefaultMcpStatelessServerHandler#handleRequest (in mcp-core) does an early
return Mono.error(McpError.builder(...).build()) for unregistered methods. That bypasses the
onErrorResume a few lines below it, which normally converts handler errors into a JSON-RPC error
response. The error instead escapes to the transport, and both Spring stateless transports map an
escaping handler error straight to HTTP 500.

This is already fixed upstream in modelcontextprotocol/java-sdk:

• Issue: Stateless server handler throws exception instead of returning JSON-RPC -32601 (Method not found) for not registered capabilities modelcontextprotocol/java-sdk#784
• Fix: Fix error behavior on unregistered handlers in stateless server handler modelcontextprotocol/java-sdk#800 (commit 5d3dece)
• Released in mcp-core 2.0.1

However, Spring AI still pins mcp.sdk.version to 2.0.0, both on the v2.0.1 tag and on main
(2.1.0-SNAPSHOT) as of today:
https://github.com/spring-projects/spring-ai/blob/main/pom.xml#L254

So spring-ai-starter-mcp-server-webflux / -webmvc users still hit this 500 today.

Describe the solution you'd like

Bump mcp.sdk.version to 2.0.1 or higher in the BOM/parent POM.

No Spring-side transport code change should be needed: per the maintainer analysis on
modelcontextprotocol/java-sdk#1085, WebFluxStatelessServerTransport
and WebMvcStatelessServerTransport only return 500 because the handler's Mono currently
errors - they .block() it and map any error to 500. Once mcp-core 2.0.1 is on the classpath,
the handler returns a normal JSONRPCResponse carrying -32601 instead of erroring, so the
transports take their regular 200 OK success path with no changes of their own.

Steps to reproduce

1. Start a stateless MCP server with spring-ai-starter-mcp-server-webflux (or -webmvc),
   spring.ai.mcp.server.protocol=STATELESS, with at least one tool registered.
2. POST an unregistered method to the MCP endpoint:

   curl -i http://localhost:8080/mcp \
     -H 'Content-Type: application/json' \
     -H 'Accept: application/json, text/event-stream' \
     --data '{"jsonrpc":"2.0","id":1,"method":"server/discover"}'

3. Observe HTTP 500 with a serialized exception body instead of HTTP 200 with a JSON-RPC
   -32601 Method not found body.

Environment

• Spring AI 2.0.1
• spring-ai-starter-mcp-server-webflux
• mcp-core 2.0.0 (transitive, via mcp.sdk.version)