MCP Client Node Error: stream is not readable when connecting to custom MCP server

Questions
1

Hi n8n community,

I’m experiencing a consistent error when trying to use the MCP Client node to connect to my custom MCP server built with the ModelContextProtocol SDK.

The Error

When attempting to connect to my MCP server, I receive the following error:
“Failed to execute operation: Failed to connect to MCP server: Error POSTing to endpoint (HTTP 400): InternalServerError: stream is not readable”

My Setup

  • n8n version: 1.86.1 (Self Hosted)

  • MCP Client node configuration:

  • Server Implementation:

    • Built with ModelContextProtocol SDK
    • Express server with SSE transport
    • Correctly registers tools using the MCP SDK
    • Server is accessible and responds to direct curl requests to the SSE endpoint

What I’ve Tried

  • Verified the server is working correctly with direct curl requests
  • Made various modifications to the server’s SSE implementation
  • Attempted to prevent the stream from closing during message handling
  • Ensured proper CORS configuration

Server Logs

When n8n attempts to connect, I see the following in my server logs:
[Include relevant logs showing SSE connection and any errors]

Has anyone encountered similar issues with the MCP Client node? Are there any known workarounds or fixes for the “stream is not readable” error?

Any assistance would be greatly appreciated!

2

I would point to testing further with GitHub - modelcontextprotocol/inspector: Visual testing tool for MCP servers

As it seems mcp server maybe facing issue, it could also be an issue with the sse URL ie its hosted with railway, maybe try testing locally first rule out if it because of railway etc.

adding to watch, like to see the resolutions for this.

3

thanks for the response Samuel when i build my mcp server i create the stdio transport dor claude desktop and sse transport for n8n. The stdio transport work in n8n but locally my goal is to use sse to get tools in n8n

Capture
Capture1366×603 39 KB

Capture2
Capture21366×605 23 KB

4

I have a similar problem and I think it has to do with the fact that the n8n MCP client uses SSE as the transport standard, but this mechanism has been deprecated in the latest version of MCP. This Github issue is related: https://github.com/n8n-io/n8n/issues/16240.