[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CFV6RYMK8FSVJX8HHBQ924":3,"skill-same:01M6CFV6RYMK8FSVJX8HHBQ924":110},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":73,"commitSha":74,"skillDirectory":75,"forksCount":76,"repositoryHtmlUrl":77,"repositoryHomepageUrl":78,"ownerHtmlUrl":79,"ownerBlogUrl":80,"ownerDescription":6,"updatedAt":81,"install":82,"resources":95},"01M6CFV6RYMK8FSVJX8HHBQ924","runpod-mcp",null,"Manage Runpod infrastructure through the connected Runpod MCP server's tool calls (pods, serverless endpoints and jobs, templates, network volumes, registry credentials, secrets, clusters, the GPU\u002FCPU catalog, and billing), and connect the server when it is missing (hosted or local npx). Load it before the first Runpod MCP tool call of a request: it routes the task to the journey skill that carries the procedure, owns the answer contract and the rules on which resources you may change, and defers to runpodctl for the terminal, file transfer, and SSH setup; template project and Hub listing authoring routes to runpod-build-template.","runpod\u002Frunpod-plugins-official","runpod","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F95939477?v=4","01M6CFSV7PCCKKMKEV6AM8XC7H","Runpod","01M6CFSVC1QMHFR2P1HF14EZ08",49,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-mcp\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[9,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"runpod mcp","MCP","listing","when","you","journey","local","project","resources","volume","billing","which","change","server","log","api","mcp server","Bash","connect","2026-11-10 10:12:30",false,"---\nname: runpod-mcp\ndescription: >-\n  Manage Runpod infrastructure through the connected Runpod MCP server's tool\n  calls (pods, serverless endpoints and jobs, templates, network volumes,\n  registry credentials, secrets, clusters, the GPU\u002FCPU catalog, and billing),\n  and connect the server when it is missing (hosted or local npx). Load it\n  before the first Runpod MCP tool call of a request: it routes the task to the\n  journey skill that carries the procedure, owns the answer contract and the\n  rules on which resources you may change, and defers to runpodctl for the\n  terminal, file transfer, and SSH setup; template project and Hub listing authoring\n  routes to runpod-build-template.\nallowed-tools: Bash(claude mcp:*)\ncompatibility: Linux, macOS, Windows\nmetadata:\n  author: runpod\n  version: \"2.0.0\" # x-release-please-version\n  concepts: [runpod-platform, pod, serverless-endpoint, job, template, network-volume, registry-credential, gpu-type, log-stream, api-key, api-rate-limit, hub-repo]\nlicense: Apache-2.0\n---\n\n# Runpod MCP\n\nThe Runpod MCP server exposes Runpod's control plane as structured tool calls, so an\nMCP-capable agent can manage infrastructure without shelling out. It is the same Runpod\nREST API that `runpodctl` uses. Pick MCP when its tools are connected (typed params,\nstructured errors, no shell quoting).\n\nThis skill owns the MCP side: it connects and authenticates the server, sets the\ntool-use rules, routes each request to the journey skill that carries its procedure\n([Route by intent](#route-by-intent)), and owns the **answer contract** below, which every\nreply follows. Lane choice (MCP vs runpodctl vs flash) belongs to the\n[router](..\u002Frunpod\u002FSKILL.md).\n\n**For a multi-step job, read the worked example before calling tools**: tool calls are\neasy to issue in the wrong order. The golden paths\n([index](..\u002Frunpod\u002Fgolden-paths\u002FREADME.md)) cover what order to do a whole job in; the\njourney skills cover procedure within one journey.\n\n## Connect\n\nWith a user present, connect the hosted server with **OAuth** (\"Sign in with Runpod\"; no key on disk). That's the default from the onboarding guide at https:\u002F\u002Fagents.runpod.io\u002F:\n\n```bash\nclaude mcp add --transport http runpod -s user https:\u002F\u002Fmcp.runpod.io\u002F\n```\n\nOAuth signs in the MCP only. When a task later needs runpodctl or flash, get a `RUNPOD_API_KEY` at that point. With no user in the loop, or a client whose OAuth callback the server rejects (`redirect_uri is not allowed`), send the key as a header instead: `--header \"Authorization: Bearer $RUNPOD_API_KEY\"`. Local **stdio** runs the server as a subprocess with your key. Other clients and the key-vs-OAuth tradeoff: **[reference\u002Fconnect.md](reference\u002Fconnect.md)**. After connecting, reconnect the client (in Claude Code, `\u002Fmcp`) so the tools load.\n\n**Verify it's live (do this before relying on MCP):** in Claude Code run `\u002Fmcp`.\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`. `\u002Fmcp` 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:\u002F\u002Fmcp.runpod.io\u002F \\\n    -H \"Content-Type: application\u002Fjson\" \\\n    -H \"Accept: application\u002Fjson, text\u002Fevent-stream\" \\\n    -H \"Authorization: Bearer $RUNPOD_API_KEY\" -d @-\n```\n\n## The server is the source of truth\n\nOnce connected, read the server. Do not reason about its tools from memory.\n\n1. **The tool list and every parameter** come from the client's own view of the\n   connected server: `\u002Fmcp` in Claude Code, or `tools\u002Flist`. Each tool carries its\n   own parameter descriptions, generated from Runpod's REST v2 contract. Check there\n   before concluding a capability exists *or* doesn't. When a journey skill's tool\n   binding disagrees with the live tool list, the live list wins. Some large\n   create\u002Fupdate tools (`create-pod`, `create-endpoint`, `create-template` and others;\n   the listing says so) list only their call shape: call `describe-tool` with the tool\n   name for the full argument schema before the first use.\n2. **The server serves these same skills** from this plugin's release: `read-guide`\n   (start with `read-guide runpod-mcp`) and the `runpod:\u002F\u002Fguides\u002F\u003Cid>` resources. With\n   this plugin installed, the journey skills below are the procedure; the server's\n   guides are the same text for an agent without the plugin. A skill's\n   `reference\u002F\u003Cname>.md` link is guide id `\u003Cskill>\u002F\u003Cname>` (e.g.\n   `runpod-serverless-deploy\u002Ferror-handling`).\n3. **The wire contract** is the Runpod v2 OpenAPI document at\n   `https:\u002F\u002Fapi.runpod.io\u002Fv2\u002Fopenapi.json`, for fields beyond the tool surface.\n\nFor concepts (pods vs serverless, GPU selection, storage), read `..\u002Frunpod-usage\u002F`.\n\n## Use MCP vs runpodctl\n\n- **Use this lane** for infra CRUD, browsing\u002Fdeploying an existing Hub listing,\n  or a serverless job call the connected server exposes; the\n  [router capability matrix](..\u002Frunpod\u002FSKILL.md#runpod-mcp-vs-runpodctl-the-overlap) picks\n  the lane per operation. Cap large job\u002Flog output to a file.\n- **Use runpodctl instead** for what these tools lack (see\n  [Capability boundaries](#capability-boundaries--state-them-never-fake-them)), for any\n  shell-only agent, or when the user wants a reproducible command.\n- **Pin the CUDA floor on every GPU create**: `gpu.minCudaVersion` on `create-pod` and\n  `create-endpoint` (`\"12.8\"` by default, `\"13.0\"` only for a CUDA-13 image),\n  `allowedCudaVersions` on `create-template`. Without a floor a modern image can land on a\n  host too old to run it ([why](..\u002Frunpod-usage\u002Freference\u002Fgpu-selection.md#step-3-pin-the-cuda-floor)).\n- **Set `timeout` (ms) on every `create-endpoint`**: omitted, v2 returns `\"timeout\": 0`\n  (live-verified 2026-10-29). After `deploy-hub-repo`, read `timeout` back and set it with\n  `update-endpoint` if it is 0\n  ([details](..\u002Frunpod-usage\u002Freference\u002Fgotchas.md#endpoint-timeout-comes-back-0)).\n- **Pod creates:** `create-pod` takes one GPU type (`gpu.id`; check the live schema\n  before assuming, and watch for a `_warning` on an otherwise-successful create), so a\n  multi-GPU priority list means one create per type, retried in order on a capacity\n  error. A CPU pod sends a `cpu` object (`{id, vcpuCount}` from `list-cpu-types`) in\n  place of `gpu`. `templateId` works for GPU and CPU pods: each field you pass replaces\n  the template's value (fields you omit come from it: image, args, ports and disk in the\n  2026-10-29 run), except `env`, which merges per key with yours winning; the pod\n  keeps no template link, and a CPU pod skips the template's persistent mount and CUDA constraint (template + CPU live-verified\n  2026-10-29, even with an NVIDIA-category template). The CLI issues this same v2\n  call, so switching to it does not help.\n- **Not this lane:** authoring a template project or Hub listing files\n  (→ [runpod-build-template](..\u002Frunpod-build-template\u002FSKILL.md)); writing\u002Fdeploying\n  your own Python with Flash (→ runpod-flash); downloading models or building\u002Fpushing\n  images (→ runpod-companion-clis).\n\n## Route by intent\n\n| The user wants to… | Journey skill |\n| --- | --- |\n| Know what GPUs\u002Fworkers\u002Fendpoints exist, what fits a model, what it costs | **runpod-discovery** |\n| Create\u002Finspect\u002Fupdate\u002Fdelete pods, endpoints, templates, network or global volumes, account secrets, SSH keys, clusters; inventory of the account; who changed what (audit log) or who is in the organization | **runpod-lifecycle-crud** |\n| Stand up a serverless endpoint for a model\u002Fworkload and verify it with a real job | **runpod-serverless-deploy** |\n| Host a ComfyUI workflow (workflow.json, custom Civitai models\u002FLoRAs) as an endpoint | **runpod-serverless-deploy**, then its [ComfyUI reference](..\u002Frunpod-serverless-deploy\u002Freference\u002Fcomfyui-serverless.md) |\n| Serve an LLM with vLLM (Hub worker-vllm endpoint, load-balancing endpoint on a vLLM image, or a Pod), or fix a vLLM deployment that will not boot | **runpod-vllm** |\n| Rent\u002Fconfigure an interactive GPU pod; create a pod then pause\u002Fstop it for later | **runpod-pod-deploy** |\n| Diagnose a broken\u002Fmisbehaving pod (0 GPUs, CUDA, crashes, 502s) | **runpod-pod-doctor** |\n| Operate an existing endpoint: jobs, scaling, workers, logs | **runpod-endpoint-ops** |\n| Understand or reduce spend; billing breakdowns | **runpod-cost-audit** |\n| Something the tools may not cover (file transfer, a command inside a Pod) | [Capability boundaries](#capability-boundaries--state-them-never-fake-them) below |\n\n## Capability boundaries — state them, never fake them\n\nThis interface manages infra through the Runpod MCP tools. It does NOT do:\nSSH sessions, file transfer to\u002Ffrom pods, local image builds, model downloads\nto volumes, or interactive terminals. When a task needs one of those, say\nthat it is not available through these tools and name the lane that does it:\n`runpodctl` for file transfer (`send`\u002F`receive`), SSH key setup, `doctor` setup,\nmodel cache and model uploads; SSH or the console web terminal for commands inside\na Pod; the Flash SDK for code-first Serverless deploys; the console for Pod\nmigration. Never improvise a fake capability or silently drop that part of the task.\n\nCheck the served tool list before calling anything a gap: account secrets and\nInstant Clusters were console-only once and are served tools now. The workaround\nfor each gap, and the discipline for answering one, are in\n[reference\u002Fapi-boundary.md](reference\u002Fapi-boundary.md).\n\n## Live reads before mutations\n\nA template id, a GPU's stock or price, or a resource's state is confirmed with\na list- or get- tool before you act on it, even when a guide or an earlier\nsession named it.\n\n## The answer contract\n\nEvery Runpod reply follows these rules. Journey skills add journey-specific\nrules and report templates; they never weaken these.\n\n**Facts come from tool reads, stated as facts.**\n- Name the read behind each fact in the answer itself (\"from the templates\n  read\", \"from list-hub-repos\", \"from the pod's logs\"): an image, a price or a\n  stock figure stated without its read is not evidence, however correct.\n- Quote real figures, names, and IDs from the reads you just made, not from\n  memory and not rounded into vagueness. IDs verbatim.\n- State current stock\u002Fstatus definitively (\"RTX 4090 in EU-RO-1: available\n  now\"), never \"should be\", \"probably\", or \"check later\". The read you just\n  did IS the check.\n- Never contradict your own data: if your table says a card is available, the\n  summary cannot call it out of stock.\n\n**Commit; don't hedge, don't defer.**\n- Diagnosis means ONE most-likely cause plus its concrete fix, chosen from the\n  evidence, rather than a menu of possibilities or \"run these commands and\n  tell me\".\n- If the account state makes the question moot (nothing deployed, zero spend),\n  say exactly that in one sentence and stop. An honest empty answer is\n  complete.\n- Never ask the user for information a tool could have given you. Push on\n  with the tools you have; ask only when the user is the sole source: their\n  credentials, their intent on a destructive step, a product choice.\n- `create-cluster` always waits for an explicit go: never call it until the\n  user has seen the shape (nodes, GPUs per node, data center) and the total\n  hourly price from the catalog read and has said go in this conversation. A\n  request to create a cluster asks for that plan and its price; the create\n  waits for the go.\n- When the request fixes a class but not the item (\"a small model\", \"a 24 GB\n  card\", an image named without its settings), choose the documented default,\n  state the choice in one line, and proceed. A setting the user did not\n  mention is never a reason to stop; stop only when a wrong guess would spend\n  heavily or destroy data.\n- A request to deploy, set up or create something is the go for that create.\n  Quote the hourly price from the catalog read in the same reply and make the\n  call; never end the turn on \"want me to go ahead?\". Two things wait for an\n  explicit go: a cluster (above), and a standing charge the user did not ask\n  for by name, such as a warm worker. For those, create the part that bills\n  nothing while idle, then quote the standing charge per hour and per month\n  and offer it.\n\n**Mutations bind to what this conversation created or the user named.**\n- You may stop, update, or delete a resource created by your own tool calls\n  in this conversation. You may also change the one resource the user named\n  in the request by its id or an unambiguous name (a setting on one\n  endpoint, one job on its queue), but only the change they asked\n  for: a user-named resource is deleted only when the user asked for that\n  delete. The user's instruction is the authority for that one resource, so\n  do the change rather than handing them console steps. Otherwise, provenance\n  comes from your create outputs, never from a name you found by listing. A\n  disposable-looking name, an auto-generated slug, or a familiar prefix is not\n  attribution.\n- A cleanup or cost-cutting instruction does not extend that authority,\n  however urgently it is phrased. For anything you cannot\n  attribute to this conversation, the complete answer is the audit: what you\n  checked, what qualifies, the ids, and the exact actions for the USER to\n  take. That is a full answer, not a deferral. The commit-don't-hedge rule\n  never licenses mutating a resource that isn't yours.\n- When nothing this conversation created remains, say exactly that and touch\n  nothing.\n- Every write is checked by a fresh read. After a create or update, read the\n  resource back and confirm the fields you set; after a delete, read again and\n  confirm it is gone; after a job cancel or a queue purge, read the job or the\n  queue again. For a settings change, also read the current values before the\n  write, so the answer gives before and after, both from reads. The write\n  call's own response is not that read, and the final message quotes what the\n  read showed.\n- A permission error on a resource you did not create is a correct answer,\n  not an obstacle: report it as out of scope. Never retry it or advise\n  re-running from a less-restricted session or key to get around it.\n\n**The final message stands alone.**\n- Close with a summary the user can act on without scrolling back: the ids,\n  URLs, prices, and commands the task produced belong in it. No \"the link\n  above\" and no pointer to an earlier turn.\n\n**Carry the work as far as the tools allow.**\n- Prefer a server-side wait (`wait` parameters) over handing the user a poll\n  loop; check state between holds. When a wait outlasts what the tools can\n  hold, report the evidenced state (what was created, what was submitted,\n  what the worker states show) and the recommended next step. Offering to\n  keep watching is fine; silently stopping mid-wait is not.\n\n**Honest failure beats fabricated success.**\n- Report failures with the observed evidence (the error body, the worker\n  state, the log line). Never report a success without the artifact that\n  proves it (the output the job returned).\n- A missing credential or capability is reported as exactly that, with what\n  you did to confirm it and what the user must supply.\n\n**Use only the tools you were given.**\n- If a tool is not available in this session, work with the ones that are;\n  reads you already made can be analyzed directly. Never stall the task\n  requesting new tool access.\n\n**Report habits** (inventory, cost, deployment reports):\n- Enumerations read best as tables carrying each resource's name and id.\n- Every dollar figure comes from a billing\u002Fpricing read made this turn; give\n  totals beside per-item figures, and show empty categories rather than\n  silently dropping them.\n- Lead the user to the number or verdict they asked for.\n\n## Source & docs\n\n- Server source: https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-mcp\n- Package (npm): https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@runpod\u002Fmcp-server\n- Hosted endpoint: https:\u002F\u002Fmcp.runpod.io\u002F\n- Docs: https:\u002F\u002Fdocs.runpod.io\n","# Runpod MCP\n\nThe Runpod MCP server exposes Runpod's control plane as structured tool calls, so an\nMCP-capable agent can manage infrastructure without shelling out. It is the same Runpod\nREST API that `runpodctl` uses. Pick MCP when its tools are connected (typed params,\nstructured errors, no shell quoting).\n\nThis skill owns the MCP side: it connects and authenticates the server, sets the\ntool-use rules, routes each request to the journey skill that carries its procedure\n([Route by intent](#route-by-intent)), and owns the **answer contract** below, which every\nreply follows. Lane choice (MCP vs runpodctl vs flash) belongs to the\n[router](..\u002Frunpod\u002FSKILL.md).\n\n**For a multi-step job, read the worked example before calling tools**: tool calls are\neasy to issue in the wrong order. The golden paths\n([index](..\u002Frunpod\u002Fgolden-paths\u002FREADME.md)) cover what order to do a whole job in; the\njourney skills cover procedure within one journey.\n\n## Connect\n\nWith a user present, connect the hosted server with **OAuth** (\"Sign in with Runpod\"; no key on disk). That's the default from the onboarding guide at https:\u002F\u002Fagents.runpod.io\u002F:\n\n```bash\nclaude mcp add --transport http runpod -s user https:\u002F\u002Fmcp.runpod.io\u002F\n```\n\nOAuth signs in the MCP only. When a task later needs runpodctl or flash, get a `RUNPOD_API_KEY` at that point. With no user in the loop, or a client whose OAuth callback the server rejects (`redirect_uri is not allowed`), send the key as a header instead: `--header \"Authorization: Bearer $RUNPOD_API_KEY\"`. Local **stdio** runs the server as a subprocess with your key. Other clients and the key-vs-OAuth tradeoff: **[reference\u002Fconnect.md](reference\u002Fconnect.md)**. After connecting, reconnect the client (in Claude Code, `\u002Fmcp`) so the tools load.\n\n**Verify it's live (do this before relying on MCP):** in Claude Code run `\u002Fmcp`.\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`. `\u002Fmcp` 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:\u002F\u002Fmcp.runpod.io\u002F \\\n    -H \"Content-Type: application\u002Fjson\" \\\n    -H \"Accept: application\u002Fjson, text\u002Fevent-stream\" \\\n    -H \"Authorization: Bearer $RUNPOD_API_KEY\" -d @-\n```\n\n## The server is the source of truth\n\nOnce connected, read the server. Do not reason about its tools from memory.\n\n1. **The tool list and every parameter** come from the client's own view of the\n   connected server: `\u002Fmcp` in Claude Code, or `tools\u002Flist`. Each tool carries its\n   own parameter descriptions, generated from Runpod's REST v2 contract. Check there\n   before concluding a capability exists *or* doesn't. When a journey skill's tool\n   binding disagrees with the live tool list, the live list wins. Some large\n   create\u002Fupdate tools (`create-pod`, `create-endpoint`, `create-template` and others;\n   the listing says so) list only their call shape: call `describe-tool` with the tool\n   name for the full argument schema before the first use.\n2. **The server serves these same skills** from this plugin's release: `read-guide`\n   (start with `read-guide runpod-mcp`) and the `runpod:\u002F\u002Fguides\u002F\u003Cid>` resources. With\n   this plugin installed, the journey skills below are the procedure; the server's\n   guides are the same text for an agent without the plugin. A skill's\n   `reference\u002F\u003Cname>.md` link is guide id `\u003Cskill>\u002F\u003Cname>` (e.g.\n   `runpod-serverless-deploy\u002Ferror-handling`).\n3. **The wire contract** is the Runpod v2 OpenAPI document at\n   `https:\u002F\u002Fapi.runpod.io\u002Fv2\u002Fopenapi.json`, for fields beyond the tool surface.\n\nFor concepts (pods vs serverless, GPU selection, storage), read `..\u002Frunpod-usage\u002F`.\n\n## Use MCP vs runpodctl\n\n- **Use this lane** for infra CRUD, browsing\u002Fdeploying an existing Hub listing,\n  or a serverless job call the connected server exposes; the\n  [router capability matrix](..\u002Frunpod\u002FSKILL.md#runpod-mcp-vs-runpodctl-the-overlap) picks\n  the lane per operation. Cap large job\u002Flog output to a file.\n- **Use runpodctl instead** for what these tools lack (see\n  [Capability boundaries](#capability-boundaries--state-them-never-fake-them)), for any\n  shell-only agent, or when the user wants a reproducible command.\n- **Pin the CUDA floor on every GPU create**: `gpu.minCudaVersion` on `create-pod` and\n  `create-endpoint` (`\"12.8\"` by default, `\"13.0\"` only for a CUDA-13 image),\n  `allowedCudaVersions` on `create-template`. Without a floor a modern image can land on a\n  host too old to run it ([why](..\u002Frunpod-usage\u002Freference\u002Fgpu-selection.md#step-3-pin-the-cuda-floor)).\n- **Set `timeout` (ms) on every `create-endpoint`**: omitted, v2 returns `\"timeout\": 0`\n  (live-verified 2026-10-29). After `deploy-hub-repo`, read `timeout` back and set it with\n  `update-endpoint` if it is 0\n  ([details](..\u002Frunpod-usage\u002Freference\u002Fgotchas.md#endpoint-timeout-comes-back-0)).\n- **Pod creates:** `create-pod` takes one GPU type (`gpu.id`; check the live schema\n  before assuming, and watch for a `_warning` on an otherwise-successful create), so a\n  multi-GPU priority list means one create per type, retried in order on a capacity\n  error. A CPU pod sends a `cpu` object (`{id, vcpuCount}` from `list-cpu-types`) in\n  place of `gpu`. `templateId` works for GPU and CPU pods: each field you pass replaces\n  the template's value (fields you omit come from it: image, args, ports and disk in the\n  2026-10-29 run), except `env`, which merges per key with yours winning; the pod\n  keeps no template link, and a CPU pod skips the template's persistent mount and CUDA constraint (template + CPU live-verified\n  2026-10-29, even with an NVIDIA-category template). The CLI issues this same v2\n  call, so switching to it does not help.\n- **Not this lane:** authoring a template project or Hub listing files\n  (→ [runpod-build-template](..\u002Frunpod-build-template\u002FSKILL.md)); writing\u002Fdeploying\n  your own Python with Flash (→ runpod-flash); downloading models or building\u002Fpushing\n  images (→ runpod-companion-clis).\n\n## Route by intent\n\n| The user wants to… | Journey skill |\n| --- | --- |\n| Know what GPUs\u002Fworkers\u002Fendpoints exist, what fits a model, what it costs | **runpod-discovery** |\n| Create\u002Finspect\u002Fupdate\u002Fdelete pods, endpoints, templates, network or global volumes, account secrets, SSH keys, clusters; inventory of the account; who changed what (audit log) or who is in the organization | **runpod-lifecycle-crud** |\n| Stand up a serverless endpoint for a model\u002Fworkload and verify it with a real job | **runpod-serverless-deploy** |\n| Host a ComfyUI workflow (workflow.json, custom Civitai models\u002FLoRAs) as an endpoint | **runpod-serverless-deploy**, then its [ComfyUI reference](..\u002Frunpod-serverless-deploy\u002Freference\u002Fcomfyui-serverless.md) |\n| Serve an LLM with vLLM (Hub worker-vllm endpoint, load-balancing endpoint on a vLLM image, or a Pod), or fix a vLLM deployment that will not boot | **runpod-vllm** |\n| Rent\u002Fconfigure an interactive GPU pod; create a pod then pause\u002Fstop it for later | **runpod-pod-deploy** |\n| Diagnose a broken\u002Fmisbehaving pod (0 GPUs, CUDA, crashes, 502s) | **runpod-pod-doctor** |\n| Operate an existing endpoint: jobs, scaling, workers, logs | **runpod-endpoint-ops** |\n| Understand or reduce spend; billing breakdowns | **runpod-cost-audit** |\n| Something the tools may not cover (file transfer, a command inside a Pod) | [Capability boundaries](#capability-boundaries--state-them-never-fake-them) below |\n\n## Capability boundaries — state them, never fake them\n\nThis interface manages infra through the Runpod MCP tools. It does NOT do:\nSSH sessions, file transfer to\u002Ffrom pods, local image builds, model downloads\nto volumes, or interactive terminals. When a task needs one of those, say\nthat it is not available through these tools and name the lane that does it:\n`runpodctl` for file transfer (`send`\u002F`receive`), SSH key setup, `doctor` setup,\nmodel cache and model uploads; SSH or the console web terminal for commands inside\na Pod; the Flash SDK for code-first Serverless deploys; the console for Pod\nmigration. Never improvise a fake capability or silently drop that part of the task.\n\nCheck the served tool list before calling anything a gap: account secrets and\nInstant Clusters were console-only once and are served tools now. The workaround\nfor each gap, and the discipline for answering one, are in\n[reference\u002Fapi-boundary.md](reference\u002Fapi-boundary.md).\n\n## Live reads before mutations\n\nA template id, a GPU's stock or price, or a resource's state is confirmed with\na list- or get- tool before you act on it, even when a guide or an earlier\nsession named it.\n\n## The answer contract\n\nEvery Runpod reply follows these rules. Journey skills add journey-specific\nrules and report templates; they never weaken these.\n\n**Facts come from tool reads, stated as facts.**\n- Name the read behind each fact in the answer itself (\"from the templates\n  read\", \"from list-hub-repos\", \"from the pod's logs\"): an image, a price or a\n  stock figure stated without its read is not evidence, however correct.\n- Quote real figures, names, and IDs from the reads you just made, not from\n  memory and not rounded into vagueness. IDs verbatim.\n- State current stock\u002Fstatus definitively (\"RTX 4090 in EU-RO-1: available\n  now\"), never \"should be\", \"probably\", or \"check later\". The read you just\n  did IS the check.\n- Never contradict your own data: if your table says a card is available, the\n  summary cannot call it out of stock.\n\n**Commit; don't hedge, don't defer.**\n- Diagnosis means ONE most-likely cause plus its concrete fix, chosen from the\n  evidence, rather than a menu of possibilities or \"run these commands and\n  tell me\".\n- If the account state makes the question moot (nothing deployed, zero spend),\n  say exactly that in one sentence and stop. An honest empty answer is\n  complete.\n- Never ask the user for information a tool could have given you. Push on\n  with the tools you have; ask only when the user is the sole source: their\n  credentials, their intent on a destructive step, a product choice.\n- `create-cluster` always waits for an explicit go: never call it until the\n  user has seen the shape (nodes, GPUs per node, data center) and the total\n  hourly price from the catalog read and has said go in this conversation. A\n  request to create a cluster asks for that plan and its price; the create\n  waits for the go.\n- When the request fixes a class but not the item (\"a small model\", \"a 24 GB\n  card\", an image named without its settings), choose the documented default,\n  state the choice in one line, and proceed. A setting the user did not\n  mention is never a reason to stop; stop only when a wrong guess would spend\n  heavily or destroy data.\n- A request to deploy, set up or create something is the go for that create.\n  Quote the hourly price from the catalog read in the same reply and make the\n  call; never end the turn on \"want me to go ahead?\". Two things wait for an\n  explicit go: a cluster (above), and a standing charge the user did not ask\n  for by name, such as a warm worker. For those, create the part that bills\n  nothing while idle, then quote the standing charge per hour and per month\n  and offer it.\n\n**Mutations bind to what this conversation created or the user named.**\n- You may stop, update, or delete a resource created by your own tool calls\n  in this conversation. You may also change the one resource the user named\n  in the request by its id or an unambiguous name (a setting on one\n  endpoint, one job on its queue), but only the change they asked\n  for: a user-named resource is deleted only when the user asked for that\n  delete. The user's instruction is the authority for that one resource, so\n  do the change rather than handing them console steps. Otherwise, provenance\n  comes from your create outputs, never from a name you found by listing. A\n  disposable-looking name, an auto-generated slug, or a familiar prefix is not\n  attribution.\n- A cleanup or cost-cutting instruction does not extend that authority,\n  however urgently it is phrased. For anything you cannot\n  attribute to this conversation, the complete answer is the audit: what you\n  checked, what qualifies, the ids, and the exact actions for the USER to\n  take. That is a full answer, not a deferral. The commit-don't-hedge rule\n  never licenses mutating a resource that isn't yours.\n- When nothing this conversation created remains, say exactly that and touch\n  nothing.\n- Every write is checked by a fresh read. After a create or update, read the\n  resource back and confirm the fields you set; after a delete, read again and\n  confirm it is gone; after a job cancel or a queue purge, read the job or the\n  queue again. For a settings change, also read the current values before the\n  write, so the answer gives before and after, both from reads. The write\n  call's own response is not that read, and the final message quotes what the\n  read showed.\n- A permission error on a resource you did not create is a correct answer,\n  not an obstacle: report it as out of scope. Never retry it or advise\n  re-running from a less-restricted session or key to get around it.\n\n**The final message stands alone.**\n- Close with a summary the user can act on without scrolling back: the ids,\n  URLs, prices, and commands the task produced belong in it. No \"the link\n  above\" and no pointer to an earlier turn.\n\n**Carry the work as far as the tools allow.**\n- Prefer a server-side wait (`wait` parameters) over handing the user a poll\n  loop; check state between holds. When a wait outlasts what the tools can\n  hold, report the evidenced state (what was created, what was submitted,\n  what the worker states show) and the recommended next step. Offering to\n  keep watching is fine; silently stopping mid-wait is not.\n\n**Honest failure beats fabricated success.**\n- Report failures with the observed evidence (the error body, the worker\n  state, the log line). Never report a success without the artifact that\n  proves it (the output the job returned).\n- A missing credential or capability is reported as exactly that, with what\n  you did to confirm it and what the user must supply.\n\n**Use only the tools you were given.**\n- If a tool is not available in this session, work with the ones that are;\n  reads you already made can be analyzed directly. Never stall the task\n  requesting new tool access.\n\n**Report habits** (inventory, cost, deployment reports):\n- Enumerations read best as tables carrying each resource's name and id.\n- Every dollar figure comes from a billing\u002Fpricing read made this turn; give\n  totals beside per-item figures, and show empty categories rather than\n  silently dropping them.\n- Lead the user to the number or verdict they asked for.\n\n## Source & docs\n\n- Server source: https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-mcp\n- Package (npm): https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@runpod\u002Fmcp-server\n- Hosted endpoint: https:\u002F\u002Fmcp.runpod.io\u002F\n- Docs: https:\u002F\u002Fdocs.runpod.io\n",{"name":5,"license":15,"metadata":56,"description":7,"allowed-tools":71,"compatibility":72},{"author":9,"version":57,"concepts":58},"2.0.0",[59,60,61,62,63,64,65,66,67,68,69,70],"runpod-platform","pod","serverless-endpoint","job","template","network-volume","registry-credential","gpu-type","log-stream","api-key","api-rate-limit","hub-repo","Bash(claude mcp:*)","Linux, macOS, Windows","main","5a83c49e1094c3fef9ce755230b64c62e6cc7173","plugins\u002Frunpod\u002Fskills\u002Frunpod-mcp",10,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official","https:\u002F\u002Fdocs.runpod.io\u002Fagent-setup.md","https:\u002F\u002Fgithub.com\u002Frunpod","https:\u002F\u002Fwww.runpod.io","2026-11-10 06:32:38",{"source":8,"skillName":5,"commands":83,"prompt":93,"zipAvailable":94},[84,87,90],{"tool":85,"command":86},"npx","npx skills add runpod\u002Frunpod-plugins-official --skill runpod-mcp",{"tool":88,"command":89},"bunx","bunx skills add runpod\u002Frunpod-plugins-official --skill runpod-mcp",{"tool":91,"command":92},"pnpm","pnpm dlx skills add runpod\u002Frunpod-plugins-official --skill runpod-mcp","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-mcp\u002FSKILL.md",true,[96,102,106],{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"evals\u002Fwhen-to-use-mcp.eval.md","REFERENCE","参考文档",1648,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-mcp\u002Fevals\u002Fwhen-to-use-mcp.eval.md",{"path":103,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":104,"sourceHtmlUrl":105},"reference\u002Fapi-boundary.md",5302,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-mcp\u002Freference\u002Fapi-boundary.md",{"path":107,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":108,"sourceHtmlUrl":109},"reference\u002Fconnect.md",1939,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-mcp\u002Freference\u002Fconnect.md",[111,141,159,175,195,214],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":123,"publishedAt":51},"01M717A4HFW93XQC7PTXV1QFFH","runpod-vllm","Serve a Hugging Face model with vLLM on Runpod (Hub worker-vllm queue endpoint, load-balancing endpoint on a vllm\u002Fvllm-openai image, or a Pod), sized, CUDA-pinned and verified with a real OpenAI client. Use for any \"deploy\u002Fserve\u002Ftest this LLM with vLLM\" request or a vLLM deployment that will not boot; defer to runpod-serverless-deploy for non-vLLM engines and runpod-endpoint-ops for an endpoint that already works.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-vllm\u002FSKILL.md",[117,120],{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[124,9,125,41,126,127,128,46,129,130,131,132,133,134,135,136,137,138,139,140],"runpod vllm","vLLM","model","worker","image","port","request","release","network","verified","hugging face","openai","face","endpoint","availability","load-balancing","for",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":51},"01M6CFW2PPRQZ006AVQXGMWPH1","runpodctl","Runpod CLI for managing GPU\u002FCPU workloads from the terminal — pods, serverless endpoints, templates, network volumes, Hub deploys, models, SSH, and file transfer (send\u002Freceive, network-volume upload\u002Fdownload). Use for terminal\u002FCI\u002Fscripting, SSH setup, `doctor`, or when the Runpod MCP tools are not connected; prefer runpod-mcp for structured tool calls in an MCP-enabled session.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002FSKILL.md",[147],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[143,149,126,150,33,49,151,63,41,152,153,132,9,154,155,156,137,157,158,35],"doctor","ci","cli","CPU","terminal","ssh setup","Tools","macos","send","windows",{"skillNo":160,"name":9,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":165,"publishedAt":51},"01M6CFVTW32TE82Y5NA85H83CK","Start here when the Runpod lane is unclear: picks the skill for a task (runpod-mcp and the journey playbooks it routes to, such as runpod-serverless-deploy, runpod-pod-deploy, runpod-pod-doctor and runpod-cost-audit; runpodctl, runpod-flash, runpod-companion-clis, runpod-usage, runpod-templates, runpod-build-template, runpod-migrate) and indexes two dozen end-to-end worked examples (golden paths). Use it before any multi-step or provisioning task, even when the lane is clear, to check for a matching golden path; for the Runpod MCP tools, runpod-mcp owns the answer contract, connection and tool rules.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod\u002FSKILL.md",[164],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[9,33,166,63,132,167,41,168,169,170,171,172,137,37,173,155,174,143,149,35],"migrate","start","end","companion","paths","flash","golden","audit","path",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"publishedAt":51},"01M6CFVK41CSZ4HM1N7TKM3WWY","runpod-usage","Explain Runpod architecture and design choices: Pods versus Serverless, GPU\u002FVRAM, image construction, storage, networking, and workload development. For creating or improving a complete template project use runpod-build-template; execute infrastructure with runpodctl\u002Frunpod-mcp and code-first work with runpod-flash.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-usage\u002FSKILL.md",[181],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[183,9,184,143,185,186,187,33,188,128,189,190,191,192,41,140,39,193,127,194],"runpod usage","usage","development","container","design","use","code","explain","architecture","disk","complete","vram",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":202,"publishedAt":51},"01M6CFVEPPADDF61NC3MC4KCE5","runpod-templates","Find, use, and troubleshoot official Runpod Pod templates, including ComfyUI workflow model metadata repair. For creating or optimizing Dockerfiles and application template projects use runpod-build-template; deploy through runpod-mcp or runpodctl.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-templates\u002FSKILL.md",[201],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[203,204,9,143,205,206,207,126,208,33,209,128,49,63,129,210,211,212,213,140],"runpod templates","templates","projects","python3","official","inventory","workflow","scripts","troubleshoot","png","repair",{"skillNo":215,"name":216,"nameZh":6,"description":217,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":218,"categories":219,"keywords":223,"publishedAt":51},"01M6PP9W1XMN6PT4J4H0XEMTKW","runpod-serverless-deploy","Bring any source (a HuggingFace repo, a ComfyUI workflow, a Hub release, a custom container image, a GGUF repo, a Civitai asset, or a community template) to a proven Runpod Serverless endpoint: pick the engine for the modality and model format, size the GPU from the model's real metadata, provision, warm, prove it with one real job, and hand back the URL with what it bills. Deploys an existing source through the Runpod MCP tools; code-first Python deploys (the Flash dev loop) are out of scope. Use when the user wants a model or worker served on Runpod Serverless, whatever the modality: text generation, speech-to-text or text-to-speech, image or video generation, embeddings, document processing, or their own handler image. For an LLM served with vLLM (Hub worker-vllm, a vllm\u002Fvllm-openai image, or a vLLM Pod), defer to runpod-vllm.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-serverless-deploy\u002FSKILL.md",[220,221,222],{"categoryNo":118,"categoryName":119,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[224,9,225,226,227,228,229,230,41,231,232,126,233,127,33,234,235,209,128,35],"runpod serverless deploy","serverless deploy","deploy","serverless","back","Video","community","processing","scope","pick","loop","URL"]