CloudGPU MCP

CloudGPU MCP

CloudGPU MCP server: let an AI agent rent a GPU by the minute, run a job, bring the results back and shut the GPU down. The same API key and balance also cover CloudGPU's OpenAI-compatible model API, so an agent can call a hosted model without renting anything.

"Fine-tune a 7B base model with LoRA on data/train.jsonl and put the adapter in ./outputs."

The agent checks live prices and quotes you, rents the GPU once you say yes, uploads your code and data, starts training in the background, watches the logs, downloads the adapter and destroys the instance. You get the files and the final cost.

It is a local (stdio) MCP server. It works with any MCP client that can start one: Claude Code, Cursor, Cline, opencode, goose, VS Code, Windsurf and others.

Install

For the browser-approval flow, add this local MCP server without an API key first:

claude mcp add cloudgpu -- npx -y cloudgpu-mcp

For another stdio client, use command: "npx" and args: ["-y", "cloudgpu-mcp"]; omit the environment key. Ask the Agent to call connect_account, open its returned CloudGPU link yourself, approve the account, spending limit, GPU concurrency and expiry, then let it call finish_connect. Never paste your password or API key into the conversation. The client must support and configure MCP; the approval link alone does not install tools in an arbitrary assistant. Existing API-key setup remains available below.

1. Create an API key at cloudgpu.app/api and add a prepaid balance (card or USDT).
2. Add the server to your client. Node.js 18 or newer is required. The key goes in the environment variable CLOUDGPU_API_KEY.

claude mcp add cloudgpu --env CLOUDGPU_API_KEY='<YOUR_API_KEY>' -- npx -y cloudgpu-mcp

{
  "mcpServers": {
    "cloudgpu": {
      "command": "npx",
      "args": ["-y", "cloudgpu-mcp"],
      "env": { "CLOUDGPU_API_KEY": "<YOUR_API_KEY>" }
    }
  }
}

{
  "mcpServers": {
    "cloudgpu": {
      "command": "npx",
      "args": ["-y", "cloudgpu-mcp"],
      "env": { "CLOUDGPU_API_KEY": "<YOUR_API_KEY>" }
    }
  }
}

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "cloudgpu": {
      "type": "local",
      "command": ["npx", "-y", "cloudgpu-mcp"],
      "environment": { "CLOUDGPU_API_KEY": "<YOUR_API_KEY>" },
      "enabled": true
    }
  }
}

extensions:
  cloudgpu:
    name: cloudgpu
    type: stdio
    cmd: npx
    args: ["-y", "cloudgpu-mcp"]
    envs:
      CLOUDGPU_API_KEY: "<YOUR_API_KEY>"
    enabled: true
    timeout: 300

3. Optional but recommended: copy rules/cloudgpu.md into your project as AGENTS.md, .cursor/rules/cloudgpu.md or .clinerules/cloudgpu.md. It tells the agent to quote before renting, download before shutting down, and never leave a GPU running. The server also exposes the same text as the resource cloudgpu://rules.

To check the install, ask your agent: "List the GPUs available, then estimate the cost for a 24 GB GPU for one hour. Do not create anything." You should see list_gpus and estimate_cost calls and a quote, and nothing is rented.

Agent Skill

The same guidance is available as two Agent Skills:

• skills/cloudgpu/SKILL.md: renting and using a GPU. Claude Code loads it on demand when you ask for a GPU job. It expects the cloudgpu MCP tools to be installed (see above).

• skills/cloudgpu-model-api/SKILL.md: calling the OpenAI-compatible model API at https://cloudgpu.app/v1 without renting a GPU. It works with the MCP tools or with just a CLOUDGPU_API_KEY.

• Claude plugin: both skills are included automatically when you install the CloudGPU Claude plugin from this repo's marketplace:

  /plugin marketplace add cloudgpu-app/cloudgpu-mcp
  /plugin install cloudgpu@cloudgpu
  

• Codex plugin: the same repository is an Agent Plugins package (plugin.json, mcp.json, and skills/). Codex shows it as CloudGPU. The server reads CLOUDGPU_API_KEY from the environment.

  codex plugin marketplace add cloudgpu-app/cloudgpu-mcp
  

• Claude Code, personal install: copy skills/cloudgpu/ and skills/cloudgpu-model-api/ to ~/.claude/skills/.

• Claude Code, project install: copy skills/cloudgpu/ and skills/cloudgpu-model-api/ to .claude/skills/ in your project.

• Cursor, Codex, Cline, Amp and other agents that read Agent Skills: install both skills with the skills CLI:

  npx skills add cloudgpu-app/cloudgpu-mcp
  

