# Nodes2Cloud (npm · n2c-mcp)

Build, validate and deploy workflows as Cloudflare Workers in your own account, with approval.

- Trust score: 88/100 (high trust)
- Change this week: +5
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `api.nodes2cloud.com`: 38/100, [markdown](https://verifymcp.io/servers/com-nodes2cloud-mcp/api.md), [page](https://verifymcp.io/servers/com-nodes2cloud-mcp/api)
- npm · `n2c-mcp`: 88/100 (this document), [markdown](https://verifymcp.io/servers/com-nodes2cloud-mcp/n2c-mcp.md), [page](https://verifymcp.io/servers/com-nodes2cloud-mcp/n2c-mcp)

## Channel facts

- Registry: `npm`
- Package: `n2c-mcp`
- Version: `1.2.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - No production dependencies, so there is no dependency health to assess.
- **Provenance & Transparency**: 100/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to nodes2cloud-com/n2c-mcp).
  - Clear OSI-approved license (Apache-2.0).
  - Actively maintained (last published 11 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 82/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 4480 tokens (~160/item across 28 items; 28 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 40/100
  - Stability observed for 12 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 98% of tool parameters carry a description.
  - Structured output schemas are declared (96% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 29 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Nodes2Cloud MCP server?

Nodes2Cloud runs locally as an npm package, launched with npx -y n2c-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add com-nodes2cloud-mcp -- npx -y n2c-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "com-nodes2cloud-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "n2c-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-nodes2cloud-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "n2c-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add com-nodes2cloud-mcp -- npx -y n2c-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-nodes2cloud-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "n2c-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-nodes2cloud-mcp --command npx --arg -y --arg n2c-mcp
```

### Hermes

```yaml
mcp_servers:
  com-nodes2cloud-mcp:
    command: "npx"
    args: ["-y", "n2c-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "com-nodes2cloud-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "n2c-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-nodes2cloud-mcp -t stdio -c npx -a -y n2c-mcp
```

### Other

```json
{
  "mcpServers": {
    "com-nodes2cloud-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "n2c-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-04 (score 88, +1)

No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-01 (score 87, +4)

- [functional improvement] Stability: unverified → 0.27

### 2026-10-31 (score 83, +1)

- [functional improvement] Security disclosure: unverified → pass

### 2026-10-30 (score 82, −1)

- [functional regression] Security disclosure: pass → unverified

### 2026-10-25 (score 83, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-10-24 (score 68)

First indexed and scored.

## MCP tools (28)

### `list_workflows` (~73 tokens)

List workflows

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.

Output parameters:

- `workflows` (array)

### `get_workflow` (~127 tokens)

Get workflow

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.

Input parameters:

- `versionNumber` (integer): A saved version to read instead of the current draft. Omit for the draft.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `authoredVia` (string)
- `authoredViaClient` (string)
- `createdAt` (string)
- `deployedWorkerUrl` (string)
- `edges` (array)
- `id` (string)
- `name` (string)
- `nodes` (array)
- `ownerId` (string)
- `previousVersion`
- `settings` (object)
- `status` (string)
- `updatedAt` (string)
- `version` (object)

### `create_workflow` (~123 tokens)

Create workflow

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.

Input parameters:

- `edges` (array): Initial edges between those nodes.
- `name` (string, required): Human-readable workflow name.
- `nodes` (array): Initial nodes. Omit to start empty.

Output parameters:

- `authoredVia` (string)
- `authoredViaClient` (string)
- `createdAt` (string)
- `deployedWorkerUrl` (string)
- `edges` (array)
- `id` (string)
- `name` (string)
- `nodes` (array)
- `ownerId` (string)
- `settings` (object)
- `status` (string)
- `updatedAt` (string)

### `update_workflow` (~197 tokens)

Update workflow

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

Input parameters:

- `edges` (array): The complete new edge list. Omit to keep the current edges.
- `name` (string): New name. Omit to keep it.
- `nodes` (array): The complete new node list. Omit to keep the current nodes.
- `updatedAt` (string, required): The workflow's `updatedAt` exactly as last returned to you.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `authoredVia` (string)
- `authoredViaClient` (string)
- `createdAt` (string)
- `deployedWorkerUrl` (string)
- `edges` (array)
- `id` (string)
- `name` (string)
- `nodes` (array)
- `ownerId` (string)
- `settings` (object)
- `status` (string)
- `updatedAt` (string)

### `validate_workflow` (~182 tokens)

Validate workflow

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.

Input parameters:

- `edges` (array): Edges to check instead of the saved ones. Pass with nodes.
- `includeCode` (boolean): Also return the compiled script and metadata when valid. Default false, to save tokens.
- `nodes` (array): Nodes to check instead of the saved ones. Pass with edges.
- `workflowId` (string): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `errors` (array)
- `metadata`
- `script` (string)
- `valid` (boolean)

### `deploy_workflow` (~239 tokens)

Deploy workflow

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.

Input parameters:

- `requestState` (string): Only on a retry: the opaque requestState from a previous `input_required` answer to this same call. Never invent or edit one.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `cron` (string)
- `deploymentId` (string)
- `elicitation` (object)
- `missingProviders` (array)
- `requestState` (string)
- `resultType` (string)
- `retryGuidance` (string)
- `setupGaps` (array)
- `url` (string)
- `versionNumber` (number)
- `warning` (string)
- `warnings` (array)

### `archive_workflow` (~96 tokens)

Archive workflow

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.

Input parameters:

- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `message` (string)
- `success` (boolean)

### `list_connections` (~80 tokens)

List connections

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.

Output parameters:

- `connections` (array)

### `list_node_types` (~124 tokens)

List node types

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.

Input parameters:

- `name` (string): Case-insensitive substring matched against the type id and display name, e.g. 'slack'.

Output parameters:

- `nodes` (array)

### `get_node_schemas` (~105 tokens)

Get node schemas

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.

Input parameters:

- `types` (array, required): Exact type ids from list_node_types, e.g. ['webhook_trigger', 'if'].

Output parameters:

- `schemas` (array)

### `test_run_node` (~144 tokens)

Test run node

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.

Input parameters:

- `nodeId` (string, required): The node's id within the saved graph.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

### `check_setup` (~154 tokens)

Check setup

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.

Input parameters:

- `sessionId` (string): A sessionId from request_connections, to poll that request's progress.
- `workflowId` (string): Also report which services this workflow still needs connected.

Output parameters:

- `cloudflare` (object)
- `connectionRequest` (object)
- `missingProviders` (array)
- `providers` (array)
- `ready` (boolean)

### `request_connections` (~147 tokens)

Request connections

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.

Input parameters:

- `providers` (array, required): Provider ids, e.g. ["google_gmail","slack","cloudflare"].
- `workflowId` (string): The workflow this is for, if any.

Output parameters:

- `connectUrl` (string)
- `expiresAt` (string)
- `providers` (array)
- `sessionId` (string)

### `run_workflow` (~256 tokens)

Run workflow

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.

Input parameters:

- `instanceId` (string): Your own id for a durable run, so you can poll it with get_run. Implies via `instance`. Cannot start with 'cf_'.
- `payload` (object): JSON trigger input, as a webhook body would carry it. Defaults to {}.
- `via` (string): `auto` (default) calls the live trigger, or starts a durable run when the trigger's secret cannot be reproduced. `instance` always starts a durable run (durable workflows only).
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `body`
- `curlCommand` (string)
- `durationMs` (number)
- `instanceId` (string)
- `nextTool` (string)
- `note` (string)
- `ok` (boolean)
- `status`
- `statusText` (string)
- `via` (string)

### `list_runs` (~239 tokens)

List runs

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.

Input parameters:

- `cursor` (string): The cursor from the previous page, with the same source and order.
- `limit` (integer): Runs per page, 1-100. Default 20.
- `order` (string): Only with source `history`. Default newest; oldest pages through all retained history.
- `source` (string): `history` (default): the run log. `instances`: durable runs and their state.
- `status` (string): Only with source `instances`: return runs in this state.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `cursor` (string)
- `instances` (array)
- `nextTool` (string)
- `runs` (array)
- `source` (string)
- `truncated` (boolean)

### `get_run` (~198 tokens)

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.

Input parameters:

- `executionId` (string): A run-log id from list_runs (source history).
- `instanceId` (string): A durable run's id from run_workflow or list_runs (source instances).
- `simple` (boolean): With instanceId only: skip step detail and return status and stepCount.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `awaitingEvents` (array)
- `error`
- `executionId` (string)
- `instanceId` (string)
- `output`
- `source` (string)
- `startedAt` (string)
- `status` (string)
- `stepCount` (number)
- `steps` (array)

### `control_run` (~210 tokens)

Control run

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.

Input parameters:

- `action` (string, required)
- `eventType` (string): Required for send_event: one of the run's awaitingEvents, exactly.
- `instanceId` (string, required): The durable run's id.
- `payload` (object): send_event only: JSON delivered to the waiting node.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `action` (string)
- `delivered` (boolean)
- `eventType` (string)
- `instanceId` (string)
- `nextTool` (string)
- `note` (string)
- `status` (string)
- `timestamp` (string)

### `get_deployment_status` (~231 tokens)

Get deployment status

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.

Input parameters:

- `include` (array): Sections to read. Default all three; fewer is faster.
- `since` (string): Time window for stats and health. Default 24h.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `drift` (object)
- `health` (object)
- `stats` (object)
- `warnings` (array)

### `get_deployment_logs` (~168 tokens)

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.

Input parameters:

- `limit` (integer): Lines to return, 1-100. Default 50.
- `since` (string): Time window. Default 24h.
- `source` (string): Force one store: Cloudflare Workers Logs, or the workflow's own log forwarder. Default tries the first, then the second.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `caveats` (array)
- `lines` (array)
- `rowsRead` (number)
- `scriptName` (string)
- `since` (string)
- `source`
- `unavailable` (object)
- `workflowId` (string)

### `list_workflow_versions` (~85 tokens)

List workflow versions

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

Input parameters:

- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `versions` (array)

### `rollback_workflow` (~154 tokens)

Roll back workflow

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.

Input parameters:

- `restoreDraft` (boolean): Also replace the editable draft with this version's graph. Default false.
- `versionNumber` (integer, required): The version to make live, from list_workflow_versions.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `cron` (string)
- `deploymentId` (string)
- `elicitation` (object)
- `missingProviders` (array)
- `requestState` (string)
- `resultType` (string)
- `retryGuidance` (string)
- `setupGaps` (array)
- `url` (string)
- `versionNumber` (number)
- `warning` (string)
- `warnings` (array)

### `list_workflow_files` (~138 tokens)

List workflow files

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.

Input parameters:

- `cursor` (string): The cursor from the previous page.
- `limit` (integer): Files per page, 1-1000. Default 100.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `cursor` (string)
- `files` (array)
- `readPath` (string)

### `verify_connection` (~120 tokens)

Verify connection

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

Input parameters:

- `credentialId` (string, required): The connection's id, from list_connections or check_setup.

Output parameters:

- `accountEmail` (string)
- `cloudflareAccountId` (string)
- `cloudflareWorkersPlan` (string)
- `createdAt` (string)
- `expiresAt` (string)
- `id` (string)
- `kind` (string)
- `lastProbedAt` (string)
- `name` (string)
- `probeError` (string)
- `probeStatus` (string)
- `probedZonePlanTier` (string)
- `provider` (string)
- `scopeWarning` (string)
- `scopes` (array)
- `workspaceId` (string)
- `wrapMethod` (string)

### `rotate_webhook_secret` (~129 tokens)

Rotate webhook secret

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.

Input parameters:

- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `ok` (boolean)
- `webhookSecrets` (object)

### `get_plan` (~87 tokens)

Get plan and limits

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.

Output parameters:

- `personal` (object)
- `workspaces` (array)

### `get_dynamic_options` (~190 tokens)

Get dynamic options

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.

Input parameters:

- `credentialId` (string, required): A credential for the loader's provider — check_setup reports what is connected.
- `loader` (string, required): Which picker to run.
- `params` (object): Loader-specific selectors, e.g. { spreadsheetId }, { baseId, tableId }, { sobject }.
- `workflowId` (string, required): The workflow's id, from list_workflows or create_workflow.

Output parameters:

- `fields` (array)
- `options` (array)

### `call_deployed_workflow` (~151 tokens)

Call deployed workflow

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.

Input parameters:

- `arguments` (object): Arguments matching that tool's schema, from list_deployed_tools.
- `name` (string, required): The tool name from the workflow's MCP Tool trigger, or the workflow id.

Output parameters:

- `body`
- `curlCommand` (string)
- `durationMs` (number)
- `ok` (boolean)
- `status` (number)
- `statusText` (string)

### `list_deployed_tools` (~78 tokens)

List deployed tools

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.

Output parameters:

- `note` (string)
- `tools` (array)
- `truncated` (number)

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/com-nodes2cloud-mcp/n2c-mcp#diagnostics

## Score history

- 2026-11-05: 88
- 2026-11-04: 88
- 2026-11-03: 87
- 2026-11-02: 87
- 2026-11-01: 87
- 2026-10-31: 83
- 2026-10-30: 82
- 2026-10-29: 83
- 2026-10-28: 83
- 2026-10-27: 83
- 2026-10-26: 83
- 2026-10-25: 83
- 2026-10-24: 68

## Common questions

### What is the Nodes2Cloud MCP server?

Nodes2Cloud is an MCP server listed in the public MCP registry as com.nodes2cloud/mcp. Build, validate and deploy workflows as Cloudflare Workers in your own account, with approval. This page covers its npm package (n2c-mcp).

### Is the Nodes2Cloud MCP server safe to use?

Nodes2Cloud scores 88 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Nodes2Cloud MCP server expose?

Nodes2Cloud exposes 28 tools: list_workflows, get_workflow, create_workflow, update_workflow, validate_workflow, and 23 more. Their descriptions and schemas cost roughly 4,225 tokens of context every time the server is loaded.

### Is the Nodes2Cloud MCP server still maintained?

Nodes2Cloud is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Nodes2Cloud MCP server under?

Nodes2Cloud declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/n2c-mcp
- Socket report: https://socket.dev/npm/package/n2c-mcp
- Repository: https://github.com/nodes2cloud-com/n2c-mcp
- Website: https://docs.nodes2cloud.com/docs/getting-started/mcp
- Changelog RSS feed: https://verifymcp.io/servers/com-nodes2cloud-mcp/n2c-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-nodes2cloud-mcp/n2c-mcp.json
- HTML version of this page: https://verifymcp.io/servers/com-nodes2cloud-mcp/n2c-mcp