n8n MCP not working? Checklist for discovery and calls

By Roman Rodomansky·Published 21 Oct 2026

n8n MCP not working? Isolate endpoint, transport, authentication, discovery and execution issues with a repeatable read-only check.

• n8n
• Workflow debugging
• Checklist

Checked against the cited sources on 21 Oct 2026.

Scope your n8n MCP issues before changing settings

Is n8n MCP not working in your workflow? Separate connection, tool discovery and tool execution. This checklist targets the MCP Server Trigger, which exposes tools from one workflow; instance-level MCP setup belongs to a different configuration.

The checks and completion criteria below are our suggested troubleshooting framework, not mandatory MCP standards or a tested procedure. These checks do not establish compatibility across n8n and client releases; verify them against your installed versions. Start by recording the configuration so later changes have a clear baseline.

• Record the installed n8n and client versions.
• Record the deployment and whether a reverse proxy is involved.
• Identify the MCP Server Trigger workflow and selected endpoint type.
• Record the intended transport and authentication mode without copying secrets.

We think the most useful debugging habit is to name the failing boundary before changing settings. A missing tool and an incorrect tool result deserve different investigations.

Sources: n8n-docs/docs/connect/connect-to-n8n-mcp-server.md at main · n8n-io/n8n-docs · GitHub

Check endpoint readiness, transport and authentication

For an inactive workflow, n8n registers the MCP Server Trigger test URL when you select Listen for Test Event or Execute workflow. Publishing registers the production URL.

The trigger supports SSE and streamable HTTP, but not direct stdio. A gateway that bridges a stdio client is a separate configuration. Authentication choices are None, Bearer auth and Header auth; authenticated access is our recommendation for this team check, rather than a universal platform requirement.

With n8n MCP not working at connection time, investigate each boundary separately instead of treating every failure as evidence of an invalid token. For reverse-proxy deployments, the buffering check below reflects n8n's documented requirement, not a complete proxy configuration. Use the following suggested completion checks.

• Use the test URL while listening, or the production URL after publishing.
• Select SSE or streamable HTTP explicitly in the client.
• Match the client's authentication configuration to the trigger.
• If a reverse proxy is present, check buffering for the MCP endpoint.
• Mark this stage complete when the client connects through the intended configuration.

Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger.md at main · n8n-io/n8n-docs · GitHub, MCP Server Trigger | Nodes | n8n Docs

Check discovery with a minimal read-only tool

Our suggested fixture is a diagnostic workflow containing the MCP Server Trigger and a connected JavaScript Code Tool returning a fixed string, for example return 'mcp-check-ok';. Exclude external APIs and write operations. n8n's Code Tool implementation on the repository's master branch describes output as a single string; this example is untested and must be checked against your installed release.

n8nlogic's March 2026 vendor guide describes the trigger as executing connected tool nodes rather than a conventional linear workflow. Use that wiring explanation as a troubleshooting lead: inspect the diagnostic tool's connection before changing its code.

The regular n8n MCP Client node automatically fetches the external server's selectable tools. Configure it for your endpoint and inspect that list. Discovery is complete when the diagnostic tool appears; visibility does not establish that the tool executes successfully.

In our view, a deliberately boring fixture is the right starting point. We would remove business logic until the connection and tool boundary are understandable.

Sources: n8n MCP Server: How to Expose Your Workflows to AI Agents | n8nlogic, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-langchain.mcpClient.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/@n8n/nodes-langchain/nodes/tools/ToolCode/ToolCode.node.ts at master · n8n-io/n8n · GitHub

Check the call, then repeat the same evidence

Is n8n MCP not working even after discovery succeeds? Call the selected tool with inputs matching its discovered schema. The n8n MCP Client supports manually entered parameters or a JSON object. For this suggested fixture, completion means the response contains mcp-check-ok and you can inspect the corresponding execution.

Inspect production runs through executions rather than live canvas output. The executions view can filter accessible runs by workflow, status and start time; access depends on workflow permissions, and deleting a workflow deletes its execution history. A Success status alone does not establish correct output.

Use this suggested handoff checklist after each configuration change. It checks the constant-response boundary, not application-specific APIs, downstream permissions or business data correctness, and it provides no reliability guarantee.

• Repeat discovery and the same tool call.
• Record the endpoint type, transport, tool name and redacted inputs.
• Record expected output, actual output and timestamp.
• Attach an accessible execution reference.
• Separate connection failures, missing tools, returned errors and incorrect output.
• Hand over the remaining failing boundary and the last configuration change.

Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger.md at main · n8n-io/n8n-docs · GitHub, MCP Client | Nodes | n8n Docs, View all executions | Build | n8n Docs