MCP connector serves a stale tools/list after a server adds tools — only an app relaunch refreshes it (a new conversation and re-issued server/discover do not)

### Summary

When a connected MCP server adds or changes a tool, the Claude Code connector keeps serving the previously cached tool surface for the life of the running app. A new conversation does not pick up the change, and even repeated `server/discover` calls on the wire don't update the usable tool set. Quitting and relaunching the app is what refreshes it. This is a papercut for any MCP server that ships tool-surface changes.

### Environment

- Claude Code desktop app (macOS).
- Remote MCP server over **Streamable HTTP**, OAuth-authenticated.
- The connector negotiated the modern **`2026-07-28`** protocol. (A second client on the same endpoint — ChatGPT Desktop — negotiated legacy `2025-06-18` and did **not** exhibit the problem; see below.)

### What happens

1. The server deploys a release that registers two additional tools (a new capability-contract version).
2. An **already-open** app cannot call the new tools — they're absent from the connector's tool list — while every pre-existing tool works normally.
3. Starting a **new conversation** in the same running app does **not** help.
4. **Quitting and relaunching** the app makes the new tools appear and dispatch normally.

### Why this is a client-side tool-list cache, not a server or scope problem

The server is protocol-correct, verified from its own request/response logs:

- Its `tools/list` result carries the modern cache hint (`ttlMs: 300000`, `cacheScope: public`) as top-level fields.
- The connector **re-issues `server/discover`** against the new release (observed twice within ten seconds), so it *is* re-fetching the surface on the wire — yet the usable tool set stayed frozen.
- It is **not a permission/scope filter**: two tools require the *identical* OAuth scope, one long-standing and one newly added; only the newly added one was missing. The split is by **recency**, not scope.
- The connector held **no `subscriptions/listen` stream**, so a `notifications/tools/list_changed` push had nowhere to land either.

So a correct, fresh server response is received but not applied to the connector's usable tool list until the app process restarts. On the same endpoint, the legacy `2025-06-18` client that re-ran `initialize → tools/list` roughly every 15 seconds stayed fully current — so the endpoint refreshes fine; the behavior is specific to this connector's in-app tool-list cache.

### Recovery ladder (observed)

| Action | Refreshes the tool list? |
| --- | --- |
| New conversation, same running app | No |
| **Quit + relaunch the app** | **Yes** |
| Remove & re-add the connector | Yes (heavier) |

### Expected / requested behavior

Apply a refreshed tool surface without an app restart — e.g., honor the advertised `tools/list` cache TTL as a refresh trigger, or apply the result of a re-issued `server/discover` to the usable tool set. Today, MCP-server authors must tell users to relaunch the app whenever a tool is added, removed, renamed, or reshaped.

### Notes

- The MCP spec does not *require* a client to re-list on any particular trigger, so this is a UX/behavior improvement rather than a spec violation.
- Happy to share additional sanitized protocol traces (request metadata only — no payloads, tokens, or account data) if useful.

No source file or test is named. Start by tracing the connector's server/discover and tools/list handling, including how the advertised cache TTL is applied, then compare it with the relaunch refresh path. Done means an added, removed, renamed, or reshaped tool becomes usable without quitting the app, with coverage for refresh during the same running session.

Escrito por el modelo de indexación a partir del texto del issue.