FastMCP/stdio: in-flight tool responses dropped on stdin EOF when input is bash-redirected from a file

[theone139344]

1. Initial Checks

• I have searched the issue tracker for similar bugs (closest existing: Using transport="stdio" closes real stdio, causing ValueError after server exits #1933, but that's about premature close of real stdio during shutdown — different failure layer)
• I am using a supported MCP SDK version (pinned mcp>=1.27,<2)

2. Description

Triage note: checked jlowin/fastmcp (now PrefectHQ fork) — FastMCP's server-side stdio delegates to mcp.server.stdio via a transport mixin, so the bug belongs here in the SDK rather than in the FastMCP wrapper.

When driving a FastMCP stdio server with a file-redirected stdin (e.g. python -m my_server < payload.jsonl > response.jsonl), in-flight tool-call responses can be dropped if their response writer hasn't been scheduled when stdin EOF arrives.

The stdio read loop appears to treat stdin EOF as an immediate-shutdown signal, cancelling pending writer tasks before they flush their JSON-RPC responses to stdout. The failure is silent — no traceback, no log line, the response is simply absent from stdout.

Expected: All responses for processed requests appear on stdout before the server exits.
Actual: Responses for the last-issued requests can be missing entirely.

3. Example Code (minimal reproducible)

# server.py
from mcp.server.fastmcp import FastMCP
import asyncio

mcp = FastMCP("repro")

@mcp.tool()
async def slow_echo(text: str) -> str:
    await asyncio.sleep(0.05)  # guaranteed yield point so writer scheduling is observable
    return text

if __name__ == "__main__":
    mcp.run(transport="stdio")

# payload.jsonl
{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"repro","version":"0.1"}}}
{"jsonrpc":"2.0","method":"notifications/initialized","params":{}}
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"slow_echo","arguments":{"text":"first"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"slow_echo","arguments":{"text":"second"}}}

python server.py < payload.jsonl > response.jsonl
# Observed: response.jsonl contains id=0 + id=1 results, id=2 is absent.

The race is timing-sensitive; if id=2 surfaces on the first run, increase the asyncio.sleep delay or run repeatedly. We saw it deterministically in production where the tool body did a real HTTP call (~50-200ms).

Diagnostic fingerprint: the difference between this transport race and a quality bug in the tool itself is absence-of-response vs response-with-empty-result. If you ever see id=N missing entirely (not {"id":N,"result":[]}), suspect this race.

4. Python and MCP Python SDK

• Python: 3.12 (python:3.12-slim Docker base)
• MCP SDK: 1.27.x (mcp>=1.27,<2)
• OS: Linux (Debian Bookworm; reproduced on Synology DSM 7.2 host)
• Transport: stdio via mcp.run(transport="stdio")

Workaround we shipped (in case it helps the fix design): wrote a Python driver that owns both pipes via subprocess.Popen(stdin=PIPE, stdout=PIPE) and refuses to close stdin until the response for the last-issued id is observed on stdout. ~140 lines stdlib-only.

Suggested fix: before exiting on stdin EOF, await any pending writer tasks (with a small timeout) so their JSON-RPC responses reach stdout before the process terminates.

[Asti1982]

I think the sharp regression boundary here is: once a JSON-RPC request has been read and accepted, stdin EOF should not be able to cancel the write path before that request's response is flushed.

A focused test could drive stdio with redirected stdin using:

• initialize
• notifications/initialized
• two tools/call requests where the second tool awaits at least once
• captured stdout assertions that response ids 0, 1, and 2 all appear before process exit

A narrow fix shape would be to let stdin EOF close the read side, but keep the stdout writer alive long enough to drain already-queued responses, with a bounded shutdown window so the server cannot hang forever.

The important part is that a missing id=N response is materially different from an error response: clients and replay harnesses may retry without knowing whether the accepted tool call already ran. I can turn this into a focused fix/test PR if maintainers want it.

[mcp-claude]

reproduces on main (616476f) and v1.x (6213787): with file-redirected stdin, responses for tool calls that are still mid-await when stdin EOFs are silently dropped — stderr shows the handlers were dispatched, but stdout only contains the initialize response.

