Manage Your Runpod Infrastructure From Any AI Assistant: Introducing the Runpod MCP Server

Today we're releasing the Runpod MCP server, an open-source Model Context Protocol server that connects Runpod to Claude Code, Claude Desktop, Cursor, Windsurf, VS Code, and any other MCP-compatible client. Once connected, your assistant can create and manage Pods, deploy Serverless endpoints, submit and monitor jobs, browse GPU availability and pricing, and pull up your spend history, all through plain conversation.

What is MCP, and why should you care?

The Model Context Protocol is an open standard that lets AI assistants call external tools in a structured way. Instead of your assistant telling you which API call to make, it makes the call with your API key on your account, and reports back the result.

For Runpod users, this closes a gap in the everyday workflow. You're already in your editor with an AI assistant when you realize you need an A100 with a network volume attached, or you want to know why your Serverless endpoint's queue is backing up. Previously that meant a context switch to the console or the CLI. Now it's one sentence in the chat you already have open.

Getting started in 60 seconds

You'll need Node.js 18+ and a Runpod API key. First, install Nodesource (the default Ubuntu template doesn’t come with this, others might)

apt-get update && apt-get install -y curl
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt-get install -y nodejs
node -v && npx -v

Then install the MCP server:

RUNPOD_API_KEY=YOUR_KEY_HERE npx @runpod/mcp-server@latest

Claude Code

One command adds it globally across all your projects:

claude mcp add runpod -s user \
  -e RUNPOD_API_KEY=rpa_HUGBF3LA4M5L9X5FHEH3EE4W8FVX53BY8TK5M67Q1ih1yn \
  -- npx -y @runpod/mcp-server@latest

Prefer per-project setup? Use -s project instead to generate a .mcp.json you can commit (minus the key, please). Verify with claude mcp list, or type /mcp in an active session to reconnect without restarting.

Claude Desktop, Cursor, Windsurf, VS Code, and friends

