feature: async tool call with join for disconnected clients and progress resources #617
+470
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…un in the background and reconnected to later
… protocol elements
9 tasks
8 tasks
…eeked line style for mermaid diagrams for legibility
This was referenced May 31, 2025
9 tasks
…no longer provided
|
How does the client poll the status of the operation? To get progress notification, the client will have to be maintain a sse connection right? |
This was referenced Jun 5, 2025
…p to progressNotifications
I guess I should make this clear in the text description, no in this in this proposal the the CallToolAsyncResult returns a new value called an AsyncToken that the client can persist and use to rejoin later, this can be a completely different sse connection. I've written a unit test to prove this is implementable here: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Work in progress exploring ideas around async tool calls inspired by thread of conversation here: #549 (comment)
Motivation and Context
Long running async tasks on the server rely on a continous connection to the server, also they have limited options for notification of progress.
This update to the specification allows clients to submit async tool call requests to the server and for the server to respond with resources as well as messages to update the client. Resources might include information such as detailed metrics for tasks such as training machine learning models or validation outputs such as images in the case of generative AI models.
Clients can join an existing in progress call tool and it is suggested the server should support multiple clients that can subscribe to progress notifications for the same async request. This complexity is suggested as less than the complexity of figuring out which of several client should be dropped and how to notify the client that has been dropped it will no longer receive progress notification updates.
How Has This Been Tested?
Work in progress on python impl is here: modelcontextprotocol/python-sdk#866
Breaking Changes
None, the protocol updates are entirely optional for the server and are backwards compatible with clients. Clients that support this function should use the capabilities async block to check if the server supports this behaviour prior to sending an async call tool request.
Types of changes
Checklist
Additional context
I did debate adding a new notification type for the server to inform the client if it sends a request that the server does not support, on reflection an MCP error is probably less of a breaking change
Other suggestions in this area have suggested reusing the Resource protocol for this behavior #549 (comment). The approach used in this RFC is suggested as preferrable as using Resource would make it non-obvious how to support an async structuredContent CallToolResult as a Resource.