Update to Runpod (Official)

{
  "name": "runpod-mcp",
  "description": "Manage Runpod infrastructure — pods, serverless endpoints, jobs, templates, network volumes, container-registry auth, GPU/CPU catalog, and billing — via the Runpod MCP server's structured tool calls. Use when the Runpod MCP tools (create-pod, list-endpoints, …) are connected in this session, or to connect them (hosted OAuth or local npx). Prefer this over runpodctl for plain infra CRUD when MCP is available; use runpodctl for the terminal, file transfer, or SSH setup.",
  "included_files": [
    {
      "relative_path": "evals/when-to-use-mcp.eval.md",
      "size_in_bytes": 1045
    },
    {
      "relative_path": "reference/connect.md",
      "size_in_bytes": 1250
    }
  ],
  "skill_md_contents": "---\nname: runpod-mcp\ndescription: >-\n  Manage Runpod infrastructure — pods, serverless endpoints, jobs, templates,\n  network volumes, container-registry auth, GPU/CPU catalog, and billing — via\n  the Runpod MCP server's structured tool calls. Use when the Runpod MCP tools\n  (create-pod, list-endpoints, …) are connected in this session, or to connect\n  them (hosted OAuth or local npx). Prefer this over runpodctl for plain infra\n  CRUD when MCP is available; use runpodctl for the terminal, file transfer, or\n  SSH setup.\nallowed-tools: Bash(npx:*), Bash(claude:*)\ncompatibility: Linux, macOS, Windows\nmetadata:\n  author: runpod\n  version: \"1.1.2\" # x-release-please-version\nlicense: Apache-2.0\n---\n\n# Runpod MCP\n\nThe Runpod MCP server exposes Runpod's control plane as structured tool calls,\nso an MCP-capable agent can manage infrastructure without shelling out. It is the\nsame Runpod REST API that `runpodctl` uses — pick MCP when its tools are\nconnected (typed params, structured errors, no shell quoting).\n\n## Connect\n\nConnect the hosted server with **your API key as a Bearer header** if you also use runpodctl/flash — that one key auths the MCP *and* the CLIs (the 80% path):\n\n```bash\nclaude mcp add --transport http runpod -s user https://mcp.getrunpod.io/ \\\n  --header \"Authorization: Bearer $RUNPOD_API_KEY\"\n```\n\nPlain **OAuth** (\"Sign in with Runpod\", via `npx @runpod/mcp-server@latest add`) is MCP-only — the CLIs stay unauthed, so use it only for MCP-only work. Local **stdio** runs the server as a subprocess with your key. Those variants + the key-vs-OAuth tradeoff: **[reference/connect.md](reference/connect.md)**. After connecting, reconnect the client (in Claude Code, `/mcp`) so the tools load.\n\n**Verify it's live (do this before relying on MCP):** in Claude Code run `/mcp` —\n`runpod` should show **Connected**, not *Needs authentication* (if it's the latter,\nsign in there first; the bundled plugin server registers the URL but stays inert\nuntil you authenticate). Confirm a real call works by asking for `list-endpoints`.\nIf the `runpod` tools aren't present at all, the server isn't connected — (re)run the\ninstall above, or fall back to **runpodctl** for this task.\n\n**Check the server version (which REST API it drives):** the MCP `initialize` handshake\nreturns it in `serverInfo.version`. `/mcp` in Claude Code shows it, or probe the hosted\nserver directly:\n\n```bash\nprintf '%s\\n' '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2024-11-05\",\"capabilities\":{},\"clientInfo\":{\"name\":\"probe\",\"version\":\"0\"}}}' \\\n| curl -s -X POST https://mcp.getrunpod.io/ -H \"Content-Type: application/json\" \\\n    -H \"Accept: application/json, text/event-stream\" -H \"Authorization: Bearer $RUNPOD_API_KEY\" -d @-\n# → serverInfo.version e.g. \"3.0.0 [RUNPOD_REST_VERSION=v2]\"  (verified 2026-07-29)\n```\n\nThe MCP server drives Runpod's **REST v2** internally (`RUNPOD_REST_VERSION=v2`), so most\ntools avoid the buggy **public `rest.runpod.io/v1`** control API. Two exceptions worth\nknowing: the Hub, public-endpoint and `set-endpoint-gpus` tools go through GraphQL (so they\nwork under either REST version), and **CPU serverless endpoints are not creatable through\nMCP** — v2 has no CPU-endpoint concept at all (`create-endpoint` requires `gpuPoolIds`), so\nuse `runpodctl serverless create --compute-type CPU` for those.\n\n**Prefer MCP or `runpodctl` over hand-rolled `rest.runpod.io/v1` calls for creating endpoints.**\n\n## Tool surface\n\nStructured tools, grouped by resource:\n\n- **Pods** — list, get, create, update, start, stop, restart, delete, stream logs.\n- **Serverless endpoints** — list, get, create, update, delete; list workers; list releases; stream worker logs.\n  - `create-endpoint` takes `endpointType: QUEUE` (default) or `LOAD_BALANCER` — see golden path 14. The routing type is fixed at creation; `update-endpoint` cannot change it.\n  - Read an endpoint's invoke URLs from `requestUrls` on the get/list reply instead of assembling them.\n  - To pin a specific GPU **SKU** on an existing endpoint use `set-endpoint-gpus`; `create-endpoint`/`update-endpoint` expose only `gpuPoolIds` and can't express a SKU (`deploy-hub-repo` can pin one at deploy time via `gpuIds` exclusions).\n- **Jobs (serverless runtime)** — run, runsync, status, stream, cancel, retry, health, purge queue.\n- **Hub** — `list-hub-repos` (public catalog of prebuilt Serverless workers and Pod templates: vLLM, ComfyUI, …) and `deploy-hub-repo`, which deploys a repo's listed release as an endpoint — the same as clicking Deploy on the Hub.\n- **Public endpoints** — `list-public-endpoints`: managed pay-per-use model APIs (text/image/video/audio) that need no deployment. Call the returned endpointId with `run-endpoint`/`runsync-endpoint`.\n- **Templates** — list, get, create, update, delete.\n- **Network volumes** — list, get, create, update, delete. `create-network-volume` takes `volumeType` (`STANDARD` | `HIGH_PERFORMANCE`) and a size of 10–4096 GB; omit `volumeType` to get the data center's default tier. The tier is **immutable after creation** — `update-network-volume` can't change it.\n- **Container registry auth** — list, get, create, delete. A username + password for **any** registry; pass the resulting id as `containerRegistryAuthId` on create-pod/create-endpoint.\n- **ECR delegations** (`list-`/`create-`/`delete-registry-delegation`) — **AWS ECR only**, v2 only, and stores no credentials: you register a repository ARN and Runpod gets scoped pull access instead. Prefer it over a stored username/password for ECR. The reply carries a `dockerRegistryUri` — that's the image URI to deploy with.\n- **Catalog** — list/get GPU types, list/get CPU types, list/get data centers.\n- **Billing** — scoped usage/cost breakdowns (`get-billing`).\n\n> The tool list above is a map, not a contract. The server is the source of truth —\n> `/mcp` (or your client's tool list) shows exactly what the connected version exposes,\n> and each tool carries its own parameter descriptions. Check there before assuming a\n> capability exists or doesn't.\n\n> Delete tools (`delete-template`, `delete-pod`, …) can return `isError: true` with\n> \"Unexpected end of JSON input\" **even on success** — the Runpod REST API returns\n> 204 No Content. Don't treat it as failure; confirm with a follow-up `get-`/`list-`\n> (a deleted resource then 404s).\n\n## Use MCP vs runpodctl\n\n- **Use runpod-mcp** when the tools are connected AND the task is infra CRUD or a\n  serverless job call the server exposes. Cap large job/log output to a file.\n- **Use runpodctl instead** for: **`send`/`receive`** file transfer, **SSH** key\n  management, **`doctor`** setup, **model cache** — or any shell-only agent, or\n  when the user wants a reproducible command.\n- **Hand pod creation to runpodctl** for a **multi-GPU priority list** (MCP's v2\n  create-pod takes one GPU type; extra `gpuTypeIds` are dropped with a `_warning`\n  on success), or for a **template + CPU** pod together — `create-pod` rejects that\n  combination, since a template deploy is GPU-and-v2-only. Each alone is fine in\n  MCP: `templateId` (v2-only, `imageName` then optional, and each field you pass\n  replaces the template's whole value rather than merging) or `computeType: \"CPU\"`.\n- **Not this lane:** writing/deploying your own Python (→ flash); downloading\n  models or building/pushing images (→ companion-clis).\n\nFor concepts (pods vs serverless, GPU selection, storage), read\n`../runpod-usage/`.\n\n## Source & docs\n\n- Server source: https://github.com/runpod/runpod-mcp\n- Package (npm): https://www.npmjs.com/package/@runpod/mcp-server\n- Hosted endpoint: https://mcp.getrunpod.io/\n- Docs: https://docs.runpod.io\n"
}