I’m on Cloud Starter and can’t get a client to authenticate against an MCP Server Trigger, despite ruling out every configuration variable I can control.
Setup: MCP Server Trigger node, Production URL, workflow Active. Tried both Bearer Auth and Header Auth credential types, both fail identically with “Authentication failed.”
What I’ve confirmed and ruled out:
URL is correct (Production URL, matches exactly between trigger and client)
Token is identical (verified by using the same credential entity on both sides, and separately by direct side-by-side comparison)
Header Auth credential Name field is exactly “Authorization,” no typo or casing issue
Header Auth “Allowed HTTP Request Domains” is set to All
Workflow is Active, not just saved
Tested via the MCP Client Tool node’s built-in connection test AND via a real live execution (Chat Trigger → AI Agent → MCP Client Tool), same failure both ways
Rebuilt from scratch in a completely isolated test workflow, brand new trigger, brand new credential, brand new client, zero shared history with my original build, same failure
This happens consistently, not intermittently. I’d appreciate help understanding whether this is a known issue with MCP Server Trigger’s authentication handling, or something specific to my instance.
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Hi @kfbird Welcome!
“Authentication failed” from the MCP Client Tool means the server answered with a 401 or 403, so the request is reaching the trigger and being rejected at the auth check, not at the URL or the transport. The trigger compares the incoming header against the stored credential as an exact string with no trimming, while outgoing header values get stripped of leading and trailing whitespace before they leave the client. A token pasted with a trailing space, tab or newline looks identical on both sides and can never match. Recreate both credentials, type a short plain alphanumeric token by hand into each instead of pasting, then republish and retest.
To confirm which side is at fault, hit the production URL directly:
curl -i -X POST "https://<your-instance>.app.n8n.cloud/mcp/<your-path>" -H "Authorization: Bearer <your-token>"
A 403 there means the trigger really is rejecting the token. Anything else means auth passed and the problem sits in the client node.
You mentioned you set the Header Auth credential’s Name field to "Authorization". This is actually the most common silent failure point: the MCP Client Tool node, when using Header Auth, sends the value as-is. If the trigger is expecting Authorization: Bearer <token> but the client sends Authorization: <token> (without the Bearer prefix), the match fails — even though the token itself is correct . Double-check that the Value field in your Header Auth credential includes the full string Bearer <your-token>, not just the raw token.
Bearer and Header auth go through two separate comparisons in the trigger, so a token-shaped problem would not fail identically in both. That rules the credential comparison out.
The MCP Client Tool prints “Authentication failed” for any 401 or 403 it receives, and the trigger answers with a plain 401 and the body “No transport found for sessionId” when the MCP session is missing, which never reaches the credential check at all.
The underlying status and body are attached to the node error as its description, so open the error detail on the MCP Client Tool rather than going by the headline. A real token rejection is a 403 with an empty body.
The Server Transport option also has to match the URL the trigger hands you. The plain base path is HTTP Streamable, and a URL ending in /sse is the deprecated SSE option.
I have the server transport as HTTP Streamable, and am using the production url exactly as it gave it to me. I don’t think it is an issue with a mismatch in the tokens/credentials as I have tried over and over to redo them and fix the error.
Both auth types you tried send the token in the Authorization header, so a header being rewritten in transit fails all of them identically.
Create a Header Auth credential with Name X-Mcp-Token and any short value, set the MCP Server Trigger to Header Auth with that credential, set the MCP Client Tool to Header Auth with the same credential, then save and re-activate.
If it still fails, email help@n8n.io with your instance name and the workflow ID so they can check the /mcp route on your instance.
At this point I’d stop changing auth methods and make the failing request visible.
The useful split is:
Does the request actually arrive with the header you think it has?
Is the MCP trigger rejecting the value after receiving it?
If you can put a temporary plain Webhook node in front of the same client and log the incoming headers, you’ll know whether this is a client/header-shape problem or an MCP trigger auth problem. If the header is present and exact there, this is probably not fixable from the workflow canvas alone.
@kfbird when you email support, mention that this reproduces on a brand-new isolated test workflow with zero shared history, that rules out anything cached or corrupted in your original workflow/credentials, and points at either an instance-level bug or something in how Cloud Starter handles the /mcp route auth specifically. Worth asking if it reproduces on other plan tiers too.
Since you’ve proven the header arrives intact and the trigger still returns 403, there are three things worth ruling out before (or while) support digs in:
Re-activation after credential edits. An active workflow keeps the credential state it had at activation time. If you edited the credential value while the workflow stayed Active, the trigger can keep validating against the old snapshot. After ANY change to the trigger or its credential: deactivate, save, wait a few seconds, activate again. A plain “Save” is not enough.
Exact path match. With HTTP Streamable transport the production URL must match character-for-character, including the trailing slash. Some clients normalize /mcp/<path> to /mcp/<path>/ (or strip it), and the request then hits the auth layer as an unknown route and comes back 403. Try both variants once in your curl test.
Take the MCP Client Tool node out of the equation. Run the official inspector from a terminal (npx @modelcontextprotocol/inspector), set transport to Streamable HTTP, paste the production URL and add the Authorization header there. If the inspector connects, the bug is in the client node config, not the trigger — that’s a very useful data point for your support ticket.
If you post the exact URL shape (path part only, token redacted) and whether the trailing-slash variant changes the 403, happy to keep digging here.