Tools

The server also provides a train_on_cloudgpu prompt.

Guardrails

• A quote first. create_instance only takes a quote_id from estimate_cost and user_confirmed=true.
• Server-side limits. Every instance is created with max_spend_usd, max_hours and an idle limit (60 minutes by default). CloudGPU's servers check them and destroy the instance when one is hit, even if your client has disconnected or your laptop is asleep.
• Your own ceiling. CLOUDGPU_MAX_SPEND_USD and CLOUDGPU_MAX_HOURS cap what the agent may set.
• Results before shutdown. After commands have run, stop_instance refuses until something has been downloaded, unless the user confirms force=true.
• Secrets stay out of the chat. The instance's SSH login is used inside this process and never returned to the model. Tool output is scrubbed of the API key and login details. Uploading .ssh, .env, key files or your whole home directory needs allow_sensitive=true.
• The instance stays manageable. Commands that change the root password, SSH configuration, firewall or the platform's monitoring agent are refused. CloudGPU shuts down instances that it can no longer monitor.
• Jobs are not started twice. run_job sends an Idempotency-Key. Resending the same job returns the same job instead of starting a second GPU, and the server refuses the same key with different parameters.
• Keys with a budget. A key from connect_account has a total spending limit, a number of GPUs it may run at once and an expiry date, all enforced by CloudGPU's servers. Revoke it at https://cloudgpu.app/api and it can no longer start anything.
• Read-only mode. CLOUDGPU_READ_ONLY=1 registers only the look-up tools.

Configuration

Model API on the same balance

The key also works with the OpenAI-compatible API at https://cloudgpu.app/v1. Call list_models (or GET /v1/models) to see the available model IDs. Model prices are on cloudgpu.app/api.

Optional persistent files and Workspaces

These tools require persistent storage to be explicitly enabled on the server;they return storage_not_enabled until it is ready. Discover server capabilitiesat /v1/public/compute-capabilities. Read get_storage for current included allowance, quota, prices and retention. Storage fees are separate from GPU Job budgets. Uploads above the included allowance require accept_storage_charges=true after user agreement; the default is false. Budget-limited connect-link keys cannot enable paid storage. Files expose expires_at; downloading does not renew retention. Versions containing expired files become unavailable, while active Jobs defer deletion.

• get_compute_catalog and quote_compute use public discovery and server quotes,including required starting balance and supports_jobs. Pass the server quote torun_job as quote_id; the original estimate_cost remains a local quote forinteractive instance rentals.
• get_storage, list_files, list_workspaces, list_workspace_versions andget_workspace_version show saved files, versions and usage.
• upload_artifact and download_artifact transfer persistent files, includingdatasets/models, without returning storage credentials to the assistant.
• save_workspace saves regular project files as an immutable version. It refusesknown credential paths and symlinks, and skips .git, node_modules,__pycache__ and .venv. Save dependency manifests so the next GPU can rebuildits environment. The returned workspace_version_id can be passed to run_job.
• delete_file and delete_workspace_version require explicit user confirmationand refuse active references.

This restores project files into a fresh directory before the Job command. It isnot full-disk restore and does not automatically save edits or collect outputs.Continue saving results from the command itself. Large-model restore speed andcross-supplier cache behavior must be measured before relying on them. Backend restore plans travel via SSH stdin, never inJob command arguments or saved scripts; the user command starts after restoration.This does not protect transfer-time memory from root on the GPU. Failed deletionsor expired uploads may remain pending while the server verifies cleanup; quota isreleased only after confirmed removal. With storage disabled, normal catalog,account, instance and Job tools keep working without a storage provider.

The developer acceptance script node scripts/acceptance.mjs is read-only bydefault. Its --paid mode is for an explicitly authorized internal test accountonly; it can create two Jobs capped at $0.03 each. Do not run paid mode as part ofordinary package tests.

Without MCP

The server wraps CloudGPU's public REST API, which any agent or script can call with the same key:

curl https://cloudgpu.app/v1/gpu/offers -H "Authorization: Bearer $CLOUDGPU_API_KEY"

Command-line tool

The package also installs a cloudgpu command for using the same API from a terminal (Node.js 18.3 or newer, no extra dependencies):

npm install -g cloudgpu-mcp      # or run it once with: npx -p cloudgpu-mcp cloudgpu --help
cloudgpu login                   # saves your key to ~/.config/cloudgpu/config.json (mode 0600)
cloudgpu offers                  # GPU models with live price and availability
cloudgpu up --gpu "RTX 4090" --template comfyui --max-minutes 120 --max-spend 5 --wait
cloudgpu ssh <id>                # opens your system ssh to the instance
cloudgpu down <id>               # destroys it and stops billing (asks first; --yes to skip)

