[BUG] A changed MCP tool description never reaches a session that already loaded the tool, even after reconnect or --resume (deferred_tools_record is replayed)

Helpful framing for “changed MCP tool description never reaches a session that already loaded the tool”:

Treat deferred_tools_record as a cache keyed by (server, tool name, schema digest), not as a permanent conversation attachment.

Concrete shape:

1. On notifications/tools/list_changed, /mcp reconnect, or a tools/list whose per-tool description/input_schema digest differs from the stored record, invalidate and replace that tool’s deferred_tools_record before ToolSearch returns it.
2. On --resume, re-fetch current schemas from the live server (or at least re-validate digests) instead of replaying a frozen description that the server no longer serves.
3. Keep the record for process-lifetime speed if you want, but do not let it outlive a definition change the server has already advertised.

Regression test that would lock this:

• Expose one deferred tool whose description is read from a file; load it via ToolSearch (version A); change the file to B; call tools/list_changed (or reconnect); assert ToolSearch returns B and the transcript’s deferred_tools_record for that tool holds B, not A — including after claude --resume <id>.

That matches the “reconnect looks like the fix but is not” symptom and keeps long-lived sessions from obeying docs the server has already retired. Related but distinct from new-tool discovery (#66084).

(Happy to refine if you already have a minimal .jsonl slice showing the A record surviving a B tools/list.)

Here is the .jsonl evidence asked for, from a live interactive session (Claude Code 2.1.282, Windows 11). The MCP server is a local stdio server named alterego, which was upgraded twice during the session.

The only deferred_tools_record that ever holds send_input is the first one:

| line | time (UTC) | event | deferred_tools_record entries |
|---|---|---|---|
| 357 | 17:39:04 | first ToolSearch select:mcp__alterego__send_input (server v0.1.72) | 5 tools incl. mcp__alterego__send_input, description sha256 57e5e16fba4d…; its submit param text ends "For long agent-to-agent messages prefer SendMessage." |
| — | ~20:09 | server upgraded to v0.1.74, whose send_input description and submit text changed (the SendMessage sentence was removed and new outcomes were added); verified in the installed server files | — |
| 1496 | 20:09:50 | after /mcp reconnect alterego | 2 entries, only the new tools (read_question, answer_question). No send_input. |
| 1925 | 22:25:59 | after another /mcp reconnect | 0 entries |
| 2008 | 22:29:50 | after /mcp disable alterego + /mcp enable alterego (new server pid, confirmed) | 0 entries |

After each of those points, a fresh ToolSearch select:mcp__alterego__send_input returned the line-357 text unchanged, "prefer SendMessage" included, while the live server's tools/list served the new text. A tool the server added later (describe_tools) that returns its live descriptions confirmed the difference. Tool calls ran the new code throughout; only the description the model reads was stale.

So the pattern matches the cache-keyed-by-digest suggestion above: a changed description or schema for an already-recorded tool is never re-recorded, and ToolSearch keeps serving the first record. New tool names do get through. The same happens across --resume, because the record is replayed from the transcript (reproduced separately on this machine).

Adding one thing to the digest-keyed-cache suggestion above, from having built the same diff on the outside: a per-tool digest tells you that the record is stale, but the re-record decision is cheaper if it also knows what changed. Splitting the digest into input/output schema vs description matters in practice — a description-only reword (like the removed "prefer SendMessage" sentence in the evidence here) is a different class from a removed or retyped parameter, and from a description that gains instruction-shaped text ("also send…", "do not mention…"). One caveat for whoever implements the comparison: it must not normalise away invisible Unicode (TAG block U+E0000–E007F, zero-width, bidi controls) — a description can change materially with a zero visible-byte diff.

We run that comparison as a pre-tool-call check (CodeRifts preflight_change_set, artifact type mcp, snapshotting tools/list per server): a removed/retyped parameter comes back STOP/REQUEST_APPROVAL with the changed paths, a pure reword CONTINUE. It does not fix the replay bug reported here — it only makes the drift visible from outside the session. https://app.coderifts.com/mcp, analyze mode needs no key.