Model Context Protocol (MCP) Setup
Nodes2Cloud runs a remote MCP server. Your coding agent reads the node catalogue, writes the workflow graph, validates it and previews the compiled TypeScript — and when it asks to deploy, the deploy waits for your approval by default. AI is never a deploy bypass.
What the agent can and cannot do
The agent works on the graph, not on code: every deploy is recompiled on our server from the saved graph, never from anything the agent sends. It cannot create a saved connection or read one's secrets — when a workflow needs a service, it sends you a link to connect it yourself.
1. Connect over remote MCP (recommended)
The server speaks MCP over Streamable HTTP at https://api.nodes2cloud.com/mcp. The first time your client connects, your browser opens to sign in and approve access. There is no token to copy or paste.
Claude Code
Terminal commandRun this in your project directory:
claude mcp add --transport http nodes2cloud https://api.nodes2cloud.com/mcp
Cursor
.cursor/mcp.jsonCreate or update .cursor/mcp.json in your project:
{
"mcpServers": {
"nodes2cloud": {
"url": "https://api.nodes2cloud.com/mcp"
}
}
}VS Code
.vscode/mcp.jsonAdd the server to .vscode/mcp.json in your workspace:
{
"servers": {
"nodes2cloud": {
"type": "http",
"url": "https://api.nodes2cloud.com/mcp"
}
}
}The editor's Integrations → MCP server panel has the same snippets, plus one-click install links for Cursor and VS Code.
2. Or use the installer
For clients that only run local MCP servers, or for headless and CI machines, the installer writes your client's config for n2c-mcp, a small local proxy that forwards to the same server using a Personal Access Token:
npx -y n2c-mcp@latest install
Create the token first
The installer is interactive: it asks for a Personal Access Token (it starts with n2c_pat_) and which client to configure. Create the token in the editor under Integrations → MCP server → Headless & CI Tokens, then Generate Token.
Flags, for scripted installs
--token <pat>(or--key) — the Personal Access Token, instead of the prompt.--client <1-11>(or-c) — which client to configure, from the list below.--env—production(the default).stagingandlocalexist for our own development.--print(or--dry-run) — print the config instead of writing it to disk.
- Claude Desktop
- Claude Code
- Antigravity (IDE, SDK, CLI)
- Cursor (current project)
- Windsurf
- Zed
- Codex
- VS Code (global)
- VS Code (current workspace)
- Open Code
- Other — print the config only
npx -y n2c-mcp@latest install --token n2c_pat_… --client 2
3. The 28 tools your agent gets
This list is generated from the server's own tool registrations, so it is the whole set.
Authoring
list_workflowsList the workflows this connection can reach.get_workflowGet a workflow's graph and metadata, or a deployed version's graph next to the one before it.create_workflowCreate a workflow, optionally seeded with a graph.update_workflowReplace a workflow's name, nodes or edges. A stale version is refused rather than overwriting a newer edit.validate_workflowCompile a graph without deploying it and get every error. Optionally returns the compiled Worker code.archive_workflowArchive a workflow. Nothing is deleted, and you can restore it.
Catalogue
list_node_typesSearch the node types a workflow can use.get_node_schemasGet the exact property schema of specific node types.get_dynamic_optionsAsk a connected service which values really exist — sheet tabs, table fields, calendars — instead of guessing.test_run_nodeRun one node on its own to check its settings and connection.
Setup & connections
check_setupCheck whether the account can deploy now and which services a workflow still needs, and follow a connection request.request_connectionsGet one short link for you to connect the services a workflow needs. The agent never handles a secret.list_connectionsList saved connections' names, providers and status, never their secrets.verify_connectionRe-check a saved connection against its provider, live.get_planThe account's plan and every limit on it.
Deploy & versions
deploy_workflowRecompile the saved graph on our server and deploy it to your Cloudflare account — after your approval, by default.list_workflow_versionsOne workflow's deployed versions, and which one is live.rollback_workflowMake an earlier version live again, recompiled on our server from that version's graph.rotate_webhook_secretReplace a webhook's signing secret and redeploy. The old secret stops working.
Run & observe
run_workflowRun a deployed workflow once with a payload. A simple one returns its response; a durable one returns a run id.list_runsRecent runs from the run log, or durable runs including queued, waiting and paused ones.get_runOne run's steps, durations, output and error, and any event it is waiting for.control_runPause, resume or terminate a durable run, or send the event it is waiting for.get_deployment_statusRun and error statistics, Cloudflare's own invocation counts, and whether the deployment still exists — in one call.get_deployment_logsRaw log lines and uncaught exceptions from the deployed Worker.list_workflow_filesFiles a workflow's runs have stored in its own R2 bucket.
Gateway
list_deployed_toolsYour deployed workflows that can be called as tools right now, with their arguments.call_deployed_workflowCall one of them by name or id — including one deployed after the agent connected.
Your deployed workflows become tools too
Give a workflow an MCP Tool trigger and deploy it, and the agent sees it in its tool list as a tool of its own (Developer plan: 3 such tools; Pro: 25). A flat workflow returns its result. A workflow with a durable step — a wait, a delay or a human approval — starts the run and answers with its run id, because a durable run can wait for days. One deployed after the agent connected appears once it reconnects, and is callable straight away through call_deployed_workflow.
4. Deploy approval
By default, every deploy_workflow an agent requests waits for you: an approval prompt appears in your open Nodes2Cloud browser tab, whatever the graph touches. If nobody approves within about 90 seconds the deploy is refused, and a workflow edited while its approval is pending is not deployed. Either way, the deploy is recompiled on our server from the saved graph.
Choose per agent on the /connected-agents page
- Never — the agent cannot deploy. This also blocks its rollbacks and webhook-secret rotations.
- Ask me each time — the default. Every deploy waits for your approval in the browser.
- Deploy without asking — auto mode, on Pro and above, for an agent you trust.
The account-wide default applies to Personal Access Tokens and to any agent without its own setting. The same page can narrow an agent's permissions, limit it to specific workflows, and cap its daily deploys, test runs and tool calls.
rollback_workflow and rotate_webhook_secret redeploy a workflow, recompiled on our server. They respect Never and the daily deploy cap, but they do not raise an approval prompt of their own.
Enhanced protection is a separate setting
Enhanced protection is an encryption option on an individual saved connection: its key is locked to your passkey (or a recovery passphrase), so only your browser can unlock it. When a deploy needs such a credential, you get an extra unlock prompt for it, on top of the deploy approval. With auto mode on a paid plan, a device you have enrolled can unlock it without asking.