Repository navigation
ServerSession methods (create_message, elicit_form) don't expose progress_callback parameter #1671
Description
Summary
The ServerSession high-level methods for sending requests to clients (create_message, elicit_form) don't expose the progress_callback parameter, even though the underlying BaseSession.send_request() fully supports it.
This means servers can't easily receive progress notifications from clients during sampling or elicitation requests.
Current Behavior
# ServerSession.elicit_form() - no progress_callback parameter
async def elicit_form(
self,
message: str,
requestedSchema: types.ElicitRequestedSchema,
related_request_id: types.RequestId | None = None,
) -> types.ElicitResult:
return await self.send_request(...) # progress_callback not passed through
# ServerSession.create_message() - same issue
async def create_message(
self,
messages: list[types.SamplingMessage],
*,
max_tokens: int,
# ... other params ...
related_request_id: types.RequestId | None = None,
) -> types.CreateMessageResult:
return await self.send_request(...) # progress_callback not passed throughExpected Behavior
# Should be able to pass progress_callback
result = await server_session.elicit_form(
message="Please provide your details",
requestedSchema=schema,
progress_callback=lambda progress, total, msg: print(f"Progress: {progress}/{total} - {msg}")
)
result = await server_session.create_message(
messages=messages,
max_tokens=1000,
progress_callback=lambda progress, total, msg: print(f"Sampling progress: {progress}/{total}")
)Context
- The MCP spec supports bidirectional progress notifications - clients CAN send
notifications/progressback to servers during request handling BaseSession.send_request()already supportsprogress_callbackparameterClientSession.call_tool()exposesprogress_callbackfor the client→server direction- The TypeScript SDK exposes this via
RequestOptions.onprogressin bothcreateMessage()andelicitInput() - Tests in
tests/shared/test_progress_notifications.pydemonstrate the bidirectional flow works
Suggested Fix
Add progress_callback: ProgressFnT | None = None parameter to:
ServerSession.create_message()ServerSession.elicit_form()- Any other
ServerSessionmethods that send requests to clients
And pass it through to send_request().
Activity
feat: expose progress_callback in ServerSession.create_message() and …
BryceEWatson commentedon Feb 12, 2026
I'd like to take this on — PR incoming.
I've added
progress_callback: ProgressFnT | None = Nonetocreate_message(),elicit_form(),elicit_url(), and the deprecatedelicit()wrapper onServerSession, plus threaded it through theelicitation.pyhelpers andContextAPI. The approach mirrors howClientSession.call_tool()already handles it.Includes E2E tests for both sampling and elicitation flows. All existing tests pass.
BryceEWatson commentedon Jun 20, 2026
Hi @felixweinberger @maxisbey — this one lost
ready for workand picked upneeds decisionback in April, so rather than leave it in limbo I wanted to ask for a keep-or-close call.A few things that might make the decision easy:
send_request()already acceptsprogress_callbackand maps it toon_progress; theServerSessionconvenience methods (create_message,elicit_form,elicit_url) just don't forward it. The client direction already exposes it (ClientSession.call_tool(progress_callback=...), feat: support progress_callback propagation in ClientSession #1248), so this restores client/server symmetry.progress_callbackkwarg already onServerSession.send_requestandClient.call_tool.Server.createMessage/elicitInputtakeRequestOptions, which carriesonprogress). Python'sServerSessionis the remaining gap.mainand green, every new param defaults toNone(non-breaking), with two E2E tests on the sampling and elicitation paths.I realize the issue isn't
ready for workright now — I'm really just asking whether you'd be open to clearing theneeds decision. "Not until v2 settles" is a perfectly good answer too; I'll keep the branch rebased either way. Happy to add tests or adjust the approach.Disclosure: I used AI assistance on this change. I've reviewed and tested every line, understand the mechanism, and can answer questions on it directly.