CLOUDGPU_API_KEY takes precedence over the saved key, and CLOUDGPU_BASE_URL overrides the API host. Read commands accept --json; SSH passwords are left out of JSON unless you pass --show-password. Every command has --help. Errors print the API's message and exit non-zero (2 for usage errors).

Links

• MCP docs: https://cloudgpu.app/docs/mcp
• GPU pricing: https://cloudgpu.app/pricing
• Model API and prices: https://cloudgpu.app/api
• API reference: https://cloudgpu.app/api/docs · OpenAPI: https://cloudgpu.app/openapi.json · For LLMs: https://cloudgpu.app/llms.txt

CloudGPU here means cloudgpu.app. Prepaid balance, billed per minute; when the balance runs out, running instances are destroyed and their disks erased, so keep enough balance for the job and download results as you go.

Development

npm install
npm test
node src/index.js   # stdio server; set CLOUDGPU_API_KEY first
node src/cli.js --help

License

MIT, see LICENSE.

Apply a Workspace to a GPU you already rent

Use list_workspace_instances, then get_workspace_application with the saved version_id and the selected instance_id. After the user agrees, call apply_workspace with user_confirmed: true, then poll status. The files appear in a new private project directory; existing files are never overwritten. This does not install dependencies, execute project code or start, stop, or restart a GPU. Rental billing continues during transfer. Budgeted Agent keys can only target instances created with the same key. Workspace requires a funded account.

Repeated application of the same version to the same instance returns the existing result, including user edits after success. On needs_attention, failed or conflict, inspect the result rather than automatically retrying. A new saved version creates a separate directory. The feature must be enabled by the server; unavailable storage does not disable ordinary GPU rental or Job tools.

D13 model preparation (0.8.0)

Version 0.8.0 adds three preparation tools; check both the installed tools and live backend capabilities before using them:

• resolve_model_reference: resolve a public Hugging Face branch/tag and explicit filenames to a commit-addressed manifest, sizes and available LFS SHA-256. No weights are hosted by CloudGPU. To enable verified use of the instance’s existing mirror, up to 8 selected JSON configuration files of at most 64 KiB each may be read from the pinned origin and SHA-256 hashed, within a shared 15-second deadline. Weight files are not fetched by this resolver. Private/gated models are refused.
• prepare_job_rerun: read parameters from a successful owned Job. No new GPU, old quote or old idempotency key. Obtain a fresh quote and explicit budget approval before run_job.
• prepare_model_deployment: prepare a setup script for the existing ComfyUI template, with direct model downloads and optional UI-format workflow JSON. Use the model name as a category (e.g. checkpoints, loras, vae). Review and approve the script before deploying. Custom nodes are not installed and workflows are not executed automatically. This is preparation support, not a real-GPU-validated template catalog.

run_job accepts optional model_references. A supporting backend is checked before submission; an old backend cannot silently ignore the references. Models are downloaded after Workspace restoration, into $CLOUDGPU_MODEL_DIR/<name>/<path>. Download time consumes the same rental budget. File size/checksum, disk and download timeout failures stop the Job and follow the existing release-evidence flow, without provisioning retries. The weights disappear with the GPU unless the user separately persists them; no R2 model cache is added.

Agent-first interaction: ask your Agent to run the project again; no separate web Job console or model JSON form is required. Team-authorized keys spend the selected team wallet; personal funds are separate.

Suggested workflow: resolve references → review model license/files and compatible environment → get quote → obtain explicit budget/time/GPU approval → run once with a stable idempotency key → poll status/cost → prepare a rerun only after success. Output collection remains the user's command's responsibility.

See examples/pinned-model-job.mjs for a default dry-run REST example. Do not enable submission during routine tests. Bounded internal acceptance covered actual MCP, candidate HTTP authentication/MySQL, independent model hashes, two GPU runs and release. A separate ComfyUI image accepted model links and a workflow file. This does not validate arbitrary custom nodes or graph execution.

Small Job output snapshots and diagnosis (0.7.0)

This branch adds diagnose_job (read-only) and save_job_output (explicit storage write). Check the installed tool list before using them; they are not a claim about the currently published npm release.

