Backport server/discover / METHOD_NOT_FOUND fix (-32601) to pre-2.0 lines — HTTP 500 has no remedy without Spring Boot 4 migration #1085

Summary

The server/discover → HTTP 500 regression (unknown JSON-RPC method throws instead of returning -32601 Method not found) currently has no remedy for users on the pre-2.0 release lines. The known fixes all target 2.0.x:

• Stateless server handler throws exception instead of returning JSON-RPC -32601 (Method not found) for not registered capabilities #784 — "Stateless server handler throws exception instead of returning JSON-RPC -32601" — closed, milestoned to 2.0.1.
• [2026-07-28] Java SDK 2.0.0 returns HTTP 500 for OpenAI server/discover requests #1072 — "[2026-07-28] Java SDK 2.0.0 returns HTTP 500 for OpenAI server/discover requests" — open, against 2.0.0; PR fix: return HTTP 404 for METHOD_NOT_FOUND in stateless transport (#1072) #1083 fixes the 2.0.x stateless transport.

This issue asks for the fix to also be made available to users still on 0.x / 1.x.

Why this matters for pre-2.0 users

OpenAI's hosted MCP connector now sends server/discover during its handshake (before tools/list). On the pre-2.0 SDK the stateless transport responds:

Missing handler for request type: server/discover   → HTTP 500

OpenAI surfaces that 500 as HTTP 424 external_connector_error, which aborts the entire response — even for a plain "hi" that needs no tool call. In practice this takes an MCP server completely offline for the OpenAI Responses API connector the moment the client starts probing, with no application-side cause. The documented backward-compat behavior is to return -32601 so the client falls back to the legacy initialize flow, and that fallback lives in the SDK's request handling, not in application code — so downstream apps cannot fix it without patching or replacing the SDK.

The only forward path today is upgrading to 2.0.x. For Spring AI consumers that is not a version bump: spring-ai 2.x requires Spring Boot 4 / Spring Framework 7, a framework-wide migration. Concretely, we are on spring-ai 1.1.4 (MCP Java SDK 0.17.0) on Spring Boot 3.x, and a trial bump to spring-ai 2.0 compiles and passes unit tests but fails to boot (NoClassDefFoundError: org.springframework.core.Nullness, a Framework 7 class). So a spec-compatibility regression triggered by a client-side change is effectively gating a large, unrelated framework migration.

The ask

Either of the following would resolve it for pre-2.0 users:

1. Backport the METHOD_NOT_FOUND / -32601 handling to a maintained pre-2.0 line and cut a patch release. This is consistent with lines the project already maintains — 0.18.3, 1.0.2, and 1.1.3 all shipped in May–June 2026, so this is not asking to revive an EOL branch.
2. Or publish an officially documented interim compat handler for the stateless transport — i.e. a supported way to make unknown methods (notably server/discover) return -32601 Method not found / a non-500 without upgrading. Consumers are currently doing this ad hoc with a servlet filter in front of the SDK; a documented, blessed pattern would be preferable to everyone reinventing it.

Environment

• MCP Java SDK: 0.17.0 (via spring-ai 1.1.4)
• Spring Boot 3.x / Spring Framework 6.2.x
• Client: OpenAI hosted MCP connector (Responses API), protocol revision 2026-07-28

References

• Stateless server handler throws exception instead of returning JSON-RPC -32601 (Method not found) for not registered capabilities #784 (fix milestoned to 2.0.1)
• [2026-07-28] Java SDK 2.0.0 returns HTTP 500 for OpenAI server/discover requests #1072 + PR fix: return HTTP 404 for METHOD_NOT_FOUND in stateless transport (#1072) #1083 (2.0.x server/discover 500 fix)