Nodes2Cloud

List the workflows this connection can access, personal and shared through a workspace, most recently updated first. Each entry has its id, name, status and live URL if deployed. Start here to find a workflowId. If the owner restricted this connection to certain workflows, only those are listed and every other id is refused.

Takes no parameters.

Get one workflow's editable graph (nodes, edges, settings) and metadata, including the `updatedAt` value update_workflow requires. Pass `versionNumber` to instead get that deployed version's frozen graph together with the version before it (`previousVersion`, null for version 1), so you can see what changed; list_workflow_versions gives the numbers.

Create a new, undeployed workflow, optionally with an initial graph. Look up node types with list_node_types and get_node_schemas first rather than guessing property names. Returns the saved workflow, including its id and `updatedAt`. Nothing runs or deploys until deploy_workflow. Refused when the plan's workflow limit is reached or this connection is restricted to existing workflows.

Replace a workflow's saved draft: any of name, nodes and edges you pass overwrite the stored ones whole (send the complete node and edge lists, not a patch). Requires the `updatedAt` from your last get_workflow or create_workflow; if someone edited it since, this returns `conflict` and changes nothing, so re-read and retry. Does not touch what is deployed. Returns the saved workflow with its new `updatedAt`.

Compile a workflow without deploying it and report every error, each with the node it concerns. Use it after every edit and before deploy_workflow. Checks the saved graph by workflowId, or an unsaved graph passed as nodes and edges (given with a workflowId, they replace the saved ones for this check only). Set includeCode to also get the generated Worker script and its metadata (target, bindings, size) to show the user.

Deploy a saved workflow to the user's own Cloudflare account, replacing any live version. The server recompiles the saved graph itself; no code you send is ever deployed. Save and validate first, and call check_setup early so missing connections are fixed in time. Unless the owner allowed this connection to deploy without asking, the call waits up to 90 seconds for the owner to approve it in an open Nodes2Cloud browser tab: tell the user to approve it there. Some protected connections need an extra approval each. Editing the workflow while approval is pending cancels the deploy. If a needed service is not connected and your client supports URL elicitation, you get `input_required` with a link and a `requestState`: show the link, wait, then retry with the same workflowId and that requestState. Returns the deployment id, version number and live URL.

Archive a workflow: it leaves the active list and can no longer be edited or deployed until the owner restores it in the Nodes2Cloud editor. Nothing is permanently deleted, and a version already deployed keeps running in the user's Cloudflare account. Only use this when the user asks to remove a workflow. Archiving twice is harmless.

List the services the user has connected (Slack, Google, Stripe and so on), with each connection's id, provider, name, kind and status. Metadata only: no secret or token is ever returned. Put a connection's id in a node's credential field when building a workflow. To see only what one workflow still needs, use check_setup instead.

Takes no parameters.

Search the catalogue of node types a workflow can use: triggers (webhook, schedule, email, agent tool), logic (if, switch, loop, wait, code) and integrations with third-party services. Returns each type's id, display name, description, category and group, without property schemas to keep it small. Filter with `name`, then call get_node_schemas for the exact types you will use. Needs no account data.

Get the full property schema of one or more node types: every property's key, type, options, default and whether it is required, plus input and output ports. Use it before writing a node's `data` so property names are exact rather than guessed. An unknown type comes back with an `error` entry instead of failing the call.

Run one saved node on its own, for real, to check its configuration and connection, the way the editor's test button does. It makes the node's actual call to the third-party service, so a 'send' node really sends. With no upstream run, `{{ … }}` expressions are passed through as literal text; the result names any field that affected. To test with real data flowing between nodes, deploy and use run_workflow. Returns the node's raw output.

Check whether the user can deploy right now and what is missing: whether Cloudflare is connected (including the one-time workers.dev subdomain step, which otherwise only fails after a deploy) and, given a workflowId, which services its nodes need that are not connected yet (`missingProviders`). Call it early, while building, so the user can fix setup in parallel. After request_connections, call it again with that sessionId to poll the user's progress: `connectionRequest.complete` turns true once they are done. Never returns a secret.

Create one short link the user opens to connect the services you name, with one button per service. Use the ids from check_setup's `missingProviders`, plus `cloudflare` if it is not connected. You cannot create a connection yourself, and must never ask the user to paste a secret into the chat: give them this link instead. Then poll check_setup with the returned sessionId and continue once `connectionRequest.complete` is true. Returns sessionId, connectUrl and expiresAt.

Run a deployed workflow once, for real, with an optional JSON payload as its trigger input, and return what happened. A simple workflow answers with its HTTP status, duration and response body. A durable one (with a wait, delay, approval or sub-workflow) starts a run and returns its instanceId and status: follow it with get_run. Use it after deploying to show the user a real result. It runs in the user's Cloudflare account against their real services, so it has real effects, and Nodes2Cloud stores nothing about it. Counts toward this connection's daily limit on workflow calls.

