/n8n-node-configuration

name: n8n-node-configuration
description: Operation-aware node configuration guidance. Use when configuring nodes, understanding property dependencies, determining required fields, choosing between get_node detail levels, or learning common configuration patterns by node type — including the native nodes that replace Code (Summarize, Aggregate, Split Out, Merge, Compare Datasets, Remove Duplicates, Sort, Limit, Date & Time, HTTP Request pagination, Crypto). Always use this skill when setting up node parameters — it explains which fields are required for each operation, how displayOptions control field visibility, and when to use patchNodeField for surgical edits vs full node updates.

n8n Node Configuration

Expert guidance for operation-aware node configuration with property dependencies.

---

Configuration Philosophy

**Progressive disclosure**: Start minimal, add complexity as needed

Configuration best practices:

• `get_node` with `detail: "standard"` is the most used discovery pattern
• 56 seconds average between configuration edits
• Covers 95% of use cases with 1-2K tokens response

**Key insight**: Most configurations need only standard detail, not full schema!

---

Core Concepts

1. Operation-Aware Configuration

**Not all fields are always required** - it depends on operation!

**Example**: Slack node

// For operation='post'
{
  "resource": "message",
  "operation": "post",
  "channel": "#general",  // Required for post
  "text": "Hello!"        // Required for post
}

// For operation='update'
{
  "resource": "message",
  "operation": "update",
  "messageId": "123",     // Required for update (different!)
  "text": "Updated!"      // Required for update
  // channel NOT required for update
}

**Key**: Resource + operation determine which fields are required!

2. Property Dependencies

**Fields appear/disappear based on other field values**

**Example**: HTTP Request node

// When method='GET'
{
  "method": "GET",
  "url": "https://api.example.com"
  // sendBody not shown (GET doesn't have body)
}

// When method='POST'
{
  "method": "POST",
  "url": "https://api.example.com",
  "sendBody": true,       // Now visible!
  "body": {               // Required when sendBody=true
    "contentType": "json",
    "content": {...}
  }
}

**Mechanism**: displayOptions control field visibility

3. Progressive Discovery

**Use the right detail level**:

1. **get_node({detail: "standard"})** - DEFAULT

• Quick overview (~1-2K tokens)
• Required fields + common options
• **Use first** - covers 95% of needs

2. **get_node({mode: "search_properties", propertyQuery: "..."})** (for finding specific fields)

• Find properties by name
• Use when looking for auth, body, headers, etc.

3. **get_node({detail: "full"})** (complete schema)

• All properties (~3-8K tokens)
• Use only when standard detail is insufficient

---

Configuration Workflow

Standard Process

1. Identify node type and operation. 2. Use `get_node` (standard detail is default). 3. Configure required fields. 4. Validate configuration. 5. If a field is unclear → `get_node({mode: "search_properties"})`. 6. Add optional fields as needed. 7. Validate again. 8. Deploy.

Example: Configuring HTTP Request

The validate-driven loop in practice: start minimal (`method`, `url`, `authentication`), then let each `validate_node` error surface the next required field (`sendBody` for POST → `body` when `sendBody=true`) until valid. Full step-by-step walkthrough in **[OPERATION_PATTERNS.md](OPERATION_PATTERNS.md#worked-example-configuring-http-request-step-by-step)**.

---

get_node Detail Levels

Standard Detail (DEFAULT - Use This!)

**✅ Starting configuration**

get_node({
  nodeType: "nodes-base.slack"
});
// detail="standard" is the default

**Returns** (~1-2K tokens):

• Required fields, resolved for the node's current typeVersion
• Operation list
• The settings inside `options` collections (n8n-mcp 2.97.0+): name + one line with nested field names, allowed

values and when each applies — HTTP Request pagination and batching, Webhook raw body, Merge combine settings, …

• Metadata

**Use**: 95% of configuration needs. Read the options list before deciding a job needs a Code node.

Full Detail (Use Sparingly)

**✅ When standard isn't enough**

get_node({
  nodeType: "nodes-base.slack",
  detail: "full"
});

**Returns** (~3-8K tokens):

• Complete schema
• All properties
• All nested options

**Warning**: Large response, use only when standard insufficient

Search Properties Mode

**✅ Looking for specific field**

get_node({
  nodeType: "nodes-base.httpRequest",
  mode: "search_properties",
  propertyQuery: "auth"
});

**Use**: Find authentication, headers, body fields, etc.

Decision Tree

1. Starting a new node config → `get_node` (standard). 2. Standard has what you need → configure with it. Otherwise continue. (On n8n-mcp 2.97.0+ standard also lists each `options` collection; a list cut at 25 settings says so.) 3. Looking for a specific field → `search_properties` mode. Otherwise continue. 4. Still need more → `get_node({detail: "full"})`.

**Dynamic properties**: when `standard` detail marks a property with `dynamicOptions: {methodName, methodType, dependsOn}`, its real values come from a live `loadOptions`/`listSearch` method, not from bundled docs — don't guess an ID for it. Resolve it with `n8n_explore_node_resources` (needs `N8N_MCP_ACCESS_TOKEN`, n8n 2.34+) and put the returned `value` in the config; `name` is display text only.

All six parameters are required and none are inferred from each other:

n8n_explore_node_resources({
  nodeType: "n8n-nodes-base.googleSheets",  // LONG form
  version: 4.5,                              // the node typeVersion the method belongs to
  methodName: "getSheets",                   // copied verbatim from dynamicOptions