Skip to content

feat(server): expose progress_callback on ServerSession request methods#2164

Closed
giulio-leone wants to merge 2 commits intomodelcontextprotocol:mainfrom
giulio-leone:fix/server-session-progress-callback
Closed

feat(server): expose progress_callback on ServerSession request methods#2164
giulio-leone wants to merge 2 commits intomodelcontextprotocol:mainfrom
giulio-leone:fix/server-session-progress-callback

Conversation

@giulio-leone
Copy link

Problem

BaseSession.send_request() supports a progress_callback parameter for receiving bidirectional progress notifications, and ClientSession.call_tool() already exposes it. However, none of the ServerSession convenience methods (create_message(), elicit_form(), elicit_url()) forward this parameter, so server code cannot receive progress updates from clients during sampling and elicitation without dropping down to raw send_request().

The TypeScript SDK already exposes this via RequestOptions.onprogress in both createMessage() and elicitInput().

Solution

Add an optional progress_callback: ProgressFnT | None = None parameter (defaulting to None) to:

  • create_message() (all overloads + implementation)
  • elicit_form()
  • elicit_url()
  • elicit() (deprecated wrapper — passes through to elicit_form())

The parameter is forwarded to send_request().

Testing

All 475 server tests pass — the new parameter defaults to None (no behavioural change for existing callers).

Closes #1650

g97iulio1609 added 2 commits February 28, 2026 15:41
Add progress_callback parameter to create_message(), elicit_form(),
elicit_url(), and the deprecated elicit() wrapper so that server code
can receive bidirectional progress notifications from the client during
sampling and elicitation requests.

BaseSession.send_request() already supports progress_callback, but none
of the ServerSession convenience methods forwarded it — callers had no
way to pass the parameter without dropping down to send_request().

Closes modelcontextprotocol#1650
@giulio-leone
Copy link
Author

Closing to reduce noise — focusing on the most impactful PRs. Happy to reopen if there's interest.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

DCR Handler Requires Both authorization_code and refresh_token Grant Types (RFC 7591 Non-Compliant)

1 participant