A sampling flow is essentially a ping pong between client and server to generate detailed generations. But, a sampling flow will never just 'end' as a result in the MCP server, it needs to be handled.

To make this effective, my current implementations go like this.

a/ Each tool has a type (sampling or standard)
b/ Standard tools receive tool request, 'do stuff' and return result
c/ Sampling tools receive tool request, 'generate async sampling request' and return 'waiting'
d/ Client receives sampling request, get's user input and generates response
e/ Sampling response is returned to MCP server.

To actually make this process useful, I add _callbacks to the _meta of the sampling request/response.

When an MCP server receives an MCP Sampling response with a callback, it 'does stuff', which is usually the important LLM magic. This requires me stuffing the '_meta' of my sampling response with _callbacks and schemas.

This does not seem the correct use of metadata, but we need some way, especially for sampling flows, to execute business logic based on the response in the server.

Fwiw I encountered usecases for similar functionality frequently when using chatgpt's python interpreter sandbox eg when doing some string processing and wanting to make use of LLM capabilities per string, within the python codebase.