Skip to main content
Glama

Nodes2Cloud MCP server

Nodes2Cloud MCP connector – tool definition quality and endpoint health on Glama

Nodes2Cloud lets coding agents (Claude Code, Cursor, VS Code, Windsurf, Zed and other MCP clients) build automation workflows, validate them, and deploy them as Cloudflare Workers in your own Cloudflare account. The server recompiles every deploy itself, and by default each agent deploy waits for you to approve it in the browser.

This package, n2c-mcp, is the stdio entry point: a small local process that forwards MCP messages over HTTPS to the hosted server. It has no runtime dependencies. If your client supports remote MCP servers, you don't need it at all.

Connect

No token to copy. The first connection opens a consent screen in your browser that lists what the agent may do.

claude mcp add --transport http nodes2cloud https://api.nodes2cloud.com/mcp

Cursor (.cursor/mcp.json) and Claude Desktop:

{ "mcpServers": { "nodes2cloud": { "url": "https://api.nodes2cloud.com/mcp" } } }

VS Code (.vscode/mcp.json):

{ "servers": { "nodes2cloud": { "type": "http", "url": "https://api.nodes2cloud.com/mcp" } } }

The installer

npx -y n2c-mcp@latest install                    # pick a client from a menu
npx -y n2c-mcp@latest install --client kiro      # or name it
npx -y n2c-mcp@latest install --list             # every client id

For clients that can sign in through the browser (Kiro, Cursor, VS Code, Antigravity, Zed, Codex, OpenCode and more), the installer writes the remote server's URL into the client's config file and asks for no token: approve the sign-in when the client connects. Pass --key <PAT> to use a Personal Access Token instead. Clients that are set up with their own command (Claude Code, Devin, Gemini CLI…) or in an app's settings (Claude, ChatGPT…) get their exact steps printed instead.

Flag

Meaning

--client, -c

Client id or alias, e.g. kiro, cursor, vscode, codex, claude-code. See --list. The numbers 1–11 from earlier versions still work.

--list

List the client ids, and which ones get a config file written vs. printed steps

--key, --token

Personal Access Token. Falls back to N2C_API_KEY, then a prompt that doesn't echo. Prefer those two: a token on the command line stays in your shell history. Without one, clients that support OAuth sign in through the browser.

--env

production (default), staging or local

--endpoint

A custom MCP endpoint URL

--scope

user or project: which config file to write. Default: the user file if the client has one, else the project's.

--allow-project-token

Write a token into a project config file that git doesn't ignore. Refused by default, since that file could be committed.

--print, --dry-run

Print the setup steps without writing any file

The installer merges into an existing config file and keeps your other servers. When it writes a token, the file is restricted to your user.

stdio clients and CI: this package with a Personal Access Token

  1. In Nodes2Cloud, open Integrations → MCP server → Headless & CI Tokens and create a token (n2c_pat_…). It is shown once.

  2. Run the installer, e.g. npx -y n2c-mcp@latest install --client claude for Claude Desktop (its config file only runs local servers), and paste the token at the prompt (or set N2C_API_KEY first). Or configure a client by hand:

    {
      "mcpServers": {
        "nodes2cloud": {
          "command": "npx",
          "args": ["-y", "n2c-mcp"],
          "env": { "N2C_API_KEY": "<YOUR_N2C_PERSONAL_ACCESS_TOKEN>" }
        }
      }
    }

With a token, the installer writes it into the client's config file in plain text and restricts the file to your user. It won't write a token into a project file that git would commit: add the file to .gitignore, use --scope user, or sign in with OAuth instead. Revoke the token from the same screen when you no longer need it, and create it with the narrowest access that works (e.g. Read only). --client 11 prints the generic stdio entry above with your token filled in.

Environment

Variable

N2C_API_KEY

Personal Access Token. Without it, the server runs in preview mode: it lists its tools, prompts and resource templates from the public server card, and every tool call returns setup instructions instead of doing anything.

N2C_MCP_ENDPOINT

Remote endpoint, https:// only (http:// only for localhost). Default https://api.nodes2cloud.com/mcp.

npx -y n2c-mcp --help and --version are also available.

Related MCP server: Cloudflare Playwright MCP

