Fix Windows pipe compatibility in Stdio transport#3
Fix Windows pipe compatibility in Stdio transport#3Getty wants to merge 1 commit intomojolicious:mainfrom
Conversation
The diamond operator (<>) doesn't work reliably with Windows pipes when the MCP server is spawned by applications like Claude Desktop. This replaces <> with a sysread-based line reading approach that works correctly on Windows. The fix also adds proper binmode settings for Windows to handle raw I/O. Tested with Claude Desktop on Windows (Strawberry Perl).
|
I don't understand why this is necessary, I would expect readline to work normally on Windows. |
|
I can just add in that regard, that there was no problem with the stdio in itself, I could use it fine on the cmd.exe directly raw. The problem is when Claude Desktop started it. I tried several ways to avoid as many problems as possible, but nothing was stable. Given that Claude Desktop is literally the application where we need the MCPs running on Win32, this workaround will make it work. Someone with more capabilities could analyze probably what happened there in between, but this patch for sure works, and even tho it would reduce the speed slightly, given the context of what it does, that is not a problem in my eyes, but we would have Win32 Claude Desktop usage covered and can then tell people "hey install strawberry, install mcp-xxxx and use it in Claude Desktop" to promote Perl on Win32 again :D (and of course for the endless commercial cases that this opens). If the speed is really a problem i could adapt the patch to make it an if that just applies this change on win32. |
The diamond operator (<>) doesn't work reliably with Windows pipes when the MCP server is spawned by applications like Claude Desktop.
This replaces <> with a sysread-based line reading approach that works correctly on Windows. The fix also adds proper binmode settings for Windows to handle raw I/O.
Tested with Claude Desktop on Windows (Strawberry Perl).