MCP Node

The MCP node calls a single named tool on a connected MCP (Model Context Protocol) server — once per run or once per record — and merges the tool response back into the automation data.

When to Use

Use MCP when you want to call one specific tool from a connected server — for example, a custom data-enrichment tool, an internal service exposed over MCP, or a third-party integration. If you instead want the model to choose which tools to call, use the Agent node.

Configuration

Arguments

In static mode the arguments object is sent as-is. In dynamic mode the argumentsTemplate string is interpolated against the record (the first row in single mode, each row in per_row mode) using {{field}} references — see Template Syntax.

Response Mapping

responseMapping.dataPath is a dot-notation path into the tool response (the part to keep). responseMapping.outputMode controls how the result is merged into the data:

• replace (default) — the tool response replaces the input rows
• merge — the response fields are merged into the existing rows
• append — the response is appended as new rows after the input

responseMapping:
  dataPath: intelligence.competitors
  outputMode: merge

Example

Call a custom company-intelligence tool once per row:

connectionId: conn_acme_mcp
toolName: get_company_intelligence
argumentsMode: dynamic
argumentsTemplate: |
  { "domain": "{{domain}}", "depth": "standard" }
iterationMode: per_row
responseMapping:
  dataPath: intelligence
  outputMode: merge

Output

Each output row carries a _success boolean. In per_row mode with continueOnError enabled, failed rows are kept with _success: false and an _error message; the rest of the run continues. The tool's output columns are unknown until execution, so downstream join keys are detected at runtime.

Notes

• MCP connections are configured on the Integrations page — only tools from active, admitted connections can be called.
• MCP tool calls run on the governed external rail (action:mcp scope, or the tool's resolved governance action type) and are evaluated by guardrails, pauses, and approval policies before execution. Read-only tools flow through unchanged; tools that are not affirmatively read-only are routed for approval (fail-closed).
• Governed external writes cannot run on the MCP node. A tool annotated as a write (cesteral.kind: "write") is blocked here because the MCP node does not run the write-preview admission pipeline — use the Agent node, which routes external writes through the admission funnel.
• Calls are rate-limited per connection using the connection's configured requests-per-second and burst settings.