NoClick

Self-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 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?}}.

Manual 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.

Manual 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 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 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 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 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 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 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 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 a workflow's saved checkpoints (newest first) with id, name, and timestamp.

Poll 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 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 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 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 the user's workflows. Returns id, name, description, and timestamps.

List the user's available workspaces (personal + organizations). Shows which workspace is currently active. Use switch_workspace to change.

Load 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 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.

Fetch 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 a workflow in the user's browser. Requires the user to have a NoClick tab open.

Report 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 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 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 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).

Execute 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 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 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 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 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.

Batch 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" />

Position 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.

Batch 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 agent and only the fired one delivers. Channel triggers (Telegram/Slack message, alarms) also auto-supply their chat/thread id as the conversation key (per-chat history). For replies into the channel, wire the same service as a tools provider and allowlist its send operations. Trigger choice: the trigger-* nodes each create a NEW NoClick-hosted entry point (trigger-webhook a URL, trigger-email a name@noclick.app inbox, interface-form a public form, trigger-cron a schedule, trigger-run a manual button) and do NOT read the user's existing accounts. For something they already own ("my inbox/Slack/calendar/sheet"), use that integration's OWN trigger operation instead (its x-is-trigger op, e.g. automation-gmail poll_for_new_emails); reserve trigger-* for a genuinely new endpoint. <update_config id="alias-or-id" key="val" /> <update_config id="alias-or-id" field="field_name">large value</update_config> <set_credentials id="alias-or-id" credential_type="credential-uuid" /> <disable_node id="alias-or-id" /> <enable_node id="alias-or-id" /> <mock_node id="alias-or-id" output='{"key":"val"}' /> <mock_node id="alias-or-id">{"key":"val"}</mock_node> <unmock_node id="alias-or-id" /> <update_settings id="alias-or-id" retryOnFail="true" maxTries="3" waitBetweenTries="1000" onError="stopWorkflow" /> update_settings fields: retryOnFail (true|false), maxTries (2-5), waitBetweenTries (0-5000 ms), onError (stopWorkflow|continueRegularOutput|continueErrorOutput), alwaysOutputData (true|false), executeOnce (true|false), notes (free text). All fields are optional — only provided fields are updated. <patch_config id="alias-or-id" field="field_name">unified diff</patch_config> patch_config format (simplified unified diff): @@ anchor_line (locates position in existing code), -old_line (remove), +new_line (add), (space)context_line (unchanged). Example: @@ function App() / - return <div>old</div> / + return <div>new</div> <remove_edge from="..." to="..." handle="optional-handle" /> <remove_node id="..." /> <add_sticky_note name="alias" after="node-a" before="node-b" color="8">markdown content</add_sticky_note> <add_sticky_note name="alias" near="node-a,node-b" direction="above" color="8">markdown content</add_sticky_note> add_sticky_note positioning modes: cover (after+before spans bounding box between two nodes), near (near+direction places adjacent to node group). Anchor params are persisted so sticky notes reposition automatically when nodes move via autolayout. color=0-8 (default 8=black). Reserved attrs per tag: add_node(type, name, label, after, operation), add_edge(from, to, handle, type), remove_edge(from, to, handle), remove_node(id), update_config(id, field), set_credentials(id), disable_node(id), enable_node(id), mock_node(id, output), unmock_node(id), update_settings(id, retryOnFail, maxTries, waitBetweenTries, onError, alwaysOutputData, executeOnce, notes), patch_config(id, field), add_sticky_note(name, after, before, near, direction, color, width, height). All other attrs are config. name= on add_node is a local alias usable in from/to/after/id within the same batch. Dynamic option suffixes in update_config: key__fuzzy="query" - auto-resolve dynamic field by fuzzy match (sets value if 1 match) key__search="query" - preview matching options without setting value key__search_limit="N" - limit search results (default 10, max 50) operation__fuzzy="query" - fuzzy match operation by name or description (auto-sets if 1 match) Flags: - include_operations: returns available operations for each added node type (+ output_handles for multi-output nodes, + per-operation output_schema from past runs showing reference paths) - include_configs: returns config schemas for nodes where operation was set (includes credentials) - include_dynamic_options: auto-load first-level dynamic field options for touched nodes Processing order: add_node → add_edge → add_sticky_note → update_config → patch_config → set_credentials → disable/enable → mock/unmock → update_settings → resolve dynamic options → remove_edge → remove_node IMPORTANT — Sticky note best practice: After building or modifying a workflow, ALWAYS add covering sticky notes to label each major section. Use cover mode (after+before) with a short markdown title only (e.g. '## Data Processing'). For complex workflows, add additional nearby sticky notes with descriptive content explaining the section. This makes workflows self-documenting and easy to understand at a glance.

Update a workflow's name and/or description.

Validate 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 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.