modelcontextprotocol / modelcontextprotocol/python-sdk
`stdio_server` uses unbuffered memory streams which can cause server to block and become unresponsive
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 24.3k
- Forks
- 4k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 31
Description
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
The MCP Python SDK's stdio_server becomes unresponsive during slow message processing operations, causing ping and/or new requests to timeout.
Observed Behaviour
- Server appears to 'freeze' and becomes unresponsive after running for extended periods
- Ping requests timeout during slow operations
- New requests cannot be processed while the server is handling long-running operations
- After 67 minutes of operation with requests every 10 seconds, the server became completely unresponsive
Expected Behaviour
- Server should remain responsive to new requests (like pings) even while processing slow operations
- Ping requests should not timeout due to message processing delays
- The server should handle concurrent requests without blocking
Suspected Root Cause
The stdio_server uses max_buffer_size=0 (supplied to anyio.create_memory_object_stream) by default, which creates synchronous handoff between the stdin reader and message processor.
When the message processor is slow or blocked, the stdin reader cannot read new messages from stdin, making the server appear unresponsive.
Example Code
import anyio
import pytest
@pytest.mark.anyio
async def test_server_becomes_unresponsive_with_slow_processor():
"""Demonstrates how server becomes unresponsive during slow processing."""
# Simulates stdio_server with default max_buffer_size=0 (synchronous handoff)
send_stream, receive_stream = anyio.create_memory_object_stream(0)
async def stdin_reader():
# First message gets through
await send_stream.send("request_1")
# Second message (like a ping) blocks until first is fully processed
await send_stream.send("ping") # This will block for entire processing time!
async def message_processor():
# Process first message
msg = await receive_stream.receive()
# Simulate slow processing (database query, API call, etc.)
await anyio.sleep(0.1) # 100ms processing time
# During this time, stdin_reader is completely blocked
# No new messages (including pings) can be read!
ping = await receive_stream.receive() # Finally unblocks stdin_reader
async with anyio.create_task_group() as tg:
tg.start_soon(message_processor)
await anyio.sleep(0.01) # Let processor start waiting
tg.start_soon(stdin_reader)
send_stream.close()
receive_stream.close()
Proposed Solution
Allow users to configure max_buffer_size > 0 to enable buffering, with a default value (0) that preserves the current behaviour.
async def stdio_server(
stdin: anyio.AsyncFile[str] | None = None,
stdout: anyio.AsyncFile[str] | None = None,
max_buffer_size: int = 0,
):
# ...
read_stream_writer, read_stream = anyio.create_memory_object_stream(max_buffer_size)
write_stream, write_stream_reader = anyio.create_memory_object_stream(max_buffer_size)
Python & MCP Python SDK
- Python: 3.12
- MCP Python SDK: 1.12.4
- OS: macOS
Additional Context
The issue manifests in long-running servers where message processing can occasionally be slow (database queries, file operations, API calls).
The fix should make max_buffer_size configurable so users can add buffering to prevent the stdin reader from blocking during slow operations.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/mcp/server/stdio.py at the referenced memory-stream setup and inspect how max_buffer_size is passed to both streams. Make the buffer size configurable as described, preserving the current default, and verify that a positive value allows input buffering during slow processing using the provided async example.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100