n8n - 💡(How to fix) Fix MCP Server: authenticated initialize POST returns HTTP 400 to Claude Code (MCP SDK client) [1 comments, 2 participants]

The built-in MCP server accepts unauthenticated probes and valid OAuth handshakes, but rejects the first authenticated initialize request from the Claude Code MCP client with HTTP 400, preventing any client interaction.

Environment

• n8n self-hosted, version 2.15.0 (Community)
• n8n MCP server version 1.1.0 (from initialize response serverInfo)
• Client: Claude Code 2.1.97 (VSCode extension build, MCP TypeScript SDK), Node.js v24.3.0
• Transport: Streamable HTTP (type: "http")
• Auth: OAuth2 via /.well-known/oauth-authorization-server discovery chain

What works

• curl -X POST /mcp-server/http with Authorization: Bearer <token>, Content-Type: application/json, Accept: application/json, text/event-stream, and a JSON-RPC initialize body returns HTTP 200 and a valid text/event-stream handshake including serverInfo, capabilities, and server instructions. Fully functional.
• The OAuth flow from Claude Code through /mcp-oauth/authorize and /mcp-oauth/token succeeds. Browser-side flow completes without user-visible error.

What fails

Immediately after the OAuth dance, Claude Code attempts the initialize POST and receives HTTP 400 with an empty error body:

[DEBUG] MCP server "n8n-official": HTTP Connection failed after 54ms:
Streamable HTTP error: Error POSTing to endpoint:  (code: 400, errno: none)
[ERROR] MCP server "n8n-official" Error: Streamable HTTP error: Error POSTing to endpoint:

Client-side state at the moment of failure (from [DEBUG] output):

• Token length: 379 (valid bearer token obtained from /mcp-oauth/token)
• Has refresh token: true
• Expires in: 3599s
• hasAuthProvider: true
• Request URL: https://<host>/mcp-server/http
• Timeout: 60000 ms
• Outgoing headers (per SDK transport init): {"User-Agent":"claude-code/2.1.97 (claude-vscode, agent-sdk/0.2.96)"} (the Authorization header is injected separately by the auth provider)

The request fails after 18-54ms, so this is not a timeout or network issue; n8n is actively returning 400 at the MCP endpoint.

Earlier in the same session

One prior attempt from the same client returned [ERROR] MCP server "n8n-official" Error: Unauthorized (HTTP 401) before the 400 started appearing, suggesting at least two distinct rejection paths depending on token state.

Hypothesis

Given that the same URL, same token shape, and a handcrafted JSON-RPC initialize body succeed via curl, and the MCP TS SDK request fails with 400, the difference is almost certainly in request shape. Candidates worth checking in the MCP server handler:

• Accept header tolerance: does the server require application/json, text/event-stream specifically, or reject requests missing one half?
• Content-Type normalisation: does it reject application/json; charset=utf-8 when the SDK sends it?
• mcp-session-id header handling: newer streamable HTTP specs require clients to echo a session ID from a prior response; does the n8n server require it on the very first POST?
• JSON-RPC body validation: is the server strict about protocolVersion values (the SDK currently sends 2025-06-18)?

Reproduction

1. Enable Instance-level MCP in n8n 2.15.0
2. Add the server to Claude Code 2.1.97 as type: "http" with the MCP URL
3. Complete the OAuth flow (succeeds)
4. Observe the connection immediately reports "Failed" in the /mcp panel with "Streamable HTTP error: Error POSTing to endpoint:"

Manual curl with the same OAuth-acquired token against the same URL works; Claude Code does not.

Why this matters

The docs on docs.n8n.io/advanced-ai/accessing-n8n-mcp-server/ explicitly recommend Claude Code as the ideal client:

"Consider using coding agents (such as Claude Code or Google ADK agents) instead of chat clients as your MCP clients. Coding agents are optimized for generating and validating TypeScript code, making them ideal for building workflows programmatically."

But the integration doesn't currently work end-to-end with Claude Code.

What would help

Any one of these would unblock:

• Log the exact reason for the 400 (which header or body field was rejected) in n8n's server output so client developers can adjust
• Return a descriptive error body instead of an empty 400 response
• Confirm which MCP protocol version the n8n MCP server targets, so client SDKs can negotiate correctly