Let hosts own independent client connections and cancel async calls

I’m looking at using mcptools with mcp-repl to give a Deputy agent an R or Python session that persists across tool calls.

In a Shiny app, I’d like two agents to keep separate interpreter state, even when both use the same server configuration. The host would own each connection, close it when the conversation ends, and let the user cancel a long-running call while the app stays responsive.

The current client registry identifies connections by configured server name. Loading that name again closes the previous connection, so I can’t use the name alone as the ownership boundary for two independent agents. Tool invocation also waits synchronously for the response; sending an R interrupt is useful, but doesn’t by itself give a Shiny host an asynchronous call it can cancel.

Would a client connection object with an explicit lifetime fit the direction of mcptools? I’d like to reuse its transport and cancellation handling, with mcp-repl continuing to own interpreter execution and reset behavior.

This seems related to #86 and #109. My use case is the client connection to an external server, rather than the server-side async handlers in #118. I’m tracking the Deputy work in JamesHWade/deputy#69 and JamesHWade/deputy#48.

Start by reviewing the current client registry and synchronous tool invocation, then compare the related discussions in #86, #109, and #118. Done would mean defining whether hosts can own independent client lifetimes and cancel asynchronous calls while preserving the existing transport and cancellation handling.