LLM Step

Description

The LLM Step runs a prompt against a large language model as one step in a workflow. You give the model scoped access to specific tables, dimensions, and documents in your project, choosing Read, Write, or both for each one. The model reads the data it needs and — where you’ve granted Write — writes its results straight back into the object you selected. There is no separate output format to configure: a Write-enabled binding is the step’s output.

A common use is to summarize a financial table into per-business-unit commentary and have the model write that commentary into a results table (or as document files) you bound with Write access.

Note

Scoped access to project data (tables, dimensions, documents) is available with Anthropic LLM connections, which use a secure connector to reach PlaidCloud’s MCP tools. Other providers can still run a prompt and return structured JSON, but they don’t get scoped data access — bindings are ignored for them, and a result schema is required.

Before You Start

You’ll need:

• An LLM connection. The step requires a connection of kind LLM (for example, Anthropic). The connection holds the provider API key, an optional default model, and an Agent Access level. See Connections.
• Write access on the connection — only if any binding is Write-enabled. A binding can write only if the connection’s Agent Access is Read & write or Full. A Read-only connection rejects Write bindings when you save.
• The destination objects already created. The model writes into objects you select — an existing table, dimension, or document account. Create and bind the destination first; the step doesn’t create new objects.

Add an LLM Step

1. Open the workflow and go to the Analyze Steps tab.
2. Add a step in the position you want, the same way you’d add a standard transform.
3. Choose LLM Step as the step type. The editor opens with three sections: LLM Request, Bindings, and Limits.

Configure the Request

In the LLM Request group:

• LLM Connection (required) — the LLM connection the step uses.
• Model (optional) — a specific model name, such as claude-opus-4-7. Leave it blank to use the connection’s default model.
• Prompt (required) — the instruction sent to the model. You can reference bound objects inline with {{tables.NAME}}, {{dimensions.NAME}}, and {{documents.NAME}}; each reference must match a binding you declare below. Tell the model plainly what to write and where (for example, “write one row per business unit into the summary table”).
• Result schema (optional for Anthropic connections; required for other providers) — a JSON Schema for a structured summary of the run, captured for the record. If you provide one, its root must be a JSON object with "type": "object". With an Anthropic connection you can leave it blank when the model’s real work is the writes it makes through MCP; other providers have no MCP access, so the structured response is their only output and a schema is required.

Bind Project Data

The Bindings section is where you grant access and choose what the step can read and write. It has three groups — Tables, Dimensions, and Documents — each with an Add button. Every row has:

• A selector to pick the object: a table picker, a dimension picker, or (for documents) an account-and-path browser. No more typing IDs by hand.
• A Name — the label you reference in the prompt ({{tables.NAME}}).
• Read and Write checkboxes. Check Read to let the model read the object, Write to let it write into the object, or both. At least one is always set.
• For documents, a Format hint (such as pdf).

How the model writes to each kind, through the MCP tools:

Binding	The model writes by…
Table (Write)	inserting rows — typically a SELECT that produces the rows to add to the bound table.
Dimension (Write)	adding or updating nodes in the bound dimension’s hierarchy.
Document (Write)	uploading a file to the bound document account and path.

Caution

Access is gated to exactly the objects you bind, per checkbox: the model can read only Read-bound objects and write only Write-bound ones. It cannot reach an object you didn’t bind, and it cannot write to a Read-only binding.

Limits

The Limits group bounds the request:

• Max output tokens — the largest response the model may return (1,024 to 128,000; default 16,000).
• Credential TTL (seconds) — how long the step’s scoped, temporary data-access credential stays valid (60 to 3,600; default 1,800). The step’s job is bounded by this window, so set it long enough for the model to finish but no longer than necessary.

Run the Step

The LLM Step runs like any other step — as part of a full workflow run, or on its own (see Running one step in a workflow). When it runs, the step mints a short-lived, scoped credential, sends your prompt and the bound objects to the model, and the model reads and writes through the MCP tools directly. The credential is revoked as soon as the step ends. The model call runs in its own job, so a long-running step doesn’t tie up the workflow runner.

Caution

Each run makes a real, billable call to your LLM provider and writes into your bound objects. Treat a Write binding as you would any other transform target, and test on a scratch table before pointing the step at production data.