You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MCP tools/list_changed notification: updated tools not visible to the model until the next user turn #3125
When an MCP server emits a notifications/tools/list_changed notification mid-turn, the updated tool list is not visible to the model until the next user turn.
Repro / observed behavior
User sends a message; the agent loop starts.
The model calls a tool on an MCP server; that tool causes the server to add/remove a tool and emit notifications/tools/list_changed.
The agent loop continues with another model iteration in the same turn.
The model still sees the old tool list. Newly added tools are not callable; removed tools are still advertised.
On the next user message, the new tool list finally becomes visible.
Affected version
1.0.41-1
Steps to reproduce the behavior
User sends a message; the agent loop starts.
The model calls a tool on an MCP server; that tool causes the server to add/remove a tool and emit notifications/tools/list_changed.
The agent loop continues with another model iteration in the same turn.
The model still sees the old tool list. Newly added tools are not callable; removed tools are still advertised.
On the next user message, the new tool list finally becomes visible.
Expected behavior
The model can see the new newly added tools without requiring another user->model conversation turn.
This is required in order to support MCP servers that implement progressive disclosure of tools server-side.
The transport layer already observes and can forward MCP list_changed notifications (src/mcp-client/mcp-host.ts emitListChanged, src/mcp-client/mcp-registry.ts setListChangedCallback), but no production caller was found wiring that callback into a per-model-iteration tool-list refresh inside an in-progress turn -- only test doubles register it. That matches the reported symptom: the new list only becomes visible on the next user turn.
This needs the exact per-iteration tool-list capture point confirmed in the agent loop, plus a decision on the refresh boundary (since re-reading tool definitions mid-turn can affect prompt caching), before it is ready to implement.
Route: developer-needed.
This triage summary was prepared with GitHub Copilot and reviewed before posting.
This appears to be resolved as of GitHub Copilot CLI v1.0.88. Please update to that release or a newer stable version. We're closing this as completed. If it still happens, please comment with your version and reproduction steps.
Activity
gokhanarkan commentedon Jul 23, 2026
Triage summary
The transport layer already observes and can forward MCP list_changed notifications (src/mcp-client/mcp-host.ts emitListChanged, src/mcp-client/mcp-registry.ts setListChangedCallback), but no production caller was found wiring that callback into a per-model-iteration tool-list refresh inside an in-progress turn -- only test doubles register it. That matches the reported symptom: the new list only becomes visible on the next user turn.
This needs the exact per-iteration tool-list capture point confirmed in the agent loop, plus a decision on the refresh boundary (since re-reading tool definitions mid-turn can affect prompt caching), before it is ready to implement.
Route: developer-needed.
This triage summary was prepared with GitHub Copilot and reviewed before posting.
copilot-cli-bot commentedon Sep 27, 2026
This appears to be resolved as of GitHub Copilot CLI v1.0.88. Please update to that release or a newer stable version. We're closing this as completed. If it still happens, please comment with your version and reproduction steps.