nanoodle-mcp

Build a multi-model media pipeline visually at nanoodle.com — then hand the whole pipeline to your agent as ONE typed tool.

Skill or MCP? Running (or designing) a single workflow? The nanoodle skill is one command and no setup. This server is for when you've built up a folder of saved graphs and want each one exposed to your agent as its own tool.

Point this MCP server at a folder of noodle-graph.json saves from the nanoodle editor and every graph becomes a callable tool with a derived input schema — in Claude Code, Grok, Claude Desktop, Cursor, VS Code, Windsurf, or anything else that speaks the Model Context Protocol. It speaks stdio to your own agent by default, or HTTP to everyone with serve mode — including charging per call in Nano, so strangers' agents can pay to run your noodles with no account anywhere.

No middleman server, no telemetry — and with wallet mode, no account either. The MCP implementation here is hand-rolled (stdio + streamable HTTP, JSON-RPC 2.0 — small enough to read). Two runtime dependencies: nanoodle (MIT), the zero-dep workflow executor that does all the heavy lifting, and nanocurrency (GPL-3.0) for signing Nano blocks — loaded only on the x402 paths, see Licensing. Your NanoGPT API key goes straight from your machine to nano-gpt.com; it is never logged and never appears on stdout.

Example: a description becomes a playable fighter

Play Iron Verdict: a furnace knight with heavy jumps, punches, ground slams and punishing arena combat. A coding agent built the game using the character-sprites skill.

The character-sprites graph turns a humanoid description into a character reference and a matching parts sheet. The skill's local rig script turns those parts into transparent idle, walk, punch and jump frames with an atlas and timing metadata. The coding agent then implements physics, combat and game rules. The finished game demonstrates that combination; one MCP call returns the reference and parts images, not the complete game.

Mount the character-sprites graph in your server's graph folder to expose it as a tool. Use tools/list to check whether a given server has it mounted and read its input schema before calling. For the published graph, the generation step is:

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"character-sprites","arguments":{"Character":"A compact furnace knight with an ivory helmet, amber visor, navy armor and brass gauntlets. Outlined 2D platformer art. No weapon or wings."}}}

Install the skill for local extraction and animation (Node 20+ and ffmpeg/ffprobe required). A useful agent request is: “Use character-sprites to make an animated fighter from my description, inspect the joints and alpha edges, then build a small playable arena with heavy gravity and impactful combat.”

Install

You need: Node 20+, a folder of saved graphs (say ~/noodles — see Making graphs), and a nano-gpt.com API key in NANOGPT_API_KEY (or passed via --key / --env-file) — or no key at all with a Nano wallet, see wallet mode.

Optional: ffmpeg on PATH. Tools whose graphs include a local-media node (resize, video frames, combine, audio trim/extract) use a pure-JS path for the common case but fall back to ffmpeg/ffprobe for formats it can't handle — JPEG/WebP resize, reading video frames, compressed audio. Without ffmpeg those runs fail (and auto-refund in charge mode); the server prints a warning at startup naming the affected tools. Pure image/LLM/vision tools don't need it. Install with apt install ffmpeg (Debian/Ubuntu) / brew install ffmpeg.

Claude Code

claude mcp add nanoodle --env NANOGPT_API_KEY=your-key-here -- npx -y nanoodle-mcp --graphs ~/noodles

Or install it as a plugin — Claude Code prompts for your noodles folder and API key, and also learns what a noodle is (this repo doubles as a plugin marketplace):

/plugin marketplace add nanoodlecom/nanoodle-mcp
/plugin install nanoodle@nanoodle

Grok

grok mcp add nanoodle -e NANOGPT_API_KEY=your-key-here -- npx -y nanoodle-mcp --graphs ~/noodles

Or, for a remote/serve endpoint (no local process, no API key on your machine):

grok mcp add --transport http noodles https://mcp.nanoodle.com/mcp

That writes [mcp_servers.noodles] into ~/.grok/config.toml (or .grok/config.toml with --scope project). Same shape by hand:

[mcp_servers.noodles]
url = "https://mcp.nanoodle.com/mcp"
enabled = true

Cursor

Install in Cursor (then edit the graphs path and key), or add to .cursor/mcp.json yourself:

{
  "mcpServers": {
    "nanoodle": {
      "command": "npx",
      "args": ["-y", "nanoodle-mcp", "--graphs", "/absolute/path/to/noodles"],
      "env": { "NANOGPT_API_KEY": "your-key-here" }
    }
  }
}

VS Code

.vscode/mcp.json — note VS Code's root key is servers, not mcpServers:

{
  "servers": {
    "nanoodle": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "nanoodle-mcp", "--graphs", "/absolute/path/to/noodles"],
      "env": { "NANOGPT_API_KEY": "your-key-here" }
    }
  }
}

Windsurf

~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "nanoodle": {
      "command": "npx",
      "args": ["-y", "nanoodle-mcp", "--graphs", "/absolute/path/to/noodles"],
      "env": { "NANOGPT_API_KEY": "your-key-here" }
    }
  }
}

Claude Desktop

Same shape as Cursor/Windsurf, in claude_desktop_config.json under mcpServers.

ChatGPT

ChatGPT only connects to remote HTTPS MCP servers. The hosted endpoint is already live — add https://mcp.nanoodle.com/mcp (paid per call in Nano, no API key). Local stdio (npx nanoodle-mcp --graphs …) stays BYOK and is not reachable from ChatGPT.

⚠️ This spends real money

The server runs on your money — either a nano-gpt.com API key (BYOK) or, keyless, your own Nano wallet via x402. Every tools/call executes a workflow against the NanoGPT API and spends from that balance — and the caller is usually an AI agent deciding on its own when to call. Point it only at graphs you're happy to have run, and keep an eye on your balance. Each result ends with a cost: $X.XXXX line so the agent (and you) can see what a call cost.

Wallet mode — no account, no API key (x402)

NanoGPT supports x402 accountless payments: a keyless API call answers HTTP 402 with a Nano invoice, you pay it, the call completes. Give the server a wallet and it does this automatically — no NanoGPT account, no API key, no signup anywhere:

export NANO_SEED=<64-hex seed>        # account 0 pays; or NANO_PRIVATE_KEY=<64-hex key>
nanoodle-mcp --graphs ~/noodles --max-usd 0.50

Per call, the server: sees the 402 invoice → signs a Nano send block locally → broadcasts it through a Nano RPC node (--nano-rpc / NANO_RPC_URL, default rpc.nano.to) → NanoGPT detects the deposit and returns the result. The seed/private key never leaves the process: only the signed block goes to the RPC node, and neither secret is ever logged. An API key, if present, always wins — the wallet is only used keyless.

Proof-of-work reliability. Every send block needs Nano proof-of-work. The server asks the RPC node's work_generate first, but public nodes routinely refuse or throttle it (no GPU, key required); the fallback is local single-threaded CPU work, which can take a minute. Two fast options, both via --work-rpc / NANO_WORK_URL:

• Hosted GPU work API — sub-second work, no hardware. E.g. nano.to's PoW API (--work-rpc https://rpc.nano.to) or Nanswap Nodes (--work-rpc https://nodes.nanswap.com/XNO — the fast work server is on their paid plan; the free one queues for minutes). Put the API key in NANO_WORK_KEY (env or --env-file, never a flag) — it's sent as both a key body field (nano.to style) and a nodes-api-key header (Nanswap style).
• Your own nano-work-server on the same machine (nano-work-server --cpu-threads 8 -l 127.0.0.1:7076 → work in a few seconds, free forever).

