Custom connector fails to register with authless self-hosted n8n MCP server (ref ofid_2518fae51bd6015d)

[brunotorresdigital]

MCP server URL or name

Custom connector name: "Google Sheets MCP via n8n FA". Self-hosted n8n MCP Server Trigger node. URL redacted for security (contains a random secret path segment used in place of formal auth). Pattern: https:///mcp//sse

How are you connecting to this server?

From a custom connector URL I entered manually

Where does the issue occur?

When pressing the Connect button

When did you last reproduce this?

2026-07-25, afternoon, America/Sao_Paulo (UTC-3) — exact time not logged

Browser and OS

Google Chrome (latest), Windows 11

Describe the issue

I built a remote MCP server on my own self-hosted n8n instance, using n8n's "MCP Server Trigger" node with authentication explicitly set to "none" (n8n does not offer a working OAuth2 option on this node version — only none/bearerAuth/headerAuth are accepted). The server works correctly when tested directly (valid MCP initialize/tool responses).

When adding it to Claude.ai as a Custom Connector (Settings → Connectors → Add custom connector), entering only the server URL and leaving the OAuth Client ID/Secret fields blank (as expected for an authless server), clicking "Connect" fails immediately with a registration error instead of connecting directly.

This matches multiple other reports in the n8n community forum describing the same behavior: Claude's connector flow appears to always attempt OAuth Dynamic Client Registration against the target server, even when the server declares no authentication requirement, and fails when the server (correctly, per its own config) does not implement an OAuth registration endpoint.

Error details

Error message shown in Claude.ai when clicking Connect (my Claude.ai UI locale is Portuguese/Brazil):

Original (pt-BR): "Não foi possível registrar no serviço de login de Google Sheets MCP via n8n FA. Você pode tentar novamente ou adicionar um OAuth Client ID nas configurações do conector."

Translation: "Could not register with Google Sheets MCP via n8n FA's sign-in service. You can try again, or add an OAuth Client ID in the connector settings."

Reference ID shown: ofid_2518fae51bd6015d

Expected behavior

Since the MCP server's authentication is explicitly set to "none" (no OAuth, no bearer token, no custom headers), I expected Claude to connect directly without attempting any OAuth Dynamic Client Registration or login/registration handshake — the same way it presumably handles other authless MCP servers.

Additional context

This appears to match several other reports of the same class of bug:

• community.n8n.io: "MCP OAuth registration fails when connecting Claude.ai" (July 22, 2026) — identical error text "Couldn't register with n8n's sign-in service"
• community.n8n.io: "Claude.ai MCP Connector Failing to connect to my self-hosted n8n" — reports both OAuth and no-auth MCP Server Trigger failing the same way when connected from Claude.ai (not Claude Desktop), including a case where Anthropic support acknowledged a related bug (OAuth completes but bearer token isn't attached to subsequent requests).

Happy to provide n8n version, workflow export, or further logs if useful.

[nkick25]

Confirming the same behavior, with two data points that may broaden the scope of this issue: n8n Cloud (not self-hosted) and MCP Server Trigger typeVersion 2 (the version that does expose an n8nOAuth2 option), with authentication explicitly set to none.

Setup

• n8n Cloud instance (URL and path segment redacted, since the path is currently the only access control).
• Workflow-level MCP Server Trigger, typeVersion 2, authentication: none.
• Endpoint pattern: https://<instance>.app.n8n.cloud/mcp/<slug> (streamable HTTP) and .../sse (SSE). Both transports are served by the v2 node.
• The endpoint responds correctly when exercised directly: valid MCP initialize, tools are listed, and tool calls return real data.

Symptom
Adding the endpoint as a Custom Connector in claude.ai web does not connect directly. Instead of an authless connection, the flow attempts to authenticate against the n8n instance — the end user is pushed toward an n8n sign-in / client-registration step and the connector never loads the tools. Same class of failure described in this issue.

Possibly useful reproduction lead: the outcome differs per Claude account on the same endpoint.

This is the part I have not seen reported elsewhere:

• From a Claude account that already has the n8n instance-level MCP connector (/mcp-server/http, which uses real OAuth) authorized for the same host, adding the authless custom connector for that host works, and tool calls succeed.
• From a Claude account with no prior OAuth grant against that host (our client's account, no n8n user at all), the exact same URL fails at the registration/sign-in step.

This suggests the connector flow requires (or reuses) an existing OAuth client registration scoped to the target host, and that an authless server is only reachable when such a registration happens to already exist. If that is the mechanism, it would explain why several reporters describe endpoints that "worked for a long time" and then stopped: the behavior depends on account state, not on the server.

Regression timing
The endpoint had been in use by an end client for an extended period without any authentication prompt. It stopped working in the window of roughly July 22–25, 2026 — consistent with the dates on this issue and on the related n8n community threads. No changes were made on our side to the authentication configuration in that window.

Also worth noting for scope
Migrating the node from typeVersion 1 to 2 does not change this behavior. So the issue is not limited to older MCP Server Trigger versions that lacked an OAuth option.

Impact
This blocks a production deployment for an end client, who has no n8n account and should not need one to consume the connector. Claude Desktop is the only workaround we are aware of, which is not viable for non-technical end users at scale.

Happy to provide n8n version, workflow export, or initialize traces privately if that helps.