save_job_output stores only the ended Job output tail as a small Artifact. It is not a full log, file collector, disk snapshot or automatic backup. Known credential patterns and queried URLs are refused. Review output for other sensitive data before approving storage. Existing eligibility, quota, retention and explicit paid-storage consent apply; the GPU Job budget does not authorize paid storage. No GPU is created, kept alive or stopped by these tools. Matching snapshots are verified and reused when found; concurrent different client processes may still create duplicate artifacts.

diagnose_job reports the error category, platform instance status and whether platform charges are final. It does not prove supplier release, infer that command failures are always user errors, or automatically rerun work. needs_attention requires resource reconciliation before a new task. A rerun requires a fresh quote, explicit approval and a new idempotency key.

Registry configuration allows discovery and connect-link approval without pre-entering a key. A tool-enabled MCP client is still required; a link does not install a client or grant unlimited spending. No new fixed infrastructure or model storage is introduced.

Optional Job output collection (requires backend capability)

Call run_job with outputs: {"files":["metrics.json"],"max_bytes":1048576} and a command that writes to "$CLOUDGPU_OUTPUT_DIR/metrics.json". Files are relative to this dedicated directory; the platform does not scan the disk. The server refuses unsupported backends rather than silently starting a Job without saving results. GPU download/execution/upload time shares the same time and spend limits.

After completion, inspect get_job.output_collection: only succeeded confirms collection. Each saved entry gives file_id, sha256, size_bytes and status; use existing file download tools. Partial failure may retain ready files, but is not overall success. Cancellation, budget exhaustion, instance loss or interrupted collection can prevent saving; GPU release still proceeds with no automatic re-run. Files follow the existing account quota, storage pricing and 30-day retention. accept_storage_charges defaults false and requires explicit user agreement to paid storage. The 10 MiB default/100 MiB maximum is a transfer bound, not a new user quota. File-name protections cannot guarantee that user-selected file contents contain no secrets.

Job log snapshot safety

Version 0.8.0 still has a credential-filter gap in save_job_output; upgrading to 0.8.0 did not fix it. The 0.9.0 candidate rejects quoted JSON credential keys, common prefixed/aliased secret fields, authorization schemes, queried/user-info URLs and bounded common escaped representations before any storage operation. Safe logs remain byte-identical. This is a conservative recognizable-pattern check, not a guarantee that arbitrary, encrypted or unknown credentials will be detected. Save only logs you know are sanitized, with explicit user approval; no actual exposure is established by this fix.

Reusable task drafts (D16)

list_task_templates and prepare_task_template are local, read-only tools: no account is required, no API call is made, and preparing a draft never rents a GPU. Start with gpu-check, csv-summary, or workspace-python. CSV work normally belongs on your local CPU; do not rent a GPU merely to process a small CSV.

{"template_id":"gpu-check","persist_results":false}

For an existing project, pass workspace-python, an immutable workspace_version_id, and a reviewed relative .py entrypoint. The script runs in the restored project; prepare its dependencies yourself. Inference/training compatibility is not certified. For model/workflow file preparation, prepare_model_deployment remains available. The experimental execution recipes below reuse a prepared environment; image/SDXL LoRA is not included.

The returned run_job_draft deliberately omits GPU selection, quote, budget, time limit, approval and idempotency key. Request a live quote, obtain explicit approval, then call existing run_job. Failed tasks are not automatically retried. To preserve results, explicitly request persist_results; normal storage eligibility, retention, quota and fees apply. workspace-python also requires the exact output_files your script writes under $CLOUDGPU_OUTPUT_DIR. Storage-fee consent defaults to false and is separate from GPU approval.

Experimental application execution recipes

comfyui-workflow runs an API-format workflow saved in an immutable Workspace against an already prepared ComfyUI application on GPU loopback (default port 8188). Models and custom nodes must already be available and reviewed. Supply workflow_path, image_count (1–4) and optionally comfy_port/timeout_seconds. It checks readiness, submits exactly once, polls that prompt and writes explicit image-N.png files plus task-summary.json. Lost submission responses, errors, redirects or unexpected output counts stop the task; no second prompt is submitted.

causal-lm-lora is small causal-language-model LoRA, not ComfyUI/image/SDXL training. Supply dataset_path (JSONL with a text field), a pinned public model_reference including configuration/tokenizer/weights, and reviewed target_modules. Optional steps (1–200), rank (1–16), sequence_length and learning_rate bound the work. Reuse an image with compatible CUDA, torch, transformers, peft and safetensors already installed. Model loading is offline from the D13 model directory with remote model code disabled. It writes adapter_model.safetensors, adapter_config.json and task-summary.json.

