seems like a bug
Umm…where is the STDIO Mcp client? Like the one provided by nerding.io?
2 Likes
when trying with ollama and a local model like mistral-small3.1:latest I get the error
It is ok when trying with openAI Chat Model (gpt4o-mini)
1 Like
MCP Client tool (SSE) not working.
- in a terminal window:
npx -y supergateway \
--stdio "docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN=ghp_... ghcr.io/github/github-mcp-server" \
--port 8000 --baseUrl http://localhost:8000 \
--ssePath /sse --messagePath /message
Which sucessfully loaded the Golang based MCP server for access to Github. I then fired up MCP Inspector v0.8.2 and successfully connected to the SSE endpoint I just created at “http://localhost:8000/sse”. When tried entering that into the provided MCP Client SSE tool in n8n, it won’t even connect to port 8000. I have the other values in the n8n node set to their defaults (no bearer token, all tools).
Your MCP node trigger has to be running,
either when you click play on it (use test til in this case) or if workflow activated(production url)
I made them work
Are you talking about MCP trigger url ? Or MCP SSE url in client tool ?
I made them work, maybe some tips:
- I use ngrok
- In client url don’t forget /sse at the end
- The workflow with McP trigger has to be running either in test mode or activated ( choose test or production url accordingly)
Hope it helps
My issue must be related to network, then. Cause I can’t make it work, no matter what.
1 Like
Regarding MCP servers that only offer STDIO transport, we first need to build proper sandboxing mechanisms to run these, before we can support them officially.
Please remember that these are arbitrary scripts and binaries from the internet, with close to no auditing and no supply-chain integrity checks in place, with great potential for exploitation.
We do want to offer these, but only after we are sure that we can do so without compromising the security of our users.
Until then If you are self-hosting, you can always run your own SSE to STDIO proxy (like supergateway), at your own risk.
3 Likes
@solomon can you please start a separate thread, even better an issue on github, with more technical information, so that we can help you fix this for your self-hosted setup 
@Brawndo localhost might be resolving to IPv6 ::1 on your setup.
Can you please try replacing localhost with 127.0.0.1 instead?
Tried localhost, 127.0.0.1, and 0.0.0.0. Nothing works.
are you running n8n inside docker? because then localhost inside the container is not the same as localhost on your host machine.
In that case maybe try replacing localhost with host.docker.internal in the MVP Client tool in n8n.
I noticed the same issue with an openrouter node. Using openai node works
This solution worked for me. Disable compression for traefik middleware component.
https://github.com/n8n-io/n8n/issues/14539#issuecomment-2795330147
2 Likes
sorry for asking, for version 1.88.0 is not release yet on latest image for docker right?
1 Like
Hi @muhdidhamm, you’re right — the n8nio/n8n:latest image currently points to version 1.86.1.
However, you can still pull other versions:
- For the upcoming release:
docker pull n8nio/n8n:next - For a specific version like 1.88.0:
docker pull n8nio/n8n:1.88.0
You can find all available tags here: Docker Hub - n8nio/n8n
3 Likes
Nice!!! Waiting when I can try.
That got me a bit further. When using host.docker.internal, the console log of the running MPC server that is running on the host outside my running docker container of n8n, I see the following:
[supergateway] New SSE connection from ::ffff:127.0.0.1
[supergateway] SSE connection closed (session 20675cdf-0d51-48e0-8fe6-2ba2103a8558)
[supergateway] Client disconnected (session 20675cdf-0d51-48e0-8fe6-2ba2103a8558)
Will those self-hosting using docker get this too?
Thanks! Changing localhost to host.docker.internal works for me. I am running n8n inside Docker. But I have to refresh the node a lot to see the change.