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.