streamable-http (type:http) MCP client caches a partial tools/list at init and never re-fetches — long-lived sessions permanently lose a tool

Summary. With a type: http (streamable-HTTP) MCP server, the client fetches tools/list once during initialization and caches it for the session's entire life. If that initial tools/list returns a successful 200 but incomplete toolset (e.g. the server degrades under load and omits some tools), the missing tools are silently absent for the whole session, with no recovery path:

• The client only retries on transient errors (5xx / connection-refused / timeout), not on a valid-but-partial 200.
• The client has no expected-count, so it cannot detect that the list is partial.
• The client does not appear to maintain the GET SSE stream for a type: http server, so notifications/tools/list_changed cannot be delivered to prompt a re-fetch (observed: the server sees zero GET requests on the MCP endpoint).
• There is no re-fetch of tools/list on reconnect/resume.

Impact. A momentary server-side degradation at init (load spike, startup race) becomes a permanent, silent loss of a tool for that session. In our case a governance-gate tool vanished from long-lived sessions, causing an outage that only fresh sessions recovered from — aged/resumed sessions stayed degraded indefinitely.

Requests (any one materially helps):

1. Re-fetch tools/list on reconnect/resume for HTTP transports.
2. Maintain the GET SSE stream for type: http so notifications/tools/list_changed is deliverable (spec-compliant server→client push).
3. Optionally, a client config to force tools/list re-fetch on resume, or to re-init when the toolset shrinks unexpectedly.

Environment. Claude Code, MCP type: http (streamable-http) server, long-lived resumed sessions.