Nodes2Cloud MCP Server
OfficialBuild, validate, deploy, run, monitor, and use automation workflows as agent tools in the user's own Cloudflare account via MCP.
Browse the node catalogue and read exact node schemas before authoring.
Create, update, validate, archive, and inspect workflows, including versions and rollbacks.
Check deployment setup, request connection links, verify saved connections, and fetch dynamic service options without exposing secrets.
Deploy workflows, rotate webhook secrets, and retrieve live URLs and deployment status.
Run workflows, list and inspect runs, control durable runs (pause/resume/terminate/send events), and read deployment logs.
View telemetry, Cloudflare health counts, drift, and stored workflow files.
List and call deployed agent-tool workflows, and check plan limits.
Deploys agent-built automation workflows into the user's own Cloudflare account, where they run as Workers; also surfaces deployment telemetry and Cloudflare's own invocation counts and drift for deployed workflows.
Compiles and deploys workflow graphs as Cloudflare Workers in the user's own account, with tools to deploy, list versions, read version graphs, roll back, run workflows, and inspect runs and logs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Nodes2Cloud MCP Server deploy my new lead-notification workflow to my Cloudflare account"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Nodes2Cloud MCP server
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.
Remote endpoint:
https://api.nodes2cloud.com/mcp(Streamable HTTP, OAuth 2.1)Public tool list: https://api.nodes2cloud.com/.well-known/mcp/server-card.json
Connect
Recommended: remote server with OAuth
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/mcpCursor (.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 idFor 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 id or alias, e.g. |
| List the client ids, and which ones get a config file written vs. printed steps |
| Personal Access Token. Falls back to |
|
|
| A custom MCP endpoint URL |
|
|
| Write a token into a project config file that git doesn't ignore. Refused by default, since that file could be committed. |
| 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
In Nodes2Cloud, open Integrations → MCP server → Headless & CI Tokens and create a token (
n2c_pat_…). It is shown once.Run the installer, e.g.
npx -y n2c-mcp@latest install --client claudefor Claude Desktop (its config file only runs local servers), and paste the token at the prompt (or setN2C_API_KEYfirst). 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 | |
| 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. |
| Remote endpoint, |
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
Available Tools
28 toolsarchive_workflowArchive workflowADestructiveIdempotentInspect
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 workflowADestructiveInspect
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 setupARead-onlyIdempotentInspect
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 runADestructiveInspect
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 workflowADestructiveInspect
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 logsARead-onlyIdempotentInspect
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 statusARead-onlyIdempotentInspect
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 optionsARead-onlyIdempotentInspect
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 schemasARead-onlyIdempotentInspect
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 limitsARead-onlyIdempotentInspect
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 runARead-onlyIdempotentInspect
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 workflowARead-onlyIdempotentInspect
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 connectionsARead-onlyIdempotentInspect
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 toolsARead-onlyIdempotentInspect
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 typesARead-onlyIdempotentInspect
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 runsARead-onlyIdempotentInspect
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 filesARead-onlyIdempotentInspect
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 workflowsARead-onlyIdempotentInspect
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 versionsARead-onlyIdempotentInspect
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 workflowADestructiveInspect
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 secretADestructiveInspect
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 workflowADestructiveInspect
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 nodeADestructiveInspect
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 workflowADestructiveInspect
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 workflowARead-onlyIdempotentInspect
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 connectionAIdempotentInspect
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
Scored across 28 tools
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.
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.
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.
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
Related MCP Connectors
The bridge from K2 agents through Wrangler to your master AI - safe, approval-gated Cloudflare ops.
Build, test and publish agentic workflows from your AI client: approve steps, read tables, see runs.
Mini apps your coding agent installs into your own Cloudflare site
Connect AI agents to your own Chrome with scoped access, approvals, and verified task results.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to control a browser through Playwright on Cloudflare Workers, allowing web automation tasks like navigation, typing, clicking, and taking screenshots through natural language commands.Apache 2.0
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to control a browser through Playwright on Cloudflare Workers, allowing them to perform web automation tasks like navigation, typing, clicking, and taking screenshots.Apache 2.0
- AlicenseNot gradedqualityNot gradedmaintenanceEnables AI assistants to control a browser through Playwright running on Cloudflare Workers, allowing web automation tasks like navigation, typing, clicking, and taking screenshots through natural language.8,154 npmApache 2.0
- AlicenseNot gradedqualityNot gradedmaintenanceEnables AI assistants to control a browser through Playwright on Cloudflare Workers, allowing them to perform web automation tasks like navigation, typing, clicking, and taking screenshots.Apache 2.0