/n8n-validation-expert

name: n8n-validation-expert
description: Interpret validation errors and guide fixing them. Use when encountering validation errors, validation warnings, false positives, operator structure issues, or need help understanding validation results. Also use when asking about validation profiles, error types, the validation loop process, or auto-fix capabilities. Consult this skill whenever a validate_node or validate_workflow call returns errors or warnings — it knows which warnings are false positives and which errors need real fixes.

n8n Validation Expert

Expert guide for interpreting and fixing n8n validation errors.

---

Validation Philosophy

**Validate early, validate often**

Validation is typically iterative:

• Expect validation feedback loops
• Usually 2-3 validate → fix cycles
• Average: 23s thinking about errors, 58s fixing them

**Key insight**: Validation is an iterative process, not one-shot!

---

Error Severity Levels

1. Errors (Must Fix)

**Blocks workflow execution** - Must be resolved before activation

**Types**:

• `missing_required` - Required field not provided
• `invalid_value` - Value doesn't match allowed options
• `type_mismatch` - Wrong data type (string instead of number)
• `invalid_reference` - Referenced node doesn't exist
• `invalid_expression` - Expression syntax error

**Example**:

{
  "type": "missing_required",
  "property": "channel",
  "message": "Channel name is required",
  "fix": "Provide a channel name (lowercase, no spaces, 1-80 characters)"
}

2. Warnings (Should Fix)

**Doesn't block execution** - Workflow can be activated but may have issues

**Types**:

• `best_practice` - Recommended but not required — surfaces under `ai-friendly` / `strict` only
• `deprecated` - Using old API/feature — surfaces under every profile
• `security` - Hardcoded secrets, unauthenticated webhooks — surfaces under every profile
• `performance` - Potential performance issue — advisory, `ai-friendly` / `strict`

**Example** (best-practice — appears under `ai-friendly` / `strict`):

{
  "type": "warning",
  "nodeName": "Slack",
  "message": "Slack API can have rate limits and transient failures"
}

3. Suggestions (Optional)

**Nice to have** - Improvements that could enhance workflow

**Types**:

• `optimization` - Could be more efficient
• `alternative` - Better way to achieve same result

---

The Validation Loop

Pattern from Telemetry

**7,841 occurrences** of this pattern:

1. Configure node
   ↓
2. validate_node (23 seconds thinking about errors)
   ↓
3. Read error messages carefully
   ↓
4. Fix errors
   ↓
5. validate_node again (58 seconds fixing)
   ↓
6. Repeat until valid (usually 2-3 iterations)

Example

// Iteration 1
let config = {
  resource: "channel",
  operation: "create"
};

const result1 = validate_node({
  nodeType: "nodes-base.slack",
  config,
  profile: "runtime"
});
// → Error: Missing "name"

// ⏱️  23 seconds thinking...

// Iteration 2
config.name = "general";

const result2 = validate_node({
  nodeType: "nodes-base.slack",
  config,
  profile: "runtime"
});
// → Error: Missing "text"

// ⏱️  58 seconds fixing...

// Iteration 3
config.text = "Hello!";

const result3 = validate_node({
  nodeType: "nodes-base.slack",
  config,
  profile: "runtime"
});
// → Valid! ✅

**This is normal!** Don't be discouraged by multiple iterations.

---

Validation Profiles

The four profiles are **cumulative** (n8n-mcp ≥ 2.63.0): each surfaces everything the lower one does, plus more. The dividing line is best-practice *advisories* — `minimal` and `runtime` withhold them; `ai-friendly` and `strict` add them. Errors are the same across every profile except that `minimal` skips a few config-level checks (e.g. enum validation of an explicit `operation`). Security and deprecation warnings surface under every profile.

minimal

**Use when**: Quick structural checks while wiring a workflow together.

**Surfaces**: hard errors that would stop execution (missing required fields, empty code, broken connections). Skips enum checks and all advisories.

**Fastest and most permissive.**

runtime (RECOMMENDED default)

**Use when**: Ongoing validation as you build; the everyday profile.

**Surfaces**: errors (required fields, value types, allowed values, dependencies, broken references) plus security and deprecation warnings. **No** best-practice advisories.

**Balanced — catches everything that breaks, stays quiet about style.**

ai-friendly

**Use when**: You want the best-practice advice before deploying.

**Surfaces**: everything `runtime` does, **plus** best-practice advisories — per-node "without error handling" suggestions, "webhook should always send a response", rate-limit notes, outdated-`typeVersion` suggestions, `cachedResultName` and long-chain hints.

**Note**: `ai-friendly` is *stricter* than `runtime`, not looser. (Older docs described it as reducing false positives — that was true only while profile gating was broken; it is fixed now.)

strict

**Use when**: Hardening a production-critical workflow.

**Surfaces**: everything `ai-friendly` does, **plus** leftover-property checks ("property 'X' won't be used — not visible with current settings").

**Maximum lint.** With the false positives fixed at the source, its warnings are advice to weigh, not noise to fight.

---

Common Error Types

Five core error types, in rough order of frequency:

• **`missing_required`** — a required field isn't provided. Use `get_node` to see required fields, then add it.
• **`invalid_value`** — value doesn't match allowed options (enums are case-sensitive). Check the error's allowed list or `get_node`.
• **`type_mismatch`** — wrong data type (string `"100"` vs number `100`). Convert to the expected type.
• **`invalid_expression`** — expression syntax error (missing `{{}}`, typos). See the n8n Expression Syntax skill.
• **`invalid_reference`** — referenced node doesn't exist (renamed