feat(MCP Client Tool Node): Add support for HTTP Streamable Transport - #15454
Conversation
|
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
mrge found 2 issues across 1 file. Review them in mrge.io
| requestInit: { headers }, | ||
| }); | ||
| await client.connect(transport); | ||
| console.log('Connected using Streamable HTTP transport'); |
There was a problem hiding this comment.
Using console.log instead of the logger system that's used elsewhere in the codebase
n8n-assistant
Bot
added
community
|
Hey @KGuillaume-chaps, Thanks for the PR, We have created "GHC-2033" as the internal reference to get this reviewed. One of us will be in touch if there are any changes needed, in most cases this is normally within a couple of weeks but it depends on the current workload of the team. |
|
I'd wager this is the highest requested feature ? I don't see a lot of registries supporting SSE anymore, would be great to have Streaming HTTP support in soon! |
It has 123 votes. So, definitely not in the top 10 most requested features.
Do you have source for that claim? Considering how the Websocket transport was initially implemented in the MCP SDK and then dropped without any serious community conversation around it, I'd suggest that everyone working on this to go slowly, not surrender to the MCP mania, and avoid rushing MCP related features at a priority, to avoid maintainer burnout 🙏🏽. I'll bring this PR up internally to see if someone can review this as soon as there is someone available. |
|
@netroy appreciate you escalating this internally! But this feels like a pretty out-of-touch take. SSE might be “technically” supported, but top registries like smithery.ai have already moved to streaming HTTP — and do not support SSE. And let’s be honest — citing “maintainer burnout” when n8n has raised $60M+ doesn’t hold water. This isn’t a volunteer project. If community-backed protocol features like MCP streaming are being stalled, that’s a product/org decision — not a resourcing issue. Streaming HTTP is where the ecosystem’s going. Happy to be proven wrong if you can point to any robust registry still backing SSE at scale. I don't need to cite data sources to prove my point, my anecdotal evidence is already reflected on your community threads. Thanks again for pushing this forward. |
|
Yep I agree, this is needed else n8n will become much less useful as a backend for ai apps. |
|
@netroy it's a top 3 most voted feature now |
|
Streamable HTTP transport support is already being added for servers here. |
|
also, please don't |
ShireenMissi
left a comment
ShireenMissi
left a comment
There was a problem hiding this comment.
Thanks @KGuillaume-chaps for the PR 🙏
I left some comments. also please add test for the changed lines pf code
|
I'm not sure what to test for or how to run the test suite. On my machine running npm run test fails with the following message :
|
|
Hi there, I've been running my production cluster on this branch for the past weeks, can't wait for it to be merged 🙏 |
|
Looks great, thanks for the contribution! 🙌 Hope to see it merged soon. 🚀 |
|
Looking forward to getting this merged |
|
👍 Please do consider prioritizing this request. |
|
Looking forward to this feature to be released! |
|
Excited for this to get in :) |
|
Excellent, will update my n8n in the next minutes this gets released! :) |
|
I'm looking forward to it |
|
any ETA when this will be merged? thinking about self-hosting n8n and using a non-verified community node. However i would ideally want to avoid this. |
|
@rfiala , which community node are you considering for this? me too. also considering running off of this branch to give some evidence that this is ready to merge |
i just moved to a self-hosted instance and installed this one: however i feel this is not exactly what i need as i need to add an explicit "execute tool" method for every tool available which i find weird. i thought it would work exactly the same as the mcp client on n8n where the agent decides which tool it is using |
RomanDavydchuk
left a comment
RomanDavydchuk
left a comment
There was a problem hiding this comment.
Thanks for incorporating the changes I've requested! I took another look and tested the code manually, looks like it works, good job. There are just a few more small changes I'd like you to make, once those are in, I think this can be merged
|
We are cheering you guys on @KGuillaume-chaps , @RomanDavydchuk . Thank you! |
|
All the linting issues should be fixed :) |
|
Got released with |
20 participants
Summary
This PR adds support for the now recommended HTTP Streamable Transport for the MCP Protocol.
It also keeps the compatibility with the deprecated SSE transport, in order to not break existing instances.
Related Linear tickets, Github issues, and Community forum posts
Review / Merge checklist
release/backport(if the PR is an urgent fix that needs to be backported)