MCP Apps widgets stopped rendering after staged rollout of server/discover version negotiation (2.1.234)

## Summary

All MCP Apps widgets/applets (tools with `_meta.ui.resourceUri`) from our MCP server stopped rendering in Claude Code mid-evening on 2026-08-20 — with **no client update, no server change relevant to widgets**. Evidence points to a staged server-side rollout activating the new `server/discover` version-negotiation probe, after which Claude Code appears to treat the server as having no app support.

## Timeline (all times local, single machine, CC 2.1.234 installed Aug 18)

- ~21:55 — MCP Apps widgets from our server render fine (as they had for weeks).
- ~22:00-22:40 — no client update (binary unchanged since Aug 18), no relevant server deploy.
- 22:44 onward — **zero widgets render** for any tool of this server, in every new session. Tool calls succeed; the model receives results; the host renders no applet.
- Server logs show Claude Code sending `server/discover` (a method our MCP Python SDK 1.28.x does not know) — the request dies in a pydantic validation cascade:
```
ReadResourceRequest.method
Input should be 'resources/read' [type=literal_error, input_value='server/discover', ...]
...params: {'_meta': {'io.modelcontextprotocol/...'}, 'elicitation': {}}
```
- We then implemented `server/discover` per the 2026-07-28 draft spec (response verified against the published `mcp-2.0.0` / `mcp_types-2.0.0` wheels: `supportedVersions` [honest 1.x list: 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05], live-derived `capabilities`, `instructions`, `resultType: complete`, `cacheScope: private`). Claude Code now receives a valid answer (confirmed in logs) — **widgets still do not render**.

## Evidence it's a staged client-side gate

- `strings` on the CC binary: `server/discover` is present in 2.1.222 (Aug 5), 2.1.233, 2.1.234 — dormant for weeks, activated tonight ⇒ server-side flag.
- Binary strings show the machinery: "Version negotiation probe timed out after", "legacy"/"modern", "Version negotiation failed: the server did not offer pinned protocol version ... via server/discover (no fallback in pin mode)".
- The identical widgets (same `_meta.ui` declarations, same `ui://` templates) render correctly in ChatGPT's MCP Apps host right now — the server side is spec-conformant.

## Questions

1. Is MCP Apps widget rendering now gated on `server/discover` results (e.g., a `capabilities.extensions` declaration)? If so, what must a server on the 1.x Python SDK return to keep widgets rendering?
2. Is there an env var / setting to pin the protocol version or disable the new negotiation as a temporary workaround?
3. If a server answers `server/discover` without offering the 2026-07-28 version (because its SDK is 1.x), is falling back to legacy widget behavior intended? It appears widgets are dropped entirely instead.

## Environment

- Claude Code 2.1.234 (macOS, installed Aug 18; issue began mid-day Aug 20 with no update)
- MCP server: Python SDK 1.28.1, streamable HTTP, OAuth; tools declare `_meta: {"ui": {"resourceUri": "ui://...", "visibility": ["model","app"]}}`
- Reproduces in fresh sessions, both via a local stdio proxy and characteristic of the server generally.

Start by reproducing the failure with Claude Code 2.1.234 and the Python SDK 1.28.1, then inspect the server logs for the server/discover request and response. Done means determining whether version negotiation gates MCP Apps rendering, identifying the required fallback or capability response, and confirming that the widgets render again.

Scritto dal modello di indicizzazione a partire dal testo della issue.