root cause is two-layer. BaseSession._receive_loop (shared/session.py:352) wraps read and write streams in one async with, so read-stream close immediately closes the write stream. then Server.run's finally at server/lowlevel/server.py:410-415 does tg.cancel_scope.cancel(), cancelling in-flight handler tasks before they reach message.respond(). the cancellation path at _handle_request (server.py:503-511) re-raises with no response, and even if a handler raced past it, the write stream is already closed.

a narrow "wait briefly before cancelling" tweak in Server.run isn't enough on its own because the write stream has already closed by the session layer. fix needs to decouple read/write stream lifecycle in BaseSession._receive_loop and adjust the cancel semantics in Server.run without regressing the streamable_http case that the existing comment was written for. flagging as non-trivial for the fix stage.

repro.py

"""Repro for issue 2678: stdin EOF cancels in-flight tool calls before responses flush."""

import json
import subprocess
import sys
import tempfile
from pathlib import Path

SERVER_SRC = '''
from mcp.server.mcpserver import MCPServer
import asyncio

mcp = MCPServer("repro")

@mcp.tool()
async def slow_echo(text: str) -> str:
    await asyncio.sleep(0.2)
    return text

if __name__ == "__main__":
    mcp.run(transport="stdio")
'''

PAYLOAD = [
    {"jsonrpc": "2.0", "id": 0, "method": "initialize",
     "params": {"protocolVersion": "2024-11-05", "capabilities": {},
                "clientInfo": {"name": "repro", "version": "0.1"}}},
    {"jsonrpc": "2.0", "method": "notifications/initialized", "params": {}},
    {"jsonrpc": "2.0", "id": 1, "method": "tools/call",
     "params": {"name": "slow_echo", "arguments": {"text": "first"}}},
    {"jsonrpc": "2.0", "id": 2, "method": "tools/call",
     "params": {"name": "slow_echo", "arguments": {"text": "second"}}},
]


def main():
    workdir = Path(tempfile.mkdtemp(prefix="mcp-2678-"))
    server_py = workdir / "server.py"
    payload_jsonl = workdir / "payload.jsonl"
    response_jsonl = workdir / "response.jsonl"

    server_py.write_text(SERVER_SRC)
    payload_jsonl.write_text("\n".join(json.dumps(m) for m in PAYLOAD) + "\n")

    with payload_jsonl.open("rb") as stdin, response_jsonl.open("wb") as stdout:
        proc = subprocess.run(
            [sys.executable, str(server_py)],
            stdin=stdin, stdout=stdout, stderr=subprocess.PIPE,
            timeout=20,
        )

    lines = [l for l in response_jsonl.read_text().splitlines() if l.strip()]
    received_ids = []
    for line in lines:
        try:
            msg = json.loads(line)
            if "id" in msg:
                received_ids.append(msg["id"])
        except json.JSONDecodeError:
            pass

    print(f"server exit code: {proc.returncode}")
    print(f"received ids: {received_ids}")
    print(f"missing ids: {sorted(set([0,1,2]) - set(received_ids))}")
    print(f"stderr tail: {proc.stderr.decode(errors='replace')[-300:]}")


if __name__ == "__main__":
    main()

(on v1.x, swap from mcp.server.mcpserver import MCPServer → from mcp.server.fastmcp import FastMCP and MCPServer( → FastMCP(.)

command + output

$ uv run python repro.py
server exit code: 0
received ids: [0]
missing ids: [1, 2]
stderr tail:           INFO     Processing request of type            server.py:449
                             CallToolRequest
                    INFO     Processing request of type            server.py:449
                             CallToolRequest

both CallToolRequest log lines confirm the handlers were entered; their responses never reached stdout.

code path

src/mcp/server/stdio.py:49-62 — stdin_reader exits its async for line in stdin on EOF; async with read_stream_writer exit closes the read stream.

src/mcp/shared/session.py:352 — async with self._read_stream, self._write_stream: exit closes both streams together when the receive loop sees the read-stream EndOfStream.

src/mcp/server/lowlevel/server.py:392-415 — async for message in session.incoming_messages exits, and the finally: tg.cancel_scope.cancel() cancels every still-running _handle_message task.

src/mcp/server/lowlevel/server.py:503-511 — _handle_request catches the cancellation. message.cancelled is false (no client-side notifications/cancelled), so the cancel re-raises and no response is sent. even removing the cancel_scope.cancel() wouldn't help on its own because by that point _write_stream is already closed at session.py:352.