What an agent can do

The server provides 28 tools, plus one tool per workflow you deploy with an MCP Tool trigger:

  • Author: search the node catalogue and read exact node schemas; create, update, validate (optionally returning the compiled Worker code) and archive workflows.

  • Set up: check what a deploy still needs, send you one link to connect missing services (agents never handle your secrets), and verify a saved connection.

  • Deploy: deploy, list versions, read any version's graph, and roll back. Each deploy is recompiled on the server from the saved graph.

  • Run and observe: run a deployed workflow; list and inspect runs; pause, resume, terminate or send an event to a durable run; read deployment status (telemetry, Cloudflare's own invocation counts, drift) and logs.

  • Use your workflows as tools: call any workflow you deployed with an MCP Tool trigger.

The full list, with every argument schema, is in the docs and the server card.

Security

  • No deploy bypass. Agents can only send workflow graph JSON. Every deploy recompiles that saved graph on the server, exactly like the editor's Deploy button.

  • Approval by default. Unless you choose otherwise on the Connected agents screen, each agent deploy waits for you to approve it in an open Nodes2Cloud tab. You can also turn deploys off for a connection, limit it to specific workflows, and set daily limits.

  • Scoped access. OAuth connections get only the permissions you approve. A Personal Access Token carries your account's default agent policy.

  • Secrets stay put. Credentials are encrypted at rest and deployed as Worker secrets in your Cloudflare account. No tool returns a secret.

  • This package forwards messages and nothing else. It sends your token only to the endpoint you configure (HTTPS by default) and never writes to disk, except when you run install.

Report a vulnerability to security@nodes2cloud.com. See SECURITY.md where available.

Privacy Policy

The full policy is at https://nodes2cloud.com/privacy. In short, for this MCP server:

  • Data collected. Your account identity, the workflow graphs and names agents create, and which tool was called, when, how long it took, its result code and the client's self-reported name. Tool arguments and results are not logged.

  • Use and storage. Workflow graphs and versions are stored to provide the service. Run data and logs from your deployed workflows stay in your Cloudflare account and are read on demand, not stored by Nodes2Cloud.

  • Third-party sharing. Deployed workflows call the services you connect, using your credentials, from your Cloudflare account. Nodes2Cloud's sub-processors are listed at https://nodes2cloud.com/sub-processors.

  • Retention. Account data is kept while your account is active and deleted when you delete the account, as described in the policy.

  • Contact. privacy@nodes2cloud.com.

This package itself collects nothing. It sends a User-Agent of n2c-mcp/<version> with each request.

Support

support@nodes2cloud.com · Issues

License

Apache License 2.0

Available Tools

28 tools
archive_workflowArchive workflowA
DestructiveIdempotent
Inspect

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.

Inputs: workflowId (required). Returns: message, success

call_deployed_workflowCall deployed workflowA
Destructive
Inspect

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.

Inputs: name (required), arguments. Returns: ok, body, status, durationMs, +2 more

check_setupCheck setupA
Read-onlyIdempotent
Inspect

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.

Inputs: sessionId, workflowId. Returns: ready, providers, cloudflare, missingProviders, +1 more

control_runControl runA
Destructive
Inspect

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.

Inputs: action (required), instanceId (required), workflowId (required), payload, +1 more. Returns: note, action, status, nextTool, +4 more

create_workflowCreate workflowAInspect

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.

Inputs: name (required), edges, nodes. Returns: id, name, edges, nodes, +8 more

deploy_workflowDeploy workflowA
Destructive
Inspect

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.

Inputs: workflowId (required), requestState. Returns: url, cron, warning, warnings, +8 more

get_deployment_logsGet deployment logsA
Read-onlyIdempotent
Inspect

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.

Inputs: workflowId (required), limit, since, source. Returns: lines, since, source, caveats, +4 more

get_deployment_statusGet deployment statusA
Read-onlyIdempotent
Inspect

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.

Inputs: workflowId (required), since, include. Returns: drift, stats, health, warnings

get_dynamic_optionsGet dynamic optionsA
Read-onlyIdempotent
Inspect

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.

Inputs: loader (required), workflowId (required), credentialId (required), params. Returns: fields, options

get_node_schemasGet node schemasA
Read-onlyIdempotent
Inspect

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.

Inputs: types (required). Returns: schemas

get_planGet plan and limitsA
Read-onlyIdempotent
Inspect

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.

Inputs: no named parameters. Returns: personal, workspaces

get_runGet runA
Read-onlyIdempotent
Inspect

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.

Inputs: workflowId (required), simple, instanceId, executionId. Returns: error, steps, output, source, +6 more

get_workflowGet workflowA
Read-onlyIdempotent
Inspect

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.

Inputs: workflowId (required), versionNumber. Returns: id, name, edges, nodes, +10 more

list_connectionsList connectionsA
Read-onlyIdempotent
Inspect

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.

Inputs: no named parameters. Returns: connections

list_deployed_toolsList deployed toolsA
Read-onlyIdempotent
Inspect

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.

Inputs: no named parameters. Returns: note, tools, truncated

list_node_typesList node typesA
Read-onlyIdempotent
Inspect

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.

Inputs: name. Returns: nodes

list_runsList runsA
Read-onlyIdempotent
Inspect

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.

Inputs: workflowId (required), limit, order, cursor, +2 more. Returns: runs, cursor, source, nextTool, +2 more

list_workflow_filesList workflow filesA
Read-onlyIdempotent
Inspect

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.

Inputs: workflowId (required), limit, cursor. Returns: files, cursor, readPath

list_workflowsList workflowsA
Read-onlyIdempotent
Inspect

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.

Inputs: no named parameters. Returns: workflows

list_workflow_versionsList workflow versionsA
Read-onlyIdempotent
Inspect

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

Inputs: workflowId (required). Returns: versions

request_connectionsRequest connectionsAInspect

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.

Inputs: providers (required), workflowId. Returns: expiresAt, providers, sessionId, connectUrl

rollback_workflowRoll back workflowA
Destructive
Inspect

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.

Inputs: workflowId (required), versionNumber (required), restoreDraft. Returns: url, cron, warning, warnings, +8 more

rotate_webhook_secretRotate webhook secretA
Destructive
Inspect

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.

Inputs: workflowId (required). Returns: ok, webhookSecrets

run_workflowRun workflowA
Destructive
Inspect

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.

Inputs: workflowId (required), via, payload, instanceId. Returns: ok, via, body, note, +6 more

test_run_nodeTest run nodeA
Destructive
Inspect

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.

Inputs: nodeId (required), workflowId (required).

update_workflowUpdate workflowA
Destructive
Inspect

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.

Inputs: updatedAt (required), workflowId (required), name, edges, +1 more. Returns: id, name, edges, nodes, +8 more

validate_workflowValidate workflowA
Read-onlyIdempotent
Inspect

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.

Inputs: edges, nodes, workflowId, includeCode. Returns: valid, errors, script, metadata

verify_connectionVerify connectionA
Idempotent
Inspect

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.

Inputs: credentialId (required). Returns: id, kind, name, scopes, +13 more

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.3/5.0

    Scored across 28 tools

    Disambiguation4/5

    Most tools target a clearly distinct resource and action, and the descriptions explicitly separate similar areas such as deployment health vs. logs vs. run history. A few pairs could still be confused at a glance, notably run_workflow vs. call_deployed_workflow and list_workflows vs. list_deployed_tools, but the descriptions resolve them.

    Naming Consistency5/5

    All 28 tools follow a consistent snake_case verb_noun pattern (list_, get_, create_, update_, deploy_, check_, etc.). Compound nouns like rotate_webhook_secret and get_deployment_status are still predictable and readable.

    Tool Count3/5

    At 28 tools this is heavy for an agent-facing set and exceeds the typical comfortable range. The domain is genuinely broad—workflow authoring, deployment, monitoring, connections, and agent tools—so most tools earn their place, but some monitoring/run tools could likely be consolidated.

    Completeness4/5

    Coverage is strong: workflow CRUD, validation, deploy, versioning/rollback, run execution and control, logs/status, node schemas, setup/connections, file listing, webhook secret rotation, and deployed-tool discovery/calling. The main gap is that archiving is a dead end within MCP—there is no restore/unarchive or delete operation, requiring the user to go to the editor.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers