autofill_node
ChatGPTAuto-fill a node's operation and/or config using the internal builder's Pass 2/3 engine (goal + upstream-context driven) — offload a hard node instead of hand-authoring every field. mode: 'full' (operation+fields), 'operation', 'fields', or 'single_field' (needs target_field). Saves the result. The node's goal/label guides the fill.
connect_credential
ChatGPTGet a link the user opens to CONNECT a credential (OAuth or API key) for a node type or credential type. Returns {connect_url, credential_type, ...}. NOTE: the credential is NOT live until the user finishes the flow at that link — re-check with search_credentials afterward before attaching it. Use when a node needs a credential the user hasn't connected yet (search_credentials returns none / credential_requests surfaced).
create_checkpoint
ChatGPTSnapshot the current workflow as a named checkpoint you can restore later. Use before a risky batch of edits so you can roll back.
create_workflow
ChatGPTCreate a new empty workflow. Returns the new workflow's id.
delete_workflow
ChatGPTDelete a workflow by id. This is irreversible.
eval_interface
ChatGPTEvaluate a JavaScript expression inside an interface node's iframe. Use this to interact with rendered interfaces: click buttons, type in inputs, read DOM state, call functions, or test that the UI works correctly. The expression runs in the iframe's context with full DOM access. Returns the eval result plus any SDK calls and console logs that occurred within 100ms after execution (captures async side effects).
get_available_node_types
ChatGPTReturns all ~65 node types with labels (optional query filters by name). Use to BROWSE the catalog; to find the node+operation for an intent (e.g. 'post to slack'), prefer search_operations. Returns: {node_types: [{node_type, label}], count}.
get_console_logs
ChatGPTGet recent console.log/warn/error/info output from interface node iframes. Useful for debugging interface rendering issues, runtime errors, and SDK call results.
get_current_workflow
ChatGPTGet the workflow currently OPEN in the user's browser (nodes, edges, selected node). WARNING: with no browser session (the normal headless case) it does NOT error — it falls back to the user's most-recently-updated workflow (a GUESS) flagged with _fallback/_warning. If you have a specific workflow in mind, use get_workflow(workflow_id) instead; list_workflows to choose. Use node_ids to fetch only specific nodes.
get_execution_status
ChatGPTLook up ONE run by execution_id when you don't have its workflow_id; otherwise use list_executions. Returns: {execution_id, workflow_id, status, started_at, finished_at, nodes_executed, error, trigger_source}.
get_health
ChatGPTSelf-test the MCP server: reports whether the DB pool and execution receiver are reachable. Use to distinguish a backend/infra problem from a bad-input error. Returns: {status: healthy|degraded, checks: {database, receiver}}.
get_node
ChatGPTGet how node(s) are SET UP — config + type + handles (plus latest output/has_mock) — without loading the whole workflow. For just a node's output, prefer the leaner get_node_output. Returns: {node_id: {type, config, output, disabled, has_mock, output_handles?}}.
get_node_configs
ChatGPTManual fallback: returns a node type+operation's config SCHEMA (the fields you can set) — NOT a live node's saved config (use get_node for that). Takes "type:operation" pairs (e.g. ["automation-slack:send_message_to_channel"]). Prefer search_operations(detail_level='full') for intent lookup, or update_workflow(include_configs=true) while building.
get_node_operations
ChatGPTManual fallback: enumerate ALL operations of a known node type. Prefer search_operations for intent-driven lookup, or update_workflow(include_operations=true) while building. Returns: {node_type: {operations: [{name, description, display_name?, category?}], guidance?}}.
get_node_output
ChatGPTGet node outputs in a workflow (batch: pass multiple node_ids). By default returns each node's LATEST output; pass execution_id to fetch a SPECIFIC past run's output instead. Returns: {node_id: {output, has_mock, execution_id?}} — output is null when the node has no output for that run/latest.
get_node_output_history
ChatGPTGet the last N outputs of a SINGLE node (node_id, not a list) ACROSS executions, newest first — vs get_node_output which reads many nodes for ONE run. Use to compare a node's output over time or find a past run. Returns: {history: [{execution_id, created_at, output}]}.
get_node_statuses
ChatGPTGet the latest terminal status (completed/error/skipped) + error per node for a workflow — the same per-node status that drives the canvas chips. run_workflow/run_nodes already include this node_states map in their response, so use this to re-fetch WITHOUT re-running. Returns: {node_states: {node_id: {status, error, finishedAt}}}.
get_sdk_logs
ChatGPTGet recent SDK call logs from the interface iframe (errors, pending calls, etc.). Useful for debugging interface node issues — shows what SDK methods were called, their results or errors, timing, and which node triggered them.
get_selected_node
ChatGPTGet the node the user currently has SELECTED in their browser (BROWSER-ONLY: returns null with no open workflow / API-only access). get_current_workflow already returns selectedNodeId — use this only for a quick peek at the selected node's data.
get_workflow
ChatGPTGet full workflow details including all nodes, edges, and their configs. Use node_ids to fetch only specific nodes (reduces token usage for large workflows).
get_workflow_folders
ChatGPTGet the complete folder tree for organizing workflows. Returns all folders the user has access to in a hierarchical structure with workflow counts. Use this to discover folder IDs for list_workflows or create_workflow.
list_checkpoints
ChatGPTList a workflow's saved checkpoints (newest first) with id, name, and timestamp.
list_credential_requests
ChatGPTPoll the status of connect_credential requests you've minted. Use after handing the user a connect_url to see when they finished — a 'fulfilled' request carries the resulting credential_id you can then attach via set_credentials. Returns: {requests: [{id, credential_type, target_email, status (pending|fulfilled|cancelled), credential_id, created_at, fulfilled_at, expires_at}]}. Filter with status.
list_executions
ChatGPTList recent executions of a workflow (newest first): execution_id, status, trigger_source, timing, nodes_executed, error. Filter by status and/or trigger_source (manual|webhook|cron|mcp|api), or search the error text. Use to find triggered/scheduled/failed runs and their execution_ids.
list_skills
ChatGPTList the reusable skills (curated reference workflows + domain guidance) the user can load — building blocks the internal builder draws on. Returns id, name, description; use load_skill to get the body.
list_tool_calls
ChatGPTList the agent tool calls made during a workflow execution: tool_name, operation, provider node, arguments, result_status, error, duration_ms, created_at. Use to debug what an AI agent node did during a run.
list_workflows
ChatGPTList the user's workflows. Returns id, name, description, and timestamps.
list_workspaces
ChatGPTList the user's available workspaces (personal + organizations). Shows which workspace is currently active. Use switch_workspace to change.
load_options
ChatGPTLoad dynamic dropdown options for a node field (e.g. list spreadsheets, sheets, channels). Requires a credential_id for authenticated nodes. Use context for dependent fields (e.g. pass spreadsheet_id to load sheet names).
load_skill
ChatGPTLoad a skill's full body (a reference workflow rendered as XML, and/or guidance text) to mimic its structure when building. Use ids from list_skills.
load_value
ChatGPTFetch a node's LIVE computed field — the info the config panel shows that is NOT stored in config: webhook_url (webhook/trigger), active_alarms (alarm node's scheduled-alarm list), file_browser (filesystem node's file list), hosted_url (mcp-server hosting link), cron next_run, etc. Call with field_name='' to list what THIS node can load. Returns {value|values} (the field's native shape). NOTE: a few fields provision on load — webhook_url registers the endpoint, hosted_url mints the link — idempotent, but not a pure read.
open_workflow
ChatGPTOpen a workflow in the user's browser. Requires the user to have a NoClick tab open.
report_bug
ChatGPTReport a bug encountered while building or running a workflow. Use this when you encounter an error, unexpected behavior, or something that doesn't work as expected. Include as much detail as possible: what you were trying to do, what happened, and any error messages. priority is 1-10 (higher = more urgent).
request_feature
ChatGPTRequest a feature that would be useful for workflow building. Use this when you identify a missing capability, a workflow pattern that isn't supported, or an improvement that would make building workflows easier or more powerful. priority is 1-10 (higher = more urgent).
restore_checkpoint
ChatGPTRestore a workflow to a saved checkpoint. Replaces the current graph and re-registers webhook/cron resources for restored nodes. Irreversible — create_checkpoint first if you might want the current state back.
run_nodes
ChatGPTRun specific nodes in a workflow for testing. Predecessor nodes are auto-mocked from their last output (missing upstream outputs resolve empty, not an error). Nodes run sequentially in order. SIDE EFFECTS: the target node really executes — don't run write/send/payment nodes without user approval. A node wired into an agent (tool-provider) returns its tool metadata, not an execution. Returns [{node_id, type, success, status: success|error|empty, output|error}] plus a node_states map; set return_output=true for full output instead of a truncated preview (or fetch it via get_node_output).
run_workflow
ChatGPTExecute a workflow. Run validate_workflow first to catch build errors. SIDE EFFECTS: this really runs every node — sends, external writes, payments, deletes. Do NOT run write/send/payment nodes without explicit user approval. Returns {execution_id, status, node_results, node_states (terminal status/error per node)}; fetch full authoritative outputs with get_node_output, inspect agent-node actions with list_tool_calls. Pass inputs={...} to simulate a form submission / webhook body (injected as the trigger node's output). Set return_output=true for full node outputs instead of truncated previews.
save_template_draft
ChatGPTSave a template draft (title and markdown description) for a workflow. This allows iterating on template content before publishing to the template library. IMPORTANT: Call this after every workflow is built or significantly modified. The title should briefly describe what the workflow does and which services/SaaS it uses (e.g. 'AI-Powered RSS Feed Monitor with Slack Notifications'). The description should be detailed markdown covering: what the workflow does, the pipeline steps, input (what triggers it or what data it expects), and output (what it produces or where results go).
search_credentials
ChatGPTSearch the user's credentials. Returns matching credentials with id, name, type, and metadata. Use to find credentials when configuring nodes that require authentication.
search_operations
ChatGPTSearch operations across node types by intent (matches name/description/display_name/category). detail_level: 'name' | 'description' (default) | 'full' (adds the config schema). Scope with node_types, or search all. Progressive disclosure over the thousands of operations without loading them all.
switch_workspace
ChatGPTSwitch between personal and organization workspaces. Pass an organization_id to switch to that org, or pass null/empty to switch to personal. Affects which workflows, folders, and credentials are visible.
update_folders
ChatGPTBatch folder mutations using XML commands. Multiple operations in one call. XML commands: <create_folder name="My Folder" description="optional" parent_folder_id="optional-uuid" /> <update_folder id="folder-uuid" name="New Name" description="New desc" parent_folder_id="new-parent-uuid" /> <delete_folder id="folder-uuid" /> <move_workflow id="workflow-uuid" folder_id="target-folder-uuid" /> <move_workflow id="workflow-uuid" /> <!-- move to root (no folder) --> Processing order: create_folder → update_folder → move_workflow → delete_folder name= on create_folder is a local alias usable in folder_id/parent_folder_id/id within the same batch. Examples: <create_folder name="Projects" /> <create_folder name="Sub" parent_folder_id="Projects" /> <move_workflow id="wf-uuid" folder_id="Projects" />
update_interface
ChatGPTPosition and arrange interface blocks on the 12-column grid layout. Interface blocks correspond to interface- workflow nodes (e.g. interface-form, interface-markdown). Any interface nodes not yet on the grid are auto-created with defaults. XML commands: <set_block_layout id="node-id" x="0" y="0" w="6" h="5" /> <remove_block id="node-id" /> <auto_layout /> <!-- 2-column grid (default) --> <auto_layout strategy="stack" /> <!-- Single column --> Grid: 12 columns, row height 40px. Blocks cannot overlap. id must be a full interface- node ID from the workflow.
update_workflow
ChatGPTBatch XML mutations on a workflow with optional progressive disclosure. XML tags: <add_node type="..." name="alias" label="Human Readable Title" after="node-or-alias" operation="..." key="val" /> after= supports "node:handle" syntax for multi-output nodes, e.g. after="conditional:true" or after="iteration:loop" <add_edge from="alias-or-id" to="alias-or-id" handle="source-handle-id" /> handle is REQUIRED for multi-output nodes (iteration: loop|done, switch: case values, conditional: true|false). Output handles are returned by include_operations and shown in get_workflow XML. For iteration nodes: add a loop-back edge from the last body node TO the iteration node to mark which body node output to aggregate into collected_results. Example: <add_edge from="body-node" to="iteration-node" /> <add_edge from="integration-node" to="agent-node" type="tools" /> — TOOL-PROVIDER wiring: instead of dataflow, the source node's operations become callable agent tools (e.g. a linear node exposes linear__create_issue). Then set the operation allowlist: <update_config id="integration-node" agent_tool_operations='["create_issue","list_issues"]' /> (operation names from include_operations; invalid names are rejected with the valid list). The agent also gets an auto-included {provider}__lookup_options tool for ID fields. Provider-wired nodes do NOT execute in the flow and cannot also feed dataflow consumers, and cannot have a trigger operation selected (either-or — use a separate node per role); they still need credentials (set_credentials) for the agent to call their tools. Use this whenever an AI agent should ACT on a service (create/update/search) rather than a fixed pipeline step. Provider edges appear as type="tools" in get_workflow XML. Rule of thumb: deterministic steps with known inputs → dataflow pipeline; open-ended instructions where the agent picks actions and arguments → provider wiring. When the request is UNDERSPECIFIED (a goal and the services involved but not the exact steps, fields, or branching), PREFER an agent with the relevant integration node(s) wired as tool providers over guessing a rigid pipeline — the agent resolves the specifics at runtime and degrades far more gracefully than a hardcoded flow built on assumptions. Keep its input minimal too: wire any trigger STRAIGHT into the agent rather than a trigger->node->...->agent chain of fetch/transform nodes — the agent fetches itself. The AGENT node's built-in chat (streaming, history) shows in the Interface tab by default — set show_in_interface="false" only when the user explicitly asks to hide it (the chat is also the Test Run surface), and never build a custom chat interface component. Prefer the agent node for open-ended "act on my behalf" work over a one-shot LLM integration node. The agent runs a plain LLM or a full agentic HARNESS — Claude Code/Codex/OpenCode/OpenClaw/Hermes, each a CLI agent with its own built-in tools in a sandbox — set via the agent node model; these are agent models, NOT standalone node types (there is no hermes/codex node). GitHub providers can also MOUNT repos into the agent sandbox: <update_config id="github-node" agent_sandbox_repos='["owner/repo"]' /> — entries are "owner/repo" strings or {"repo": "owner/repo", "branch": "dev"} objects; each is cloned with push access at run start; the agent edits/pushes via execute_bash and opens PRs with github__create_pull_request. RARELY, when an agent must call an API that has NO NoClick node from its shell, request sandbox env vars by declaring their NAMES: <update_config id="agent-node" agent_env_requested='["STRIPE_KEY"]' /> (names only — the user provides values, which become a credential you can never read). Prefer a provider or HTTP Request node; only use env vars when no node exists for the API. <add_edge from="trigger-node" to="agent-node" /> — TRIGGER wiring: a trigger wired directly into an agent delivers its fired event as part of the agent's user turn automatically. Do NOT template trigger references into the agent message — it holds standing instructions; multiple triggers can feed one a…
update_workflow_metadata
ChatGPTUpdate a workflow's name and/or description.
validate_interface
ChatGPTValidate an interface node's JSX/React component headlessly (transpile + render in a server-side sandbox) and return any syntax/runtime error — no browser tab needed. Reads the node's jsx_source.
validate_workflow
ChatGPTValidate a workflow WITHOUT running it (no side effects). Per node: config vs Pydantic model + JSX/placeholder lint, missing required fields, reference validity, and whether a required credential is attached. Runs the SAME checks update_workflow surfaces inline per touched node — use the inline verdict while building, and validate_workflow as the final gate before run_workflow. Returns: {nodes: [{node_id, type, operation, config_valid, validation_error?, missing_required?, reference_warnings?, credentials_missing?, credentials_disconnected?}]}. credentials_disconnected means an ATTACHED credential's provider session is dead (e.g. WhatsApp phone unlinked) — the fix is reconnecting that credential, never creating a duplicate.
