context.report_progress not sending notifications on streamable-http

[abdhx]

Initial Checks

• I confirm that I'm using the latest version of MCP Python SDK
• I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue

Description

Hello 👋

It seems like context.report_progress is not sending any notifications on streamable-http.
I checked and the reason is that related_request_id is not specified in the underlying function.

A fix that work on my side in the file src/mcp/server/fastmcp/server.py:

async def report_progress(self, progress: float, total: float | None = None, message: str | None = None) -> None:

# <---- non important code is skipped here --->

await self.request_context.session.send_progress_notification(
 progress_token=progress_token,
 progress=progress,
 total=total,
 message=message,

 # ADD this line to fix the issue
 related_request_id=self.request_id,
)

I created a PR to add that line.

Example Code

from mcp.server.fastmcp import Context, FastMCP

mcp = FastMCP("StatelessServer", stateless_http=True)

@mcp.tool()
async def example(ctx: Context) -> str:
 await ctx.report_progress(0, None, "This does not work")
 await ctx.session.send_progress_notification(
 ctx.request_context.meta.progressToken, 0, None, "But this works perfectly", ctx.request_id
 )
 return "Done"

mcp.run(transport="streamable-http")

Python & MCP Python SDK

mcp 1.9.4
Python 3.13.3
uv 0.7.13

[catbbblack]

yes,v1.10.1 has the same question.

[lukebuehler]

can also confirm progress notifications still don't work on 1.10.1 with streamable http

[catbbblack]

i try send post request directy to server without using clientAPI, i get the return progress. you can try it later @lukebuehler
such as {"jsonrpc": "2.0", "method": "tools/call", "params": {"name": "xxx", "argument": {}, "_meta":{"progress_token": "0"}}, "request_id": "0"}
note that: if you use the newest sdk, you need to modify the source code

[fangzhegeo]

Still the same in v1.25.0.

After testing with json_response=False (to enable POST SSE streaming), I observed that:

• Log notifications (info/debug/warning/error) do go through the SSE stream opened by the POST request — they show up right there in real time.
• But progress notifications (report_progress) and sampling requests/responses (from create_message) all end up in the persistent SSE stream opened by the separate GET request.

According to the spec, stuff that's tightly tied to the current tool call (like progress updates and sampling interactions) should go through the POST-initiated SSE, while the GET stream is meant for things unrelated to any running request. I think current implementation violates the spec