List a deployed workflow's recent runs, newest first, read on demand from the user's own Cloudflare account. `source: history` (default) lists completed runs with an executionId, status and duration from the workflow's run log; it is empty until something has actually run. `source: instances` lists durable runs with an instanceId, including ones still queued, waiting or paused, and can filter by `status`. Pass the returned `cursor` back to get the next page. Open one run with get_run.

Get one run's details. Pass `executionId` (from list_runs source history) for step-by-step status, durations and recorded inputs and outputs. Pass `instanceId` (from run_workflow or list_runs source instances) for a durable run's state, step history, output and error, plus `awaitingEvents`: the event types it is parked on, which control_run send_event must use. Pass exactly one of the two. Set `simple` with instanceId to get only the status, for cheap polling.

Act on one in-flight durable run: `pause`, `resume`, `terminate` (stops it where it is; completed steps are not undone), or `send_event` to deliver an event to a run parked on a wait or approval, resuming it. For send_event, read get_run first and use one of its `awaitingEvents` as `eventType`: Cloudflare accepts any type, so a wrong one silently does nothing. To run a workflow again from the start, use run_workflow; replaying from a step is not offered because it would repeat effects that already happened.

Answer 'is this deployed workflow healthy, and is it still what we deployed?' in one call. `stats`: run counts, error rates and p50/p95 durations per node type from the workflow's own telemetry. `health`: Cloudflare's independent count of invocations, errors and CPU time, which also catches failures the telemetry cannot see. `drift`: whether the deployed script still exists in the user's Cloudflare account (catching one deleted by hand) and, with GitHub sync, how far the mirror is behind; plan-gated. Each section answers on its own: one that cannot be read carries an `error` and is listed in `warnings`, and the rest still return. Read each section's `caveats` before concluding. For raw log lines use get_deployment_logs.

Read the raw log lines and uncaught exceptions a deployed workflow produced in the user's Cloudflare account, newest first. Use it when a run failed without explanation, or get_deployment_status shows errors you need to see. `source` in the answer says which log store responded; null means neither had anything for this window, which is not an error.

List one workflow's deployed versions, newest first, marking which one is live now. Every deploy creates a version. Use the version numbers with get_workflow (to read or compare a version's graph) and rollback_workflow (to make an earlier one live again).

Make an earlier deployed version of a workflow live again in the user's Cloudflare account, replacing what is running now. Get version numbers from list_workflow_versions. Only do this when the user asks. Refused if the owner turned off deploys for this connection. For a durable workflow, the answer warns about runs the outgoing version left in flight. Set restoreDraft to also load that version back as the editable draft.

List the files a deployed workflow's runs have stored in its own storage bucket in the user's Cloudflare account, with each file's key, size and last-modified time. `readPath` is the URL template that downloads one file. A workflow that never stored a file returns an empty list, not an error. Pass `cursor` back for the next page.

Check a saved connection against its provider right now (a read-only identity call) and record the result. Use it when a node fails with what looks like an authentication error: access that worked when it was saved may since have been revoked or narrowed. Returns the connection's metadata with its new status, never the secret. Some providers cannot be checked on their own, and neither can a connection under the owner's extra passkey protection; both answer `not_eligible`.

Generate a new secret for a deployed workflow's webhook trigger, redeploy it, and return the new secret. This immediately breaks anything still calling the webhook with the old secret, so only do it when the user asks or needs the secret to call the webhook themselves. The new secret takes a few seconds to go live: treat a single 401 right afterwards as propagation delay, wait and retry, and do not rotate again. Refused if the owner turned off deploys for this connection.

Read the user's plan and its limits: how many workflows may be saved and live at once, how many deployed workflows can be offered to agents as tools, and which features are included. Also lists each shared workspace's own limits, since a workflow's limits come from its owner's plan. Check this before telling the user something is impossible: a refusal is often a plan limit, not a bug.

Takes no parameters.

Ask a connected service which values really exist, such as a spreadsheet's tab names, an Airtable base's tables and typed fields, a Typeform's questions or a Google account's calendars. Use it while configuring a node instead of guessing a name: a guessed tab or field deploys fine and only fails later on the user's real data. Read-only. Returns `options` (label and value pairs) or, for field pickers, `fields` with types and allowed values.

Call one of the user's deployed agent-tool workflows (those with an MCP Tool trigger) by its tool name or workflow id, with the arguments its schema declares. Use it when the workflow is not in your tool list: one deployed since you connected only appears there after you reconnect, but is callable here at once. It runs for real in the user's Cloudflare account and counts toward this connection's daily limit on workflow calls. list_deployed_tools shows what is callable and the arguments each takes.

List the user's deployed workflows that agents can call as tools right now (those deployed with an MCP Tool trigger), each with its tool name, description and argument schema. Use it to find a workflow deployed after you connected, then call it with call_deployed_workflow. If the plan's limit hides some, the answer says how many.

Takes no parameters.