RunPod MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RUNPOD_API_KEY | Yes | Your Runpod API key (get your API key at https://www.runpod.io/console/user/settings) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list-gpu-typesD | – |
| list-data-centersD | – |
| list-podsD | – |
| get-podD | – |
| create-podA | Create a new GPU/CPU pod on RunPod. If the user does not specify an image, recommend the "Runpod Pytorch 2.8.0" image (runpod/pytorch:1.0.2-cu1281-torch280-ubuntu2404) as the default — it has the most up-to-date CUDA and PyTorch versions. |
| update-podD | – |
| start-podD | – |
| stop-podD | – |
| delete-podD | – |
| list-endpointsD | – |
| get-endpointD | – |
| create-endpointD | – |
| update-endpointD | – |
| delete-endpointD | – |
| run-endpointA | Submit an asynchronous job to a Serverless endpoint. Returns a job ID immediately — use get-job-status to poll for results. Async results are available for 30 minutes after completion. |
| runsync-endpointA | Submit a synchronous job to a Serverless endpoint and wait for the result. Best for tasks completing within 90 seconds. If processing exceeds 90 seconds, the response returns a job ID to poll with get-job-status. Max payload: 20 MB. Results expire after 1 minute. Use the wait parameter to extend the server-side wait up to 5 minutes (300000 ms). |
| get-job-statusA | Check the status of an asynchronous Serverless job. Returns the current status and output when complete. Job statuses: IN_QUEUE, IN_PROGRESS, COMPLETED, FAILED, CANCELLED, TIMED_OUT. |
| stream-jobA | Retrieve all streaming output from a Serverless job by polling until the job reaches a terminal state. The worker must support streaming output. Polls /stream/{jobId} repeatedly and collects every chunk until status is COMPLETED, FAILED, CANCELLED, or TIMED_OUT. |
| cancel-jobA | Cancel a Serverless job that is queued or in progress. |
| retry-jobA | Retry a failed or timed-out Serverless job. Only works for jobs with FAILED or TIMED_OUT status. The previous output is removed and the job is requeued. |
| endpoint-healthA | Get the health and operational status of a Serverless endpoint, including worker counts and job statistics. |
| purge-endpoint-queueA | Remove all pending jobs from a Serverless endpoint queue. Only affects queued jobs — in-progress jobs continue running. Use this for error recovery or clearing outdated requests. |
| list-templatesA | List available templates. By default returns only the user's own templates. Use includeRunpodTemplates to also include official RunPod templates. The recommended default template for new pods is "Runpod Pytorch 2.8.0" (ID: runpod-torch-v280) — it has the latest CUDA and PyTorch versions. |
| get-templateD | – |
| create-templateD | – |
| update-templateD | – |
| delete-templateD | – |
| list-network-volumesD | – |
| get-network-volumeD | – |
| create-network-volumeD | – |
| update-network-volumeD | – |
| delete-network-volumeD | – |
| list-container-registry-authsD | – |
| get-container-registry-authD | – |
| create-container-registry-authD | – |
| delete-container-registry-authD | – |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 36 tools
Most tools are distinct resource+action pairs (pods, endpoints, templates, volumes, registry auths), but run-endpoint vs runsync-endpoint and get-job-status vs stream-job overlap enough to cause confusion. Many tools have no descriptions, so the boundaries between similar operations are not clearly reinforced.
The set mostly follows a lowercase hyphenated verb_noun pattern like list-pods and create-endpoint, which is predictable. However, runsync-endpoint is an awkward compound, endpoint-health breaks the verb-first pattern, and singular/plural naming is inconsistent for container registry auths.
At 36 tools, this is a heavy surface that will feel overwhelming for an agent, especially with several overlapping job-related operations. It exceeds the 25+ threshold and would benefit from consolidation or clearer grouping.
The tool surface covers full CRUD for pods, endpoints, templates, volumes, and registry auths, plus pod lifecycle and serverless job operations. There are no obvious dead ends that would prevent a typical workflow from being completed.