An MCP server turns “deploy nginx for a month” into a signed, paid app on Flux, without an account. The catch is the keys, and an underpayment that does not come back.
Flux Cloud is a decentralized cloud. You describe an app, the network runs it on other people’s machines, and you pay in FLUX. Until recently that meant writing a specification, checking a price, signing it, and broadcasting a payment yourself.
Flux Cloud MCP puts that whole path behind the Model Context Protocol, the plug that lets an assistant call outside tools. You tell Claude, Cursor, or any other MCP host what you want. The server builds the spec, asks the network for a price, and, only if you confirm, pays and waits until the app is up.
There is no Flux account. Two keys are the identity.
What you can actually do
The current package, @runonflux/flux-cloud-mcp v0.2.7, exposes 15 tools. Most of them only look. Two of them can spend money, and only when a call includes confirm=true.
See the network and your apps. flux_get_network_info returns node counts, chain height, the FLUX price, and the address deployments pay. flux_get_pricing returns the USD rate card, the live FLUX rate, discounts, and reference sizes. flux_get_app looks up any app by name: its spec, when it expires, running instances, and URLs. flux_list_my_apps lists the ones your Flux ID owns, with instance counts and days left. flux_get_identity shows that ID, the payment address, and the balance in FLUX and dollars.
Design before you spend. flux_build_spec turns a plain description (container image, ports, CPU, RAM, disk, and how many months) into a full version-8 app spec, with public ports picked for you and data replication turned on. flux_validate_spec checks that spec against local rules and then against a real FluxOS node: is the image reachable, is the name free, will the network accept it. flux_quote_app asks the network what a new app, or an update, will cost in dollars and in FLUX. None of this moves money.
Deploy, watch, and stop. With confirm=true, flux_deploy_app signs the spec with your Flux ID, broadcasts it, and pays the quoted FLUX. Without that flag it only returns the plan: price, balance, and warnings. flux_wait_for_app polls until the payment is accepted and instances are running, then hands back the URLs. After that you can read container logs (flux_get_app_logs), see live CPU, memory, and network (flux_get_app_stats), and restart, redeploy, or remove instances (flux_control_app). flux_cancel_app, again only with confirm=true, ends an app early by shortening its term so the network uninstalls it.
The server also ships guides the agent can read (flux://guide/overview, spec format, pricing, and gotchas) and a deploy_on_flux prompt that walks a deployment from start to finish.
How a build actually goes
The project’s own walkthrough is the clearest picture. You say: deploy nginx on Flux, three instances, one month.
- The agent checks who you are. In the example, the Flux ID starts
1Ab…, the payer startst1Cd…, and the wallet holds 996.98 FLUX, shown as $48.74. - It builds a v8 spec. The public port in the example is 39978, forwarded to port 80 inside the container, with a data volume at
r:/data. - It quotes the network. The example comes back at $0.99 for one month, which is 19.24 FLUX after the 5 percent discount for paying in FLUX.
- You agree. Only then does
flux_deploy_apprun withconfirm=true. The example records a message hash, a payment of 19.24 FLUX, and a transaction id. flux_wait_for_appwaits until the app is accepted (in the example, at block height 2941560) and all three instances are running, then returns a URL likehttps://myapp.app.runonflux.io.
Those figures are the README’s sample session, not a live price checked on 3 October 2026. Every quote the server shows is meant to match what home.runonflux.io charges: the USD price, converted to FLUX at the live rate, with that 5 percent pay-in-FLUX discount. Quotes come from the network endpoint /apps/calculatefiatandfluxprice, so they include the $0.99 minimum, hardware and term discounts, and any credit you are owed when you update an app.
Under the hood, five things happen, in order.
The spec is checked through api.runonflux.io the same way it will be at registration. If the load balancer refuses, the server tries a few healthy nodes. The network quotes a dollar price and the server checks the payer’s balance. On confirm, the Flux ID signs the spec and the same endpoint broadcasts it, returning a 64-character message hash. The payment address then sends the quoted FLUX to the network’s deployment address, with that hash in an OP_RETURN output. Just before signing, the amount is checked again against a fresh price table. Nodes pair the confirmed payment with the message, publish the app, and the instances pull the image.
Updates use the same deploy tool. If the name already belongs to you, the server sends an update message and the network credits the unused part of the old term.
How you set it up
Install the package, or skip the install and run it with npx:
npm install -g @runonflux/flux-cloud-mcp
npx @runonflux/flux-cloud-mcpIn Claude Code, add it as a user-level server:
claude mcp add flux-cloud -s user \
-e FLUX_ID_PRIVATE_KEY=<wif> -e FLUX_PAYMENT_PRIVATE_KEY=<wif> \
-- npx -y @runonflux/flux-cloud-mcpClaude Desktop, Cursor, and Windsurf use the same shape in their MCP config: command npx, args ["-y", "@runonflux/flux-cloud-mcp"], and those two keys in env. OpenCode wants a type: "local" entry with a command array and an environment object instead.
The keys are optional. Without them, every read-only tool still works. flux_generate_keys creates a fresh pair and tells you how to put it in the config. You then fund the payment address (t1…) with FLUX. The Flux ID (1…) owns apps and signs specs. It is not supposed to hold funds.
If your host cannot start a local process (claude.ai connectors, ChatGPT, a browser agent), add the hosted server instead: https://mcp.runonflux.com/mcp. There is a twin at https://mcp.runonflux.io/mcp. That copy holds no keys. Signing and paying tools take the two private keys as arguments for that one call. The project says they are used in memory and not logged. Anything you type into a chat still passes through the model vendor and the host’s history, so treat a hosted pair as disposable and keep the balance small. For real money, run the server on your own machine, where the keys stay in the process.
You can run your own copy in Docker with docker run -p 3000:3000 ghcr.io/runonflux/flux-cloud-mcp:0.2.7. The Docker Hub name in the README, runonflux/flux-cloud-mcp, is not published. It is stateless, so several instances can sit behind one load balancer. GET /healthz is the liveness check. The spec that runs the public instance lives in the repo at deploy/cloudmcp.json.
To build it from source, the project uses Yarn: yarn install, then type-check, lint, format check, build, and test. yarn test:live compares the dollar estimator with the live network. The estimator, the spec formatter, and the payment guard are written to mirror FluxOS itself (appSpecHelpers.js, appUtilities.js, messageVerifier.js). The licence is MIT.
What it will not do for you
An underpayment is gone. The chain’s own acceptance threshold is lower than the price this server quotes, and the server never shows that lower number as a price. It only checks it as a guard. If a payment still comes in short, the network drops the message quietly and does not refund the FLUX. That is why the amount is re-checked against a fresh price table immediately before the payment is signed.
Removing an instance is not cancelling the app. flux_control_app can restart containers, pull the image again and recreate them (hard=true also wipes data), or uninstall from nodes. The registration stays, and the network starts the app again somewhere else. To stop paying, you cancel, which shortens the term so the app expires within about an hour.
Private apps stay partly private. Enterprise apps publish an empty component list. Logs, stats, and the app lookup then fetch a decrypted spec from an ArcaneOS node using the owner key. The server returns component names, images, ports, and sizes. Environment variables, commands, and registry credentials are not supposed to leave it.
The hosted server is the wrong place for a fat wallet. Keys passed in a chat are visible to the model vendor. The project’s own instruction to agents is to generate a dedicated pair and fund only what the deployment needs, not to ask for a wallet you use for anything else.
The bottom line
Flux Cloud MCP is a thin, careful remote control for a cloud that already existed. You describe an image, a size, and a term. The agent builds a spec the network will accept, shows you a dollar price, and spends nothing until you say confirm. Then it waits and gives you a URL.
That is enough to stand up a small public app from a chat. It is not a custody product. Use a payment address that holds only what you mean to spend, run the server locally if the amount matters, and treat a quote as stale the moment the FLUX price moves.
Sources
- RunOnFlux, Flux Cloud MCP server, npm package
@runonflux/flux-cloud-mcpv0.2.7, last published 13 September 2026. npmjs.com/package/@runonflux/flux-cloud-mcp. Repository: github.com/RunOnFlux/flux-cloud-mcp - Hosted endpoint: mcp.runonflux.com/mcp
- Flux Cloud: runonflux.com
- Model Context Protocol: modelcontextprotocol.io
