Add a pattern for a deferred tool resulting using UI interaction

[connor4312]

Motivation and Context

This is a pattern I've been asked about a few times already, so adding a reference for it.

How Has This Been Tested?

N/A

Breaking Changes

N/A

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

[jonathanhefner]

Interesting pattern! Basically, elicitation implemented as an MCP App! Although, for servers using the SHTTP transport, I think it might cause similar reliability issues (around long-running requests, server affinity, etc). What are your thoughts about that?

[connor4312]

Yup essentially fancy elicitation.

I think the way to tackle reliability is to have the servers set a taskHint for clients that support it 🙂 I'll add mention of this to the example.

[liady]

Nice use case @connor4312 (definitely one that's been asked a lot)!
Agree that the long-running tool issue can be tricky here, and perhaps a task-based implementation will make the pattern too complex?
But a really cool idea, interweaving the two tools like that in the app

[connor4312]

Maybe, I think right now implementing task support in a server using the TS SDK is a bit complicated. But I know they're still working on it and in theory an SDK (or helper library) could abstract common patterns enough that implementing a task-based tool for a server is not much more expensive than implementing any other kind of tool call. Ideally one would just plug in their choice of persistence layer (memory/redis/etc) into a tool definition and be good to go.