{"version":"2.1.221","anchor":"list-changed-refreshes-can-be-synthesized-after-a-listen-str","canonical_anchor":"list-changed-refreshes-can-be-synthesized-after-a-listen-str","heading":"list_changed refreshes can be synthesized after a listen stream reopens","tier":"internal","area":"MCP","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.221\/e\/list-changed-refreshes-can-be-synthesized-after-a-listen-str","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.221","markdown":"### list_changed refreshes can be synthesized after a listen stream reopens\n\nClaude can now tell whether an MCP tool list refresh came from a reconnect or a server notification.\n\n**What**\n\nRefresh handlers now know why they ran, so a refetch caused by a reconnect is distinguishable from one caused by a server notification.\n\n**Details**\n\n- Tools, prompts and resources refresh handlers take a cause argument.\n- When the refetch came from a listen-stream reopen rather than a notification, the debug log says so.\n- The `tengu_mcp_list_changed` event carries a new `cause` field.\n- The prompts and resources events moved: they are now emitted after the refresh completes instead of before it starts.\n\n**Evidence**\n\n`Synthesized tools refetch after listen-stream reopen (no notification received)`\n\n- Area: MCP\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 0\/5"}