Every major MCP client uses the same JSON configuration shape. For Claude Desktop, edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "runpod": {
      "command": "npx",
      "args": ["-y", "@runpod/mcp-server@latest"],
      "env": {
        "RUNPOD_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

‍

The same block works in Cursor (.cursor/mcp.json), Windsurf (~/.codeium/windsurf/mcp_config.json), VS Code agent mode (.vscode/mcp.json), Cline, and JetBrains IDEs. The server uses stdio transport, so it works with anything on the official MCP clients list. Full per-client instructions are in the README.

Running it inside a Pod

Normally the MCP server runs on your local machine next to your assistant, and the pod never needs Node at all. But a popular workflow is running Claude Code inside a pod. You can SSH in, develop where the GPU lives, and Runpod images like the default PyTorch image don't ship with Node.js. Installing it takes a minute:

curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt-get install -y nodejs

That gives you node, npm, and npx system-wide, and the claude mcp add runpod ... command from above works exactly as on your laptop. If you want Node to survive pod restarts, install it via nvm onto your network volume instead:

curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | NVM_DIR=/workspace/.nvm bash
export NVM_DIR=/workspace/.nvm && . "$NVM_DIR/nvm.sh"
nvm install 22

Since /workspace lives on the persistent volume, your Node install (and anything you put on the volume) is there the next time the pod starts up. Just re-source nvm in your shell profile.

What can it actually do?

The server exposes roughly fifty tools organized around the resources you already know: Pods, Serverless endpoints and jobs, templates, network volumes, container registry credentials, tags, billing, and a discovery catalog of GPU types, CPU types, and data centers. Rather than list them all, here's what they look like in practice.

Spin up a Pod without leaving your editor

You: What GPU types have at least 48 GB of VRAM available in Secure Cloud right now, and what do they cost?

The assistant calls list-gpu-types with a minimum-VRAM filter and comes back with live stock and pricing. Then:

You: Create a pod called finetune-01 on an A6000 with the default PyTorch image, a 100 GB volume mounted at /workspace, and expose port 8888 for Jupyter.

Behind the scenes that's a single create-pod call:

create-pod
  name: "finetune-01"
  imageName: "runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404"
  gpuTypeIds: ["NVIDIA RTX A6000"]
  cloudType: "SECURE"
  volumeInGb: 100
  volumeMountPath: "/workspace"
  ports: ["8888/http"]

A detail we're proud of: the server refuses to guess your intent. If you ask for a pod without specifying GPU types, it won't silently fall back to a CPU pod as it returns a clear error pointing you to list-gpu-types. Discovery tools exist precisely so the assistant can look up valid IDs instead of hallucinating them.

From there, start-pod, stop-pod, restart-pod, update-pod, and get-pod cover the full lifecycle. When you're done: "stop finetune-01, and delete it if the volume is detached."

Deploy and exercise a Serverless endpoint

You: Deploy a Serverless endpoint named whisper-prod from image myorg/whisper-worker:v3 on 24 GB Ada GPUs, scaling from 0 to 3 workers.

That maps to create-endpoint with an inline config , including an image name, a GPU pool from the catalog (for example ADA_24), and worker bounds. Min workers of 0 means it scales to zero and you pay nothing while idle.

Then test it in the same conversation:

You: Send it a sync request with this audio URL and show me the transcription.

The assistant uses runsync-endpoint for quick jobs (it waits up to 90 seconds server-side, extendable to 5 minutes) or run-endpoint for async work, polling get-job-status until the result lands. There's also stream-job for workers that emit streaming output, cancel-job and retry-job for lifecycle control, and purge-endpoint-queue when you need to clear a backlog of stale requests without touching in-flight work.

Operational visibility comes along too: endpoint-health reports worker counts and job statistics, list-endpoint-workers shows the individual workers backing an endpoint, and list-endpoint-releases shows rollout history, which can be handy for a quick "did my new image finish rolling out?" check.

Debug with logs and health checks

You: My endpoint seems slow. What's going on?

A good assistant will chain endpoint-health (queue depth, worker states) with list-endpoint-workers and suggest a fix like bumping max workers via update-endpoint. For Pods, log access is built in: the server parses the server-sent-events log stream from the API into structured entries, so "show me the last logs from finetune-01" just works.

Keep an eye on spend

You: How much have I spent on Serverless this week versus Pods?

The get-billing tool returns time-bucketed spend history, either aggregated or broken down by resource type (e.g. pods, serverless, endpoints, network volumes.)

Everything else

Templates (create-template through delete-template) let you codify reusable pod and endpoint configurations. Network volumes get full CRUD for persistent storage that outlives any single pod. Container registry auth tools store credentials for private images. And tags give you a lightweight way to organize resources.

Built with agents in mind

A few design choices worth calling out: 

Tool annotations: Every tool declares whether it's read-only, a write, or destructive, using MCP's standard annotation hints. Clients that respect these can auto-approve reads while requiring confirmation before a destructive change like a delete-endpoint.

Pagination everywhere: List tools accept limit and cursor parameters and cap result sizes, so a large account doesn't blow out your assistant's context window.

Clear API-version handling: The server speaks both the soon to be released v2 REST API and v1 where needed, routing each resource to the right backend and telling you plainly when a tool isn't available on your API version rather than failing cryptically.

Descriptive schemas: Every parameter carries a description, which is what lets models fill in arguments correctly without you memorizing the API reference.

A word on security

The server authenticates with your Runpod API key, which grants full access to your account,  and MCP means an AI model is now making calls with it. Some practical advice: never commit your key, consider a dedicated key with limited permissions for MCP use, keep confirmation prompts enabled for destructive operations in your client, and don't wire this into production automation without proper controls. Treat your assistant like a very fast new teammate: capable, but you still review before it deletes things.

Try it, fork it, extend it

The server is open source under Apache-2.0 at github.com/runpod/runpod-mcp. The codebase is approachable TypeScript: tools are organized per resource, defined with Zod schemas, and the contributing guide walks you through adding your own. If there's a workflow you want that isn't covered, issues and pull requests are open.

Connect it to your assistant of choice and ask it something you'd normally open the console for. We think you'll find it hard to go back.

Get your API key in the Runpod console and get started with npx @runpod/mcp-server@latest.

‍

‍

‍