n8n - 💡(How to fix) Fix [MCP SDK] create_workflow_from_code intermittently returns HTTP 500, often as a false negative (workflow persists anyway, causing duplicates on retry)

Summary

The native n8n Workflow Builder MCP server's create_workflow_from_code intermittently returns HTTP 500 for valid code that validate_workflow accepts. Three things distinguish this from the existing deterministic 500 reports (e.g. #29660):

1. Non-deterministic: the same code, submitted twice in a row, can 500 once and succeed once.
2. Not node-specific: observed with n8n-nodes-base.emailReadImap, and separately with n8n-nodes-base.gmail (v2.2) + n8n-nodes-base.scheduleTrigger (no IMAP node involved).
3. The 500 is frequently a false negative: the workflow is persisted in n8n despite the error returned to the client, so a retry creates a duplicate.

Environment

• n8n: self-hosted (Docker), version 2.18.5
• Builder MCP / @n8n/workflow-sdk
• Client: Claude Code MCP integration
• Observed: 2026-05-26 and 2026-05-27

Observed behavior

Intermittency. Two independent MCP sessions submitted near-identical code containing an n8n-nodes-base.emailReadImap trigger. One returned HTTP 500; the other, minutes later, succeeded with the same node, with no config or credential difference that would explain it.

Not node-specific. The next day the same 500 hit a workflow with no IMAP node at all (n8n-nodes-base.gmail v2.2 + n8n-nodes-base.scheduleTrigger), so the fault is in the tool/persist path, not a specific node's schema.

False negative -> duplicates (the most actionable part). create_workflow_from_code returned 500 to the client, but the workflow was created in n8n anyway. Retrying after the 500 produced a second, identical workflow. In one case two consecutive 500s left two complete, identical workflows that had to be reconciled by hand (search_workflows to detect, archive_workflow to clean up).

No error body. As in #29660, the 500 carries no error payload to the MCP client, so the underlying cause can't be diagnosed client-side.

Expected behavior

• When validate_workflow accepts the code, create_workflow_from_code should persist deterministically.
• A genuine failure should not leave a persisted workflow (no partial commit), and/or the call should be idempotent or return the created workflow id so retries don't duplicate.
• The actual error should be surfaced in the response body.

Impact

Workflow creation via the Builder MCP is unreliable and silently lossy toward duplicates: every 500 forces a defensive "search_workflows before retrying" step, and missed duplicates accumulate in the instance. This undercuts the core value of building workflows programmatically.

Suggested triage

The combination of (a) persist-succeeds-but-500-returned and (b) non-determinism points at the post-persist / response-construction step throwing after the DB write has committed (e.g. a serialization step, credential auto-assignment, or a race/timeout), rather than the create itself failing. Two concrete asks:

1. Surface the real error body to the MCP client; this alone would let reporters file deterministic repros.
2. Make create persist+respond atomic, or idempotent / id-returning, so a 500 can't leave an orphan duplicate.

Repro notes

The bug is non-deterministic, so there's no single deterministic snippet; it reproduces by calling create_workflow_from_code repeatedly with the same valid, validate_workflow-passing code and observing occasional 500s plus duplicate persists. Happy to share the exact SDK code and, if you point me at the relevant server-side logger, capture a stack trace from a self-hosted instance.

Related: #29660 (deterministic 500 + no error body on create_workflow_from_code for langchain root nodes); likely shares the response-path handling.