Error initializing MCP server: fileno

[tdison71]

Hi,
There seems to be an issue with using MCPServerStdio. The error is "Error initializing MCP server: fileno."

Has anyone seen this error before?

[tdison71]

It appears that the fix for this may be to change the stdout and stderr to PIPE in the anyio->_core->_subprocesses.py->open_process

[Atharva-77]

Did changing to above config worked? @tdison71 did not work for me

[tdison71]

It worked for me but I had the same issue on another machine and tried this and it didn't work there. I think this was probably the final step along with other things I had tried that finally fixed it. I still have the other machine giving me issues. I will try to work it out some more there.

[Atharva-77]

Yeah sure! Thanks for the comment @tdison71 !

[Atharva-77]

Letme know if you find a workaround for this

[Atharva-77]

I was able to get around the issue on the windows by going to this path:
.venv\Lib\site-packages\mcp\client\stdio_init_.py

and making change to this line from:
process = await create_windows_process(command, args, env, errlog, cwd)

to:
process = await create_windows_process(command, args, env, None, cwd)

[srinivasrk]

For me the fix was to change the method call from this

    return await get_async_backend().open_process(
        command,
        stdin=stdin,
        stdout=stdout,
        stderr=stderr,
        cwd=cwd,
        env=env,
        startupinfo=startupinfo,
        creationflags=creationflags,
        start_new_session=start_new_session,
        pass_fds=pass_fds,
        **kwargs,
    )

To replace with

    return await get_async_backend().open_process(
        command,
        stdin=stdin,
        stdout=stdout,
        stderr=None,
        cwd=cwd,
        env=env,
        startupinfo=startupinfo,
        creationflags=creationflags,
        start_new_session=start_new_session,
        pass_fds=pass_fds,
        **kwargs,
    )

Note that the stderr=None, change in file C:\Users\<name>\agents\.venv\Lib\site-packages\anyio\_core\_subprocesses.py

[Carbaz]

You can check this: #1343

I made a PR to monkey patch it on the 4th week notebook, but the code is completely portable.

This prevents the need to edit the library files and you just patch the method during runtime.

This is basically the code added (with explanatory comments):

# Jupyter on Windows has an issue with MCP stdio client due to how Jupyter captures
# "stderr".
#   See: https://github.com/modelcontextprotocol/python-sdk/issues/1103

# The MCP client internally uses "stdio_client()" to create a server process and Jupyter
# replaces "stderr" with a Python object (ipykernel.iostream.OutStream) that can't
# provide a real OS file descriptor, so "subprocess.Popen()" crashes when trying to use
# it.

# When "stderr=None" is passed instead of Jupyter's captured "stderr", the subprocess
# can start correctly.
#   Fix: https://github.com/modelcontextprotocol/python-sdk/issues/1103#issuecomment-3470416291

# Since stdio_client() is called internally by mcp_server_tools() and we can't pass
# parameters to it directly, we monkey patch stdio.stdio_client to always pass
# stderr=errors_file before the MCP session is created.

# With None, the subprocess will bypasses Jupyter's captured stream entirely but error
# logs will be lost, so we pass an already opened file so we can track it to see outputs.

import mcp


mcp.client.stdio._original_stdio_client = mcp.client.stdio.stdio_client
_errlog = open("mcp_stderr.log", "w", buffering=1)
patched = lambda server, *_: mcp.client.stdio._original_stdio_client(server, _errlog)  # noqa: E731
mcp.stdio_client = mcp.client.stdio.stdio_client = patched

Important

This code must be run BEFORE any other import.
(or least before any MCP related import)

EDIT:

I just updated the PR monkey-patch to make it work with week's 6 MCPServerStdio

Warning

Issue: Execution failure when paths contain spaces

The MCPServerStdio implementation (and its underlying mcp dependency) does not correctly escape spaces in the command field.

This is a frequent issue when using npx (often located in ...\Program Files\nodejs\) or uvx if your Python environment path contains spaces.

The Workaround:
Use cmd as the primary command and move the original command into the args list, preceded by the /c flag.

• Instead of:
  playwright_params = {"command": "npx", "args": ["@playwright/mcp@latest"]}

• Use:
  playwright_params = {"command": "cmd", "args": ["/c", "npx", "@playwright/mcp@latest"]}

[krrish612]

This issue is likely caused by Windows/Jupyter replacing stderr with a non-standard stream object that does not expose a valid OS-level file descriptor (fileno()), causing MCP subprocess initialization to fail.

Working runtime-level fix:

import mcp

preserve original stdio client

mcp.client.stdio._original_stdio_client = mcp.client.stdio.stdio_client

patch stderr handling

patched = lambda server, *_: mcp.client.stdio._original_stdio_client(server, None)

apply monkey patch

mcp.stdio_client = patched
mcp.client.stdio.stdio_client = patched

Important:

run this BEFORE importing any MCP-related modules
especially required on Windows + Jupyter/IPython environments

Alternative lower-level fix:
Inside:

anyio/_core/_subprocesses.py

change:

stderr=stderr

to:

stderr=None

Reason:
Jupyter wraps stderr using ipykernel.iostream.OutStream, which breaks subprocess creation because subprocess.Popen() expects a real file descriptor.

Additional Windows path bug:
MCP subprocess execution may also fail when commands contain spaces (e.g. Program Files).

Instead of:

{"command": "npx", "args": ["@playwright/mcp@latest"]}

use:

{
"command": "cmd",
"args": ["/c", "npx", "@playwright/mcp@latest"]
}

because MCP stdio execution does not correctly escape Windows paths with spaces.

[Carbaz]

This issue is likely caused by Windows/Jupyter replacing stderr with a non-standard stream object that does not expose a valid OS-level file descriptor (fileno()), causing MCP subprocess initialization to fail...

@krrish612, Did you really come here just to rephrase my post and present my code as your own? If you're going to plagiarize my content, please do it elsewhere.

Anyway, I've updated both the PR and my previous post to redirect stderr directly to a file so the outputs aren't lost.

[krrish612]

This issue is likely caused by Windows/Jupyter replacing stderr with a non-standard stream object that does not expose a valid OS-level file descriptor (fileno()), causing MCP subprocess initialisation to fail...

@krrish612, Did you really come here just to rephrase my post and present my code as your own? If you're going to plagiarise my content, please do it elsewhere.

Anyway, I've updated both the PR and my previous post to redirect stderr directly to a file so the outputs aren't lost.

I appreciate your concerns, and it was never my intention to diminish them. Your original investigation effectively pinpointed the root cause related to stderr handling in Windows/Jupyter environments, and I should have more clearly acknowledged that critical context.

My primary aim was to validate and expand upon the behaviour from a runtime and debugging standpoint, particularly concerning the interactions with ipykernel.iostream.OutStream, subprocess.Popen(), and the MCP stdio initialisation process.

Your insights regarding redirecting stderr to a file and the Windows command escaping issue provided essential clarifications that enhance our understanding. The cmd /c workaround you mentioned for commands containing spaces holds particular importance for Windows users operating MCP servers via tools like npx.

Thank you for your thorough documentation of the issue and for updating the pull request with a more effective approach. Your efforts truly enhance our work moving forward.
@Carbaz