Design: concurrency model

[findleyr]

Right now, requests to a single MCP session are serialized by our jsonrpc2 framework, allowing the server to observe requests in logical order.

For gopls, we support a jsonrpc2.Async(ctx) method, similar to t.Parallel(), which allows the request to be handled asynchronously to other requests.

Perhaps this is irrelevant in the context of stateless servers, which will automatically handle requests asynchronously on a separate handler. But it needs to be considered.

[findleyr]

Here's a simple design: the handling of notifications should be synchronous, and the handling of calls should be async.

For example, if I am a client and send a roots/list_changed notification, then a callTool request, I should be guaranteed that the server can observe the root list changed before the callTool request is handled.

On the other hand, it is too easy to introduce a distributed deadlock with synchronous request handling. For example, it would be odd but not impossible for there to be a callTool->sampling->callTool cycle. That is a callTool request blocked on a sampling request, blocked itself on a callTool request.

There is no such problem with distributed deadlock with notifications, because the peer does not wait for a response.

I'm going to implement this. If we ever want to change it, we can add an option that chooses a different behavior. But I think that's unlikely.

CC @jba @samthanawalla

[findleyr]

Another pragmatic rationale for this: consider a long running tool call (for example, waiting for an elicitation), and an asynchronous keepalive ping from the client. We should respond to the ping asynchronously to the elicitation, else the client may kill the connection.

Of course, 'initialize' must always be synchronous.