Problem
Consider a client that wants to add a root, then make a tool call that observes the new root.
It first sends a roots-changed notification, then makes the call.
Since roots-changed is a notification, the client gets no response from the server.
Therefore, it cannot be sure that the server processed the notification before it invokes the tool.
Fixing this by imposing restrictions on servers, like all notifications must be processed before any tool calls, will not work in general. In a distributed server, each notification or call may be routed to a different instance, and the messages may arrive out of order. In general, in a distributed system, one-way messages impose no ordering guarantees.
Solution
Roots-changed should be a call instead of a notification.
When the client receives a response from the server, it knows the server has received and processed the change. It can then make the tool call safely.
Problem
Consider a client that wants to add a root, then make a tool call that observes the new root.
It first sends a roots-changed notification, then makes the call.
Since roots-changed is a notification, the client gets no response from the server.
Therefore, it cannot be sure that the server processed the notification before it invokes the tool.
Fixing this by imposing restrictions on servers, like all notifications must be processed before any tool calls, will not work in general. In a distributed server, each notification or call may be routed to a different instance, and the messages may arrive out of order. In general, in a distributed system, one-way messages impose no ordering guarantees.
Solution
Roots-changed should be a call instead of a notification.
When the client receives a response from the server, it knows the server has received and processed the change. It can then make the tool call safely.