Both recipes require persist_results=true and an immutable Workspace. They do not install software or start servers, and preparation does not select a GPU, infer a budget, claim image compatibility or consent to storage charges. The existing Job API checks output-collection availability before accepting the request. GPU time, downloads and collection share the approved Job cap; existing storage charges are separate. Failed collection does not keep the GPU disk alive. Do not save arbitrary private logs as artifacts.

Validation boundary: ComfyUI HTTP execution/output and LoRA orchestration have local protocol fixtures, not real GPU generation/training or quality acceptance. These recipes remain experimental. Check the selected image and model before a paid run; no universal compatibility claim is made.

Bounded batches (D17 first stage)

1. Prepare each reviewed Job with a fresh quote_compute quote, its own GPU spending cap and time limit. Select output storage explicitly.
2. Call prepare_job_batch with a caller-retained batch_key, jobs (1–8) and total_budget_usd. Preparation is local and read-only. The sum of per-Job maximum spending must fit the total and client cap; this is a GPU budget, excluding separately approved storage charges.
3. Present all tasks, their quotes, time limits and combined cap to the user. Only after explicit approval, call run_job_batch with the identical input, returned approved_plan_sha256 and user_confirmed=true.
4. Retain the manifest, batch key and response receipt. Partial acceptance is possible; this is not an atomic transaction or an independent scheduler. A lost acknowledgement stops new submissions. To reconcile, replay only the identical approved manifest/key: existing server-side idempotency returns the original Jobs. Never invent replacement keys or silently change an expired quote. Changing a task requires a new review; an old batch key is not permission for extra spending.
5. Poll get_job_batch with the explicit Job IDs. stopping, needs_attention, unknown or unavailable state requires reconciliation. Do not treat a failed status or a destroy request as independent supplier release evidence. Cancel individual Jobs only through the existing cancel_job tool when authorized.

There are no automatic failed-execution retries. Each submitted Job survives a client disconnect using the existing durable backend queue. Unsubmitted members do not continue in the background if the MCP process exits. Fresh-attempt retry automation and a durable batch-level coordinator are not included. No warm GPU pool or new infrastructure is required.

Private local batch receipts (0.12.0)

run_job_batch now journals submission intents and accepted Job IDs under CLOUDGPU_CONFIG_DIR (default ~/.config/cloudgpu), in a private batch-receipts-v1 directory. get_job_batch_receipt({batch_key}) reads this local metadata without an API request. It records no commands, complete manifests, API keys, model URLs or signed links. Keep your original reviewed manifest separately.

After a client restart, reconnect with the same scoped API key and endpoint. Inspect the receipt, then use get_job_batch for live status. Replaying the exact approved manifest queries known accepted Jobs; only an uncertain acknowledgement is reconciled by the original create request/key. Unavailable, stopping or needs_attention stops progress. A local historical status is not a current supplier release audit. A missing receipt (another device/key, an older client, or lost files) is never proof that no GPU exists.

The local store must support private file permissions, no-follow file opens and atomic hard links. An unsafe/unavailable store refuses new batch submissions; a write failure after acceptance returns the known Job ID and stops later members. Do not silently switch to a new key or discard uncertain records. New entries are refused once 1,024 batch directories are observed for a key/endpoint; this local housekeeping check is not a concurrent server quota. Archive verified terminal receipts explicitly. Original single-Job tools remain available.

This is client-local receipt durability, not a server-side batch coordinator. Unsubmitted members do not run while the client is closed. No automatic retry of failed execution, new-attempt spending, refund or cancellation is added. Preparing a plan still creates no GPU and requires no account; paid submission still requires exact plan approval, fresh quotes and existing GPU/storage limits. Scopes on different keys or endpoints are separate; inspect existing resources before intentionally changing either.

Keep the exact original manifest outside the receipt store. Expired quotes for unsubmitted members may require reconciliation followed by a newly reviewed plan for the remaining work; do not overwrite the old ledger or regenerate keys merely to bypass expiry. Terminal status without final cost evidence also stops a journaled resume.

One in-flight batch retains its original API credential and endpoint even if another tool connects a different account concurrently. not_submitted in a returned call receipt means unvisited in that invocation only; those entries may have accepted Jobs from an earlier call. Inspect the saved receipt and live Job IDs before deciding what remains.

Use 0.12.1 or newer for directory-entry durability: newly created config/receipt directories and their parent entries are synced before paid submission. A parent-directory sync failure refuses new batch work. Existing 0.12.0 receipt records remain readable; preserve their IDs and original keys rather than deleting them. Process-exit tests alone do not constitute physical power-loss testing.