Why does server/discover return HTTP 500 on an MCP server?

The server may still be running a 2025-era SDK or request dispatcher that does not implement the 2026-07-28 server/discover method. Confirm the negotiated protocol revision and upgrade or add a dual-era compatibility path instead of treating a generic HTTP 500 as normal negotiation.

Was initialize removed from MCP 2026-07-28?

Yes. The 2026-07-28 protocol removes the initialize/initialized handshake. Protocol version, client identity and client capabilities travel in request metadata instead. Older protocol revisions still use initialize.

Should an MCP 2026-07-28 client send Mcp-Session-Id?

No. Protocol-level sessions and the Mcp-Session-Id header were removed from the 2026-07-28 wire format. Servers that need application state should use explicit server-minted handles or another application-level state mechanism.

How can one MCP endpoint support both 2025 and 2026 clients?

Use an SDK or transport mode that explicitly supports both protocol eras. Current official SDKs can serve initialize-based legacy clients while handling 2026-07-28 requests statelessly on the same endpoint. Test each path independently instead of forcing one era onto every client.

What replaces server-initiated elicitation on a stateless MCP connection?

MCP 2026-07-28 uses Multi Round-Trip Requests. A server can return an input_required result containing input requests and opaque request state, then the client retries the original request with the required responses.

What replaces the old GET/SSE notification stream in MCP 2026-07-28?

The modern protocol uses subscriptions/listen for requested notification streams. A 405 on legacy GET or DELETE paths can therefore be correct for a stateless 2026-07-28 endpoint rather than evidence that the MCP server is down.

Editorial

Research guide · MCP migration · 13 September 2026

MCP 2026-07-28 migration: fix server/discover, Mcp-Session-Id and initialize failures

If a remote MCP server suddenly fails on server/discover, waits for initialize, requires Mcp-Session-Id or breaks behind a stateless client, treat it as a protocol-era migration problem before changing tool logic. MCP 2026-07-28 removed the handshake and protocol session, moved client context into every request, and replaced several connection-bound patterns with explicit request/response mechanisms.

Published 13 September 2026 · sources checked 13 September 2026

2026-07-28

Current stateless MCP protocol revision covered here

server/discover

Optional modern capability-discovery RPC

No session ID

Mcp-Session-Id is removed on the modern wire path

input_required

MRTR result used when a call needs another round trip

Why this is showing up now

Current clients are reaching 2025-era servers with 2026-era expectations

The 2026-07-28 MCP release is a breaking transport and lifecycle shift, not a cosmetic version bump. The official release removes the initialize/initialized exchange and Mcp-Session-Id. Protocol version, client information and client capabilities instead travel with each request, and server/discover can be used when a client wants server capabilities before making another call.

Fresh implementation demand is still arriving. A Microsoft Agent Framework issue opened 10 September 2026 asks for Python support for the stateless revision because its MCP integration is still built around the 2025-era session model. A separate Java SDK report documents OpenAI's hosted MCP client sending server/discover before tools/list; a server on an older SDK returned HTTP 500 and the hosted client surfaced an HTTP 424 connector error.

Those reports are implementation evidence, not new protocol rules. The acquisition-relevant point is practical: an operator can have a valid tool implementation, valid OAuth and a reachable endpoint and still fail before tool discovery because client and server disagree about the protocol era.

Migration map

Replace connection-bound assumptions one boundary at a time

Boundary	2025-era pattern	2026-07-28 pattern	Migration action
Connection setup	initialize → notifications/initialized	No handshake; request metadata carries protocol/client context	Do not wait for initialize before accepting a modern request.
Protocol session	Optional Mcp-Session-Id bound later requests to a session	No protocol-level session or Mcp-Session-Id	Move durable workflow state to explicit application handles where needed.
Capability discovery	Learned during initialize	server/discover is available for upfront discovery	Implement discovery on modern servers and keep clean legacy fallback behavior.
Server-to-client requests	Sampling/elicitation/roots could ride a held-open connection	Multi Round-Trip Requests return input_required and retry	Preserve opaque requestState and correlate the retry to the original operation.
Notifications	Legacy GET/SSE stream and unsolicited delivery patterns	subscriptions/listen for requested notification classes	Do not diagnose a modern GET 405 as a server outage by itself.
Horizontal scaling	Sticky sessions/shared session stores were common	Any request can land on any capable replica	Remove protocol-session affinity, but keep application state explicit and authorized.

Fast diagnosis

Map the failure to the protocol-era boundary first

