Under the hood
MCP tool-list refetches now use a debounced, backed-off scheduler instead of firing on every change notification
What
When an MCP (Model Context Protocol) server sends repeated list_changed notifications that its tool list has changed, a new scheduler now coalesces rapid successive notifications into a single refetch instead of triggering one refetch per notification. If a refetch fails, the wait before the next attempt doubles, up to a capped maximum.
Why
This avoids hammering an MCP server with repeated refetch calls when it sends a burst of change notifications, and backs off automatically if refetching keeps failing.
One source agreesOne thing we can check says the same as this entry.
Anthropic's release notes agree
Fixed sustained high CPU usage and repeated tool-list requests when an MCP server sends list_changed notifications in a tight loop