MCP Tool execution hangs indefinitely in stdio mode when calling external Python scripts

[ycycycl]

Describe the bug
When using FastMCP in stdio transport mode, any tool that attempts to execute an external Python script will hang indefinitely until timeout, without returning any result or error. The same code works perfectly when using SSE transport mode.

To Reproduce
Steps to reproduce the behavior:

1. Create a minimal external script (minimal_script.py) that simply prints output and exits

import sys

def main():
    print("Successfully Call!")
    return 0

if __name__ == "__main__":
    sys.exit(main())

2. Create an MCP server with a tool that calls this external script

import os
import sys
import asyncio
import subprocess
from typing import Dict, Any

from mcp.server.fastmcp import FastMCP

# Initialize MCP
mcp = FastMCP("bug_demo")

@mcp.tool()
async def call_external_script() -> Dict[str, Any]:
    """Call external script and return result"""
    # Get script path
    current_dir = os.path.dirname(os.path.abspath(__file__))
    script_path = os.path.join(current_dir, "minimal_script.py")
    
    # Build command
    cmd = [sys.executable, script_path]
    
    try:
        # Execute external command
        process = await asyncio.create_subprocess_exec(
            *cmd,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE
        )
        
        # Wait for process to complete and get output
        stdout, stderr = await process.communicate()
        
        return {
            "success": process.returncode == 0,
            "stdout": stdout.decode().strip(),
            "stderr": stderr.decode().strip(),
            "return_code": process.returncode
        }
    except Exception as e:
        return {
            "success": False,
            "error": str(e)
        }

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

3. Run the server in stdio mode
4. Call the tool (Using MCP Inspector) that executes the external script
5. Observe that the tool call hangs indefinitely with no response

Expected behavior
The tool should execute the external Python script, capture its output, and return the results promptly, regardless of the transport mode used (stdio or SSE).

Screenshots
When using stdio, the tool will hang indefinitely until timeout.

However, correct results can be obtained by using SSE mode.

Desktop (please complete the following information):

• OS: Windows 11 24H2 26100.3775
• Python 3.10.0
• mcp 1.7.1
• asyncio 3.4.3

Additional context
· The issue persists regardless of whether using asyncio.create_subprocess_exec() or subprocess.run().
· I tried printing something in an external py script and found that when calling the tool in STDIO mode, it would be unresponsive, but after timeout, the external py script would be executed and something would be printed out. This is like the running of a py script being blocked until the tool call times out before it can run

[DanielAvdar]

@ycycycl
take a look here: dev-kit-mcp-server
it works smoothly.

[Hellwz]

Met the exact same issue here. The function mentioned by @DanielAvdar solved it perfectly. Thanks a lot!

[atongmuuu]

@Hellwz
Hello, could you provide me with an example to have a look?
The code I wrote by referring to that function still has problems and reports the following error.

the code:

async def create_sub_proccess(cmd: str) -> asyncio.subprocess.Process:
    """Create a subprocess to execute a shell command.

    Args:
        cmd: The shell command to execute

    Returns:
        A subprocess object with stdout and stderr pipes

    """
    process_get = await asyncio.create_subprocess_shell(
        cmd,
        cwd=field(init=False, repr=False).as_posix(),
        stdin=asyncio.subprocess.DEVNULL,
        stdout=asyncio.subprocess.PIPE,
        stderr=asyncio.subprocess.PIPE,
    )
    return process_get


@mcp.tool()
async def plot_by_script(script: str, path: str) -> str:
    """
    Draw through a python script in the form of command-line parameters, input the python script path and file path, draw the image and convert it to base64 format to return.
    :param script: python scripts can pass in a parameter to specify the data path
    :param path: file path
    :return: image base64
    """
    cmd = f"python {script} {path}"
    process = await create_sub_proccess(cmd)
    stdout, stderr = await process.communicate()
    res = {
        "stdout": stdout.decode(errors="replace"),
        "stderr": stderr.decode(errors="replace"),
        "exitcode": process.returncode,
        "cwd": field(init=False, repr=False).as_posix(),
    }
    return res["stdout"]

the error:

⚠️ error: 'coroutine' object has no attribute 'content'
/project/mcp/client.py:151: RuntimeWarning: coroutine 'ClientSession.call_tool' was never awaited
  print(f"\n⚠️ error: {str(e)}")
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

[Hellwz]

Hi @atongmuuu,
I made simple modifications based on your script and used it to call a very simple Python script. It works just fine. Hope it helps.

async def create_sub_process(cmd: str, cwd: str) -> asyncio.subprocess.Process:
    """Create a subprocess to execute a shell command."""
    process_get = await asyncio.create_subprocess_shell(
        cmd,
        cwd=cwd,
        stdin=asyncio.subprocess.DEVNULL,
        stdout=asyncio.subprocess.PIPE,
        stderr=asyncio.subprocess.PIPE,
    )
    return process_get

@mcp.tool()
async def call_script(script_path: str) -> str:
    """Call an external script."""
    current_dir = os.path.dirname(os.path.abspath(__file__))
    cmd = f"{sys.executable} {script_path}"
    process = await create_sub_process(cmd, current_dir)
    stdout, stderr = await process.communicate()
    res = {
        "stdout": stdout.decode(errors="replace"),
        "stderr": stderr.decode(errors="replace"),
        "exitcode": process.returncode,
        "cwd": current_dir,
    }
    return res["stdout"]

[atongmuuu]

@Hellwz
Thank you. I changed the code later and the script has been successfully called.

[Gallaecio]

I can:

• Reproduce the issue.
• Confirm it is a Windows-only issue.
• Confirm stdin=DEVNULL works as a workaround.