Instance level MCP access issues

Questions
1

Describe the problem/error/question

I have a meta workflow triggered by a webhook, which needs to be exposed as a tool to other compatible custom AI agents via n8n MCP server. Having issues accessing the server via the provided analogous URL

What is the error message (if any)?

n8n UI url: http://localhost:5678/mcp-server/http

I am using a devtunnel via VSCode to get HTTP access: assume https:///mcp-server/http/

Just to test things out I try converting the JSON config via access token and convert it to a curl command

``
curl -v --http1.1
-H “Upgrade: mcp”
-H “Connection: Upgrade”
-H “Authorization: Bearer $MCP_TOKEN”
-H “Accept-Encoding: identity”
https:///mcp-server/http/
```
ALSO via npx

npx -y supergateway --streamableHttp “https:///mcp-server/http/” --header “authorization:Bearer $MCP_TOKEN”

While the connection is successful, I return HTML like response from the editor UI when it should have been from mcp server

```
curl -v --http1.1
-H “Authorization: Bearer $MCP_TOKEN”
```

>

We're sorry but the n8n Editor-UI doesn't work properly without JavaScript enabled. Please enable it to continue.

I have mcp enabled and the relevant workflow also published and made available in MCP

Using VPN that cannot be disabled and the devtunnel for exposing

tried replacing the hostname with the devtunnel URL, localhost, 127xx, the service name of docker but all return errors

Is this that non trivial? Could use some hints/help please!

Information on your n8n setup

  • n8n version: 2.1.1
  • Database (default: SQLite): postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker with n8n main+ runners setup external mode
  • Operating system: n8n running within WSL

any leads will be helpful

2

Most likely, the problem is that devtunnel does not transmit HTTP Upgrade headers, which are critical for the MCP protocol.

I think the best solution would be to host your automation on a server or in the cloud, although this does cost money $$

3

Hi @adarsh-lm The problem you’re having is that the devtunnel you are using is stripping the HTTP Upgrade headers necessary for establishing the MCP WebSocket connection and is returning the n8n Editor UI HTML instead of the MCP protocol handshake there are several solutions i can suggest but the major one i would say is that do not use development server of VScode and use Ngrok and as it supports free plans with 20k HTTP requests a month that would be more than enough for testing things around, let me know if this helps.

1 Like
4

Hi @adarsh-lm

One small clarification based on the docs: the instance-level MCP /mcp-server/http endpoint uses streamable HTTP, not WebSockets, so it does not rely on Upgrade headers.

Since you’re getting the Editor UI HTML back, that usually means the request is being routed to / instead of /mcp-server/http. In practice, this happens when the tunnel/proxy rewrites or drops the path.

The key things to verify are:

  • the exact URL copied from Settings → Instance-level MCP → Connection details
  • that your tunnel forwards /mcp-server/http unchanged to http://localhost:5678/mcp-server/http
  • and that you’re only sending Authorization: Bearer <token> for streamable HTTP

If the tunnel can’t preserve the path reliably, using ngrok or a public host is the safest way to test MCP.

Reference:
Accessing MCP; Examples]
[Examples]
Accessing MCP
[Common issues; Community nginx fix]

1 Like
5

Thank you all for the response ! @tamy.santos @Anshul_Namdev @Aleksei_Chprynin

While I will check into the devtunnel aspect. I wanted to understand if corporate VPN has any role to play into this issue? I am still learning about these details so any opinions in this regard will also help me!

I will reply soon as possible on switching devtunnel

1 Like
6

@adarsh-lm

Yes, the corporate VPN could definitely be involved. However, the knowledge sources don’t provide a definitive rule on this – it depends entirely on your organization’s network configuration and firewall policies.

I’d recommend checking with your IT team to see if there are any restrictions on outbound connections or specific domains that might be blocked when connected to the VPN.

1 Like
7

@adarsh-lm VPN is just a private network and it should not effect your traffic until specifically configured, just use a Ngrok/CloudFlare tunnel and things should start working, i am using Ngrok its better.

8

I have seemingly found a way out to the problem without having to further dig into replacing devtunnel OR VPN issues

The rationale comes from the point that I was able to connect with the MCP server endpoint in the first place. The major issue seemed to be routing to the correct path as I was being returned HTML

Adding the X-Tunnel-Skip-Anti-Phishing-Page header seemingly worked with the connection

To the curl request, I had to add another header Accept: application/json, text/event-stream

Also supergateway seems to be giving a lot of issues with connection, so I also switched to mcp-remote and I have been able to connect, though the consistency is not great. Keep either getting no response or timeouts

my final config json that seemingly should work with agents

``
{
“mcpServers”: {
“n8n”: {
“command”: “npx”,
“args”: [
“-y”,
“mcp-remote”,
“$MCP_ENDPOINT``”``,
“–header”,
“Authorization: Bearer $MCP_TOKEN”,
“–header”,
“X-Tunnel-Skip-Anti-Phishing-Page: true”,
“–header”,
“Content-Type: application/json”
]
}
}
}
```

Potentially if not the header, ngrok would have been the fix because it avoids the anti phishing confirmation banner on the browser.

thank you all again for your help. look forward to hearing comments, else we can close this

1 Like
9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.