Order: --work-rpc (2-minute timeout, so a hung server can't stall a payment) → --nano-rpc node → local CPU. The wallet also precomputes work for the next block the moment one publishes, and serve mode prewarms at boot — with any healthy work source, callers effectively never wait on proof-of-work.

The local-CPU last resort runs on the Node main thread: in --serve mode a send-difficulty grind (minutes) freezes the whole HTTP server while it runs. If your remote work sources are dependable, pass --no-local-work — the send then fails cleanly instead (an unpayable invoice is refused up front, and a failed refund/payout send leaves the balance in the wallet for the next settle to move).

This is a hot wallet. Use a dedicated wallet holding pocket money, not your savings: its balance is a natural spend ceiling, and --max-usd adds a per-call one on top. NanoGPT auto-refunds overpayments and failed generations on its side.

Prefer prepay? Wallet mode settles on-chain per call. If you'd rather pay once and draw down a balance, that's exactly what a NanoGPT account is: deposit crypto (Nano included) into an account, take its API key, and run the server in normal BYOK mode — same tools, one payment instead of many.

Serve mode — host your noodles as a service (--serve)

Everything above speaks MCP over stdio to your own agent. --serve speaks MCP over streamable HTTP instead, turning a directory of noodles into a service anyone's agent can connect to:

nanoodle-mcp --graphs ~/noodles --serve 8402

Callers connect with one command — no key, no signup:

claude mcp add --transport http noodles https://your-host/mcp
# or
grok mcp add --transport http noodles https://your-host/mcp

GET / serves a landing page with the tool list and that exact command (Claude and Grok behind a one-click toggle — same endpoint, same flags), so sharing your server's bare URL is the onboarding. Every workflow on it links to its source: an open in editor link (a share link minted from the exact graph file being served — it loads the workflow in the nanoodle editor to inspect, remix, or run on your own key) and its raw graph JSON at /graph/<tool>.json. The page also spells out the economics (deposits settle at metered cost + 20%; the markup is the author's cut on graphs that name a payout address, and the operator's on the rest, and the page says which of yours do) and how to self-host — this server, the editor, and the executor are MIT (licensing). Generated media is served back under unguessable /out/… URLs (small images also ride inline in the tool result). Runs themselves are not logged: free serve mode keeps no record of who called what, and charge mode keeps only a payments ledger (money events, never run telemetry — see below).

Generated media is deleted after --out-ttl hours — a privacy backstop so a hosted server doesn't hoard every caller's generations on disk forever. In --serve mode it defaults to 24h; pass --out-ttl <hours> to change it (fractions like 0.5 are fine) or --out-ttl 0 to keep everything. Stdio mode defaults to off — files you generated locally are yours to keep — but honors the flag if you pass it. The sweep only ever removes media artifacts (images, video, audio); the operator's own costs.json, gate-state.json, and usage.jsonl are never touched. Note the 24h default matches the charge gate's replay window: a paid result stays replayable for 24h and references its /out/ URL, so lowering --out-ttl below 24h in charge mode means a replayed result can point at a file that's already been swept.

Privacy — what your server keeps

Run with the defaults and the same promise the hosted server makes holds on your box, every line checkable in this repo:

• No accounts, no API keys, no sign-ins. In charge mode, paying is the only thing that authorizes a call.
• Prompts and inputs are never written to disk or logs. Input media rides in memory only — it is never stored. In charge mode the gate keeps only a short hash binding a payment to its call (hashArgs), never the arguments.
• Generated media auto-deletes after --out-ttl hours (default 24h in --serve, off for local stdio), served at unguessable /out/… URLs until then. Set --out-ttl 0 to keep everything.
• Results are held in memory for delivery, not stored — the restart-state file carries no result text or error detail.
• No analytics, no trackers, no IP logs — the app keeps no request logs. In charge mode the one thing it writes is usage.jsonl, a payments ledger of money-lifecycle events that mirror the public Nano ledger — no run telemetry, no error text. Free serve mode writes no ledger at all.

gate-state.json itself never holds customer content. It exists to keep in-flight money safe across the restart a deploy causes — quotes and owed sends survive — but a paid tool's text output and any upstream error detail are never written to disk. Media results persist only their /out/ pointer and a receipt; a text result persists as nothing, so a restart between a run and the caller's retry simply re-runs the tool (charged once, delivered once — the operator eats one duplicate model call) rather than replaying content from disk, and a failed run replays a fixed placeholder plus its refund status, never the original error message.

One caveat, stated plainly: generation runs on NanoGPT's API, so prompt content in flight is governed by their privacy policy.

Free serve mode runs on your balance — fine on a trusted network, ruinous on the open internet. For that, charge for calls:

Charging per call (--charge-usd)

nanoodle-mcp --graphs ~/noodles --env-file wallet.env \
  --serve 0.0.0.0:8402 --public-url https://noodles.example.com --charge-usd 0.05

Now every tool call is paid in Nano (XNO) by the caller, with no accounts on either side. The flow their agent walks through (the server's MCP instructions teach it automatically):

On each PAYMENT REQUIRED quote the tools/call hangs up with payUrl, watchUrl, and a next imperative ( blocking: false ):

1. Pay. Show the user ONLY payUrl (QR for the exact amount); any Nano wallet scans it. Never show them watchUrl or the wallet address.
2. Watch — immediately, on that same payment link. The agent opens watchUrl (GET /x402/watch/<id>, agent-only SSE) the moment it has the quote. One status event per state change; when payment lands the stream closes with done: true and a next field for phase 3. (The pay page uses the same stream; poll GET /x402/status/<id>?wait=1 as a fallback.) Detection is RPC polling or push via --nano-ws — about a second.
3. Results. ONLY after the watch closes paid: re-call the tool with the same arguments plus _payment_id. That tools/call is the results stream — it runs the workflow (progress heartbeats on a streaming transport) and returns the result with a receipt. Do not open it while still watching for payment. Re-calls with the same _payment_id replay the cached result free.

What they paid is a deposit, not the price: the call settles at the run's actual metered model cost + 20%, and everything above that is sent back to the paying wallet as change — the same deposit→meter→refund model NanoGPT itself uses, one layer up. Nobody ever pays off an estimate.

Nano has no payment memo, so each quote's amount carries a few raw of random dust — the amount is the memo. Quotes expire after 15 minutes; a payment that arrives late is bounced straight back, and a run that fails after payment is refunded automatically. Arguments are validated before a quote is issued (nobody pays for a typo), and run_noodle is withdrawn in charge mode — an arbitrary share link's cost can't be priced up front.

Pricing: --charge-usd sets the ceiling deposit, and the opening quote for a tool that has never run. Once a tool has run, its deposit tracks its real cost automatically: quotes become twice the settle price (worst observed metered cost + 20%, from the costs.json sidecar), ceiled to a whole cent with a 1¢ floor — a tool that meters $0.004 quotes a $0.01 deposit, not the flat ceiling. Size the ceiling generously; over-covering costs callers nothing since the difference comes back as change, while an under-sized deposit means runs can cost more than was collected and you eat the difference (the gate warns at startup when a graph's deposit is below its last observed cost + 20%). The XNO conversion comes from NanoGPT itself: the gate fires a keyless x-x402 probe and keeps the invoice's exact raw-XNO/USD pair — the same rate your downstream payments settle at, so quotes and costs can never drift apart on FX, and no market-data service is involved (probe invoices are never paid; they just expire). Cached 60s, stale cache rides out probe outages, and --xno-usd forces a static rate if you ever need one. Per-graph overrides are a hand-added top-level block in the graph JSON:

"x402": { "usd": 0.10, "author": "nano_1abc…" }

usd overrides the deposit. author routes the 20% markup of every successful call to that address — computed on what the run actually cost, never on the deposit, and capped by whatever the deposit has left once the cost is taken out (a deposit too small to cover cost + 20% pays the author only the remainder). Nano has no network fees and this server takes no cut of the markup, so creators keep 100% of what does get routed. With no author field the markup stays with the wallet running the server — it is opt-in per graph, not the default. In exact raw, per settled call:

cost   = metered model cost, converted at the deposit's own oracle pair, rounded up
markup = cost / 5                    (20%, integer floor)
take   = min(markup, deposit − cost) → author (or kept, if no author field)
change = deposit − cost − take       → back to the payer

A run costing more than its deposit keeps the whole deposit and the operator absorbs the excess; a run whose model reports no cost settles at $0 and the whole deposit is returned (the caller is never billed off a number the meter didn't produce). The math is integer-exact end to end: USD decimals parse by string into nano-dollars, the rate is the oracle invoice's literal raw/USD pair, every conversion is BigInt ratio arithmetic with an explicit floor or ceil, and floats never touch an on-chain value.

The wallet (NANO_SEED / NANO_PRIVATE_KEY, via --env-file) receives payments, sends refunds and author payouts, and — if you don't set an API key — also pays NanoGPT per call via x402, making the whole service nano-in/nano-out. With an API key, runs spend from the key and the wallet only handles the customer side.

Payment detection

Polling receivable on your Nano RPC node (1s while quotes are pending) is the always-on default. Add --nano-ws wss://… to subscribe to a Nano node websocket for push detection — settlement is then effectively instant and polling relaxes to a safety net. Public websockets exist (e.g. wss://nanoslo.0x.no/websocket worked at the time of writing); your own node is the dependable option. Either way the poller also checks account_history, so payments pocketed by a concurrently-running wallet are still found.

Payments ledger

In charge mode <out>/usage.jsonl is a payments ledger: one line per money event only — quote, paid, refund, change, author_payout — your server's own record of money moving, nothing client-side. It is deliberately not a usage log: there are no run events, no run timing, no success/failure telemetry, and no upstream error strings (which can quote user content). A money event does carry .tool — the tool name is the subject of the payment, not a record of a run — so you can see what earns, but not who ran what when or whether it failed. Refunds record a fixed category (run_failed, late_payment), never the underlying error text — the full error still reaches the caller and the operator's stderr. Free serve mode writes no ledger at all. Some starters:

jq -r 'select(.event=="paid") | .tool' usage.jsonl | sort | uniq -c | sort -rn  # paid calls per tool
jq 'select(.event=="paid") | .settleMs' usage.jsonl                             # quote→settle latency
jq 'select(.event=="paid") | .usd' usage.jsonl | jq -s add                      # gross deposits taken
jq -r 'select(.event=="refund") | .reason' usage.jsonl | sort | uniq -c         # refunds by category

Hosting checklist

• Reverse proxy / tunnel: bind localhost, put Caddy/nginx/cloudflared in front for HTTPS, and set --public-url to the outside URL (it's what pay links and media links are built from).

• systemd (adjust paths):

  [Unit]
  Description=nanoodle-mcp serve
  After=network-online.target
  
  [Service]
  ExecStart=/usr/bin/npx nanoodle-mcp --graphs /srv/noodles --out /srv/noodle-out \
    --env-file /srv/wallet.env --serve 8402 --public-url https://noodles.example.com \
    --charge-usd 0.05 --work-rpc http://127.0.0.1:7076
  Restart=on-failure
  
  [Install]
  WantedBy=multi-user.target
  

• Keep the float small: the wallet is hot. Sweep revenue to cold storage regularly; if you run with an API key, cap that account's balance too.

• Work server: refunds and payouts are Nano sends and need proof-of-work — use a hosted GPU work API (nano.to, Nanswap — key in NANO_WORK_KEY in the env file), or point NANO_WORK_URL at a nano-work-server --gpu on any box you own over a tailnet (work requests carry only block hashes — nothing secret). Pair either with --no-local-work so a work outage can't freeze the server on CPU work. Wallet-material and key env vars all belong in the --env-file, which also takes NANO_WS_URL for a key-bearing websocket URL (e.g. Nanswap's wss://nodes.nanswap.com/ws/?ticker=XNO&api_key=…).

• There is intentionally no auth: on a charged server, payment is the authorization. Don't serve graphs you wouldn't want strangers running.

How it works

~/noodles/
  generate-hero-image.json   →  tool "generate-hero-image"
  make-jingle.json           →  tool "make-jingle"

Every readable *.json graph in --graphs becomes one MCP tool: