Server hangs when shutting down if a connection is still open

[lindycoder]

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!

I was testing my MCP server with the inspector npx @modelcontextprotocol/inspector using streamable-http and I noticed that if the inspector is connected, the MCP Server will not shutdown.

We can't keep the server running if a client forgot to disconnect right? This is tested with the official inspector tools, so there might be other clients working the same way.

Shouldn't the server close its active connections/tasks on shutdown?

Reproduction

1. Run the server (see code snippet)
2. In the MCP Inspector click "connect"
3. In the server's terminal hit CTRL+C

At this point

• The server shows Waiting for connections to close (CTRL+C to force quit) and CTRL+C doesn't work, in fact nothing works except killing the process
• Clicking "Disconned" in the Inspector cannot disconnect, because Error in /mcp route: TypeError: fetch failed

Evidences

Shell execution

$ python demo-mcp.py 
INFO: Started server process [10749]
INFO: Waiting for application startup.
[08/14/25 11:03:16] INFO StreamableHTTP session manager started streamable_http_manager.py:110
INFO: Application startup complete.
INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
[08/14/25 11:03:21] INFO Created new transport with session ID: 4134f60ccda44baf8a01733ed94bc0d8 streamable_http_manager.py:233
INFO: 127.0.0.1:54629 - "POST /mcp HTTP/1.1" 200 OK
INFO: 127.0.0.1:54629 - "POST /mcp HTTP/1.1" 202 Accepted
INFO: 127.0.0.1:54630 - "GET /mcp HTTP/1.1" 200 OK
^CINFO: Shutting down
INFO: Waiting for connections to close. (CTRL+C to force quit)

Inspector proxy Disconnect error

Received DELETE message for sessionId dd8a78d2-d5a8-4ff2-b679-6a8571f7cd0c
Connection refused. Is the MCP server running?
Error in /mcp route: TypeError: fetch failed
 at node:internal/deps/undici/undici:13502:13
 at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
 at async StreamableHTTPClientTransport.terminateSession (file://.../.npm/_npx/5a9d879542beca3a/node_modules/@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:355:30)
 at async file://.../.npm/_npx/5a9d879542beca3a/node_modules/@modelcontextprotocol/inspector/server/build/index.js:264:17 {
 [cause]: Error: connect ECONNREFUSED 127.0.0.1:8000
 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1636:16) {
 errno: -61,
 code: 'ECONNREFUSED',
 syscall: 'connect',
 address: '127.0.0.1',
 port: 8000
 }
}

Mitigation

Setting the timeout_graceful_shutdown uvicorn config to a few seconds will eventually quit the process, BUT this is exiting with a non 0 exit code, which is an issue trying to run this in production. (This setting has been request here and currently available in FastMCP 2.0)

Example Code

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("demo")

@mcp.tool()
async def hello() -> str:
 return "world"

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

Python & MCP Python SDK

Python 3.12.8
mcp 1.12.4

Edit: reproduced with mcp 1.13.0

[davidroeca]

I can confirm that this happens while working with the ai sdk as well. I'll poke around and reply back if I can find the culprit or at the very least set up a minimal repro

Edit: my immediate issue is a bit of a docs issue with the AI sdk, likely separate from this one (they recommend some messy patterns for opening/closing mcp connections per-request, so their current experimental implementation requires additional bespoke code to run efficiently).

[giulio-leone]

I have a fix for this in #2181. The PR adds graceful session termination during shutdown — when the server receives a shutdown signal, it cancels active sessions instead of waiting indefinitely for clients to disconnect.