Skip to content

Conversation

@davemssavage
Copy link

@davemssavage davemssavage commented May 31, 2025

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

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

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.

@davemssavage davemssavage changed the title Feature/disconnected tasks feature: async tool call with join for disconnected clients and progress resources May 31, 2025
…eeked line style for mermaid diagrams for legibility
@bzsurbhi
Copy link

bzsurbhi commented Jun 4, 2025

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?

@davemssavage
Copy link
Author

davemssavage commented Jun 6, 2025

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?

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.

https://github.com/modelcontextprotocol/modelcontextprotocol/pull/617/files#diff-273099cbfa5ca22c6af97f73eca738047952f7a8e7dffc4c1572fec3bdbbc211R324

I've written a unit test to prove this is implementable here:

https://github.com/davemssavage/python-sdk/blob/feature/617-async-call-tools/tests/server/lowlevel/test_async_request_manager.py#L239

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

No open projects
Status: Draft

Development

Successfully merging this pull request may close these issues.

3 participants