Signal	Likely boundary	First action
`server/discover → HTTP 500`	The server dispatcher or SDK likely does not understand the modern discovery method.	Check the server SDK revision and modern request path before debugging tools/list or OAuth.
`Hosted client reports 424 external_connector_error`	An upstream MCP call may have failed before a tool was invoked; a failed discovery request is one documented cause.	Inspect the remote server logs for server/discover and protocol-version handling.
`Server says Mcp-Session-Id is missing`	A 2025-era session requirement is leaking into a 2026-07-28 request path.	Branch behavior by negotiated protocol revision instead of requiring a session header globally.
`Server waits forever for initialize`	A modern client may never send the removed handshake.	Accept self-describing 2026-07-28 requests or use a dual-era SDK transport.
`GET /mcp returns 405`	This can be expected on a stateless modern endpoint where POST is the request path and subscriptions/listen owns notifications.	Check the negotiated revision before restoring a legacy GET stream.
`Elicitation hangs or never reaches the user`	A host may still depend on the legacy push-style approval path or lack an interaction surface.	Test MRTR/input_required handling and the host's actual approval/elicitation UI separately.

Repair sequence

Eight checks for a production migration

1. Capture the actual protocol version. Do not infer it from the SDK package name or server URL. Log the negotiated revision without logging credentials or private request data.
2. Test server/discover independently. If the modern client uses discovery, confirm the server handles it as a protocol request rather than falling into an unknown-route HTTP 500 path.
3. Stop requiring initialize on the modern path. A 2026-07-28 request is self-describing. Legacy clients may still initialize; modern ones should not be forced through the old lifecycle.
4. Remove global Mcp-Session-Id assumptions. Do not make a modern request depend on a session ID that the current wire format removed. Keep legacy session behavior scoped to legacy negotiations.
5. Make application state explicit. If a browser run, shopping basket, job or workflow must survive across calls, mint an application-level handle and pass it as an authorized argument. Stateless protocol does not mean state-free applications.
6. Move interaction loops to MRTR. For modern elicitation or other supported server requests, return input_required, preserve the opaque requestState, collect the required response through the host, and retry the original operation.
7. Move notification listening to subscriptions/listen. Keep legacy stream behavior only for clients that actually negotiated the older protocol. Do not reintroduce a session solely because a modern GET stream disappeared.
8. Run a dual-era matrix. Test at least one current 2026-07-28 client and one initialize-based 2025-era client against the same endpoint if backward compatibility matters. Record which features are intentionally unavailable on each path.

State design

Stateless MCP does not require a stateless business workflow

The removed session was protocol plumbing. Your application can still maintain a cart, browser, job, reservation or long-running workflow. The safer migration is to make that state explicit: a tool creates an opaque handle, later tools receive that handle as an ordinary argument, and authorization checks bind the handle to the correct principal and permissions.

This matters for agent commerce and autonomous procurement because hidden connection affinity is a poor place to keep spending context. An explicit purchase or workflow handle can be audited, expired and scoped. Do not place payment credentials or bearer secrets inside the handle merely because it is opaque to the model.

Dual-era compatibility

Do not “fix” a 2026 client by silently forcing everything back to 2025

Current official SDK documentation shows a cleaner migration pattern: serve both revisions on one endpoint where the SDK supports it. Modern requests use the stateless path; legacy clients keep the initialize/session behavior they understand. Current Python SDK v2 documentation describes probing server/discover and falling back to the initialize handshake for an older peer.

That compatibility layer should be explicit and testable. A modern client receiving a legacy session requirement, or an older client receiving only modern routing semantics, is not graceful negotiation. Record the negotiated era and keep transport behavior consistent with it.

If the modern request then fails on Mcp-Method, Mcp-Name or Mcp-Param-*, move to zFinia's HeaderMismatch guide. That is a separate modern-header integrity problem, not evidence that sessions should be restored.

Related zFinia guides

Continue from protocol migration into transport, output and authorization integrity

MCP HeaderMismatch (-32020)
Debug Mcp-Method, Mcp-Name, x-mcp-header and Mcp-Param failures after the modern protocol path is established.
MCP structuredContent and outputSchema
Diagnose tool results that reach the transport but disappear before the model or client consumes them.
MCP OAuth 401/403 troubleshooting
Separate protocol-era failures from Protected Resource Metadata, resource audience and scope problems.
zFinia machine services
Browse machine-readable services and current contracts for agent and machine-economy workflows.

Sources