MCP Custom Tool: SSE fallback always fails with 'Invalid response body, expected a web ReadableStream' (node-fetch v2 body is not a web ReadableStream) · Issue #6715 · FlowiseAI/Flowise · GitHub
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 13, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 13, 2026. It is now read-only.
MCP Custom Tool: SSE fallback always fails with 'Invalid response body, expected a web ReadableStream' (node-fetch v2 body is not a web ReadableStream) #6715
Connecting a Custom MCP tool to any remote SSE server (URL with sse transport) always fails with:
Failed to connect to Custom MCP server: SSE error: Invalid response body, expected a web ReadableStream
Root cause (traced in flowise-components 3.1.4)
In flowise-components/dist/nodes/tools/MCP/core.js, MCPToolkit.createClient() first tries StreamableHTTPClientTransport, and on failure falls back to SSEClientTransport with a custom fetch:
node-fetch v2 represents a streaming response body as a Node.js PassThrough stream. The MCP SDK's SSEClientTransport hands the response to the eventsource package, which hard-requires a web ReadableStream and rejects any other body shape (its check: if (typeof body !== 'object' || !body || !('getReader' in body)) failConnection(...)). A PassThrough has no getReader, so every SSE connection fails — regardless of which server is behind the URL. This reproduces against any spec-compliant MCP SSE server (tested against the MCP SDK's own SSEServerTransport).
How to reproduce
Run any MCP SSE server (e.g. an apigen/@modelcontextprotocol/sdkSSEServerTransport at http://127.0.0.1:3100/sse).
Add a Custom MCP tool with config {"url": "http://127.0.0.1:3100/sse"}.
Load Available Actions / run the flow → the error above.
Suggested fix
Convert secureFetch's node-fetch body to a web ReadableStream before handing it to the SSE client (Node's staticstream.Readable.toWeb(stream) — there is no instance .toWeb()). Minimal patch, verified working against a live SSE server:
Hi @maintainer, I’d like to work on this issue as my first contribution to Flowise. I’ve reviewed the issue and would like to investigate the SSE fallback and the ReadableStream compatibility problem, then submit a fix with appropriate tests. Is this issue still available for contribution?
Activity
mahi-in9 commentedon Aug 9, 2026
Hi @maintainer, I’d like to work on this issue as my first contribution to Flowise. I’ve reviewed the issue and would like to investigate the SSE fallback and the ReadableStream compatibility problem, then submit a fix with appropriate tests. Is this issue still available for contribution?