Runpod Just Got Native in Your AI IDE

The way you build with AI is changing—and now, so is the way you interact with your infrastructure. Runpod ships an official MCP server, unlocking chat-native access to your GPU fleet from any AI-first IDE.

Drop it into Claude Code, Cursor, Codex CLI, VS Code, Windsurf, Cline, Gemini CLI, Claude Desktop, or any JetBrains IDE. If your tool speaks Model Context Protocol (MCP), it now speaks fluent Runpod.

No more context switching. No more hand-written curl commands. Just talk to your editor and your model handles the infrastructure like spinning up Pods, deploying endpoints, manage volumes, and more.

What is an MCP Server?

MCP is an open JSON‑RPC 2.0 standard that lets language model interfaces and tool providers speak the same language.

Instead of bolting together fragile glue code and one-off REST wrappers, you just define a few message types (initialize, request, result, etc.) and let the model decide what tools to invoke and when to do it. The MCP server handles the call. The client (Cursor, Claude Code, etc.) handles the UI. Your model handles the logic.

With the Runpod MCP server, that means full access to your Runpod account; directly from your editor, no context switch required.

Two servers, two jobs

Runpod actually ships two MCP servers:

• Runpod API MCP server: manage Pods, Serverless endpoints, templates, network volumes, and container registries through the Runpod REST API. Requires a Runpod API key. Published as the npm package @runpod/mcp-server.
• Runpod docs MCP server: search Runpod's documentation for features, code examples, and guides. No authentication required. Available over HTTP at https://docs.runpod.io/mcp.

The rest of this post focuses on the API server. The docs server is covered at the end.

What you can do (spoiler: almost everything)

Once the API server is connected, your assistant can reach all of the tools below. You can toggle individual tools on and off in your client, so what the model is allowed to do stays entirely within your control.

Pods

• create-pod
• list-pods
• get pod
• update-pod
• start-pod
• stop-pod
• delete-pod
• get-pod

Serverless Endpoints

• create-endpoint
• list-endpoint
• get-endpoint
• delete-endpoint
• update-endpoint

Templates

• list-template
• get-template
• create-template
• update-template
• delete-template

Endpoint jobs & runtime

• run-endpoint
• runsync-endpoint
• get-job-status
• stream-job
• cancel-job
• retry-job
• purge-endpoint-queue
• endpoint-health

Network Volumes

• list-network-volumes
• get-network-volume
• create-network-volume
• update-network-volume
• delete-network-volume

Container Registry Auth

• list-container-registry-auths
• get-container-registry-auth
• create-container-registry-auth
• delete-container-registry-auth

Discovery (read-only)

• list-gpu-types
• list-data-centers

Under the hood, the create/read/update/delete tools wrap the same REST operations you already know, while the read-only discovery tools (list-gpu-types, list-data-centers) use Runpod's public GraphQL API, so they work without write access. Your model fills in the parameters and handles validation and errors for you.

What It Feels Like in Practice

Once set up, you can talk to your AI assistant like this:

“Create a serverless endpoint using my template called jacobs-comfyui.”

Behind the scenes, your IDE routes that natural-language request to your LLM, which selects the right MCP tool (create-endpoint), fills in the parameters, and fires it off to Runpod. A few seconds later, your endpoint is live.

No terminal. No docs. Just code and chat.

Quickstart Guide

Prereqs

• Node.js 18 or higher
• A Runpod account and API key (get yours in the console)
• Any MCP-compatible client (Claude Code, Cursor, Codex CLI, VS Code, Windsurf, Cline, Gemini CLI, Claude Desktop, JetBrains, etc.)

The fastest path: run with npx

You don't have to clone or build anything. The server runs straight from npm:

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

Most clients just need this same command wired into their config. Examples follow.

Setting it up in your client

Replace YOUR_API_KEY with your actual Runpod API key in every example below.

Claude Code

Add the server globally so it's available across all your projects:

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

Or scope it to a single project (this writes a .mcp.json file you can commit):

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

Verify with claude mcp list. If you're already in a session, type /mcp to reconnect without restarting.

Codex CLI

codex mcp add runpod --env RUNPOD_API_KEY=YOUR_API_KEY -- npx -y @runpod/mcp-server@latest

Cursor

Add the following to .cursor/mcp.json in your project, or ~/.cursor/mcp.json for global access. This works with both the Cursor IDE and the Cursor Agent:

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

Windsurf, Cline, VS Code, Gemini CLI, JetBrains

These clients use the same command / args / env pattern shown above; only the location of the config file differs:

• Windsurf: ~/.codeium/windsurf/mcp_config.json
• Cline: cline_mcp_settings.json (open via the MCP Servers panel in the Cline sidebar)
• VS Code (Copilot agent mode, 1.101+): .vscode/mcp.json, or run MCP: Add Server → stdio from the Command Palette
• Gemini CLI: ~/.gemini/settings.json (global) or .gemini/settings.json (project)
• JetBrains: ~/.junie/mcp.json (global) or .junie/mcp/ in your project

What it feels like in practice

Once connected, you can talk to your assistant in plain language:

"Create a Serverless endpoint from my template 30zmvf89kd, named image-gen, scaling from 0 to 5 workers."

Behind the scenes, your client routes that request to the model, which selects the right tool (create-endpoint), fills in the parameters, and calls Runpod. A few seconds later, your endpoint is live.

A few more things you can just ask for:

"Which secure-cloud GPUs have at least 48 GB of VRAM right now?" → list-gpu-types

"Spin up a single RTX 4090 Pod running the PyTorch image and give me the Pod ID." → create-pod

"Run my endpoint with this input, then stream the job output back to me." → run-endpoint + stream-job

Bonus: the docs MCP server

Want your assistant to answer Runpod questions accurately instead of guessing? Add the docs server. It's read-only, needs no API key, and uses HTTP transport.

Claude Code:

claude mcp add runpod-docs --scope user --transport http https://docs.runpod.io/mcp

Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "runpod-docs": {
      "url": "https://docs.runpod.io/mcp"
    }
  }
}

A note on security

Your Runpod API key grants full access to your account. Never share it. Consider creating a separate, limited-permission key for MCP use, be deliberate about which tools you leave enabled, and don't wire this into a production environment without appropriate safeguards.

Why We Built This

We’re big believers in developer flow. The future of infrastructure isn’t menus and dashboards. It’s context-aware, assistant-driven, and conversational. By building Runpod’s MCP server, we’re making it feel native to every AI-first editor you already use.

Try it out, and let us know what you'd like us to build next.

👉 GitHub Repo

‍

Related posts

• Mixture of Experts (MoE): A Scalable AI Training Architecture
• How to Fine-Tune LLMs with Axolotl on Runpod
• The RTX 5090 Is Here: Serve 65,000+ Tokens Per Second on Runpod
• Cost-Effective AI with Autoscaling on Runpod
• The Future of AI Training: Are GPUs Enough?
• Built on Runpod: How Cogito Trained Models Toward ASI

Author profile: Jacob Wright