What can you do with this server?

The server lets MCP clients manage RunPod cloud resources—pods, serverless endpoints, templates, network volumes, and registry auths—and run serverless jobs. * Pods: list, get, create, update, start, stop, and delete GPU/CPU pods * GPU/data centers: list and filter GPU types and data centers * Serverless endpoints: create, update, delete, list, and get endpoints; check health; purge queues * Serverless jobs: run async or sync jobs, stream output, check status, cancel, and retry jobs * Templates: list, get, create, update, and delete serverless/pod templates * Network volumes: list, get, create, update, and delete network volumes * Container registry auths: list, get, create, and delete registry credentials * Hosted-only extras: report feedback, ask questions, and read/write the calling account's own journal (ALP tools), plus RunPod task playbooks as MCP resources

Which integrations are available for this server?

Serves as the runtime environment for the MCP server, required for installation and operation. Supports management of RunPod resources with NVIDIA GPUs, including creating and configuring pods with specific NVIDIA GPU types and counts. Enables deployment of pods with PyTorch images, allowing users to specify PyTorch-based container environments. Provides tools for managing RunPod serverless endpoints, including creation, configuration, and scaling of serverless deployments. Supports deployment of pods with Ubuntu-based images, enabling users to specify Ubuntu versions in their container environments.

How do I use RunPod MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RunPod MCP Server list all my pods" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

RunPod MCP Server

Official

by runpod

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Runpod MCP server

The official Runpod Model Context Protocol (MCP) server. It lets MCP clients such as Claude Code, Claude Desktop, Cursor, Windsurf, and VS Code manage your Runpod Pods, Serverless endpoints, templates, network volumes, and more.

We host it for you at https://mcp.getrunpod.io/ — point your client at that URL and sign in with Runpod. Nothing to install, no API key on disk. Or run it locally from npm as @runpod/mcp-server.

Quick start

The guided installer detects the clients you have installed, asks which to configure, and writes the config for you:

npx @runpod/mcp-server@latest add

It offers two connection modes:

Hosted (recommended) — points the client at the hosted server and authenticates with "Sign in with Runpod" (OAuth). No API key is stored on disk.
Local — runs the server through npx and stores a RUNPOD_API_KEY in the client's config.

To undo later:

npx @runpod/mcp-server@latest remove

Or install the whole Runpod plugin

For the full agent setup, the official plugin marketplace bundles this server with a router skill plus five more — runpod-mcp, runpodctl, flash, runpod-usage, and companion-clis:

npx skills add runpod/runpod-plugins-official

That works in Claude Code, Codex, Cursor, Copilot, Windsurf, Cline, Gemini, opencode, and 17+ other agents, and installs the skills — pair it with npx @runpod/mcp-server@latest add above for the control-plane tools.

In Claude Code, the native plugin route also wires up the hosted MCP server for you (OAuth included), so no separate setup is needed:

/plugin marketplace add runpod/runpod-plugins-official
/plugin install runpod@runpod

Requirements

Node.js 20 or higher.
A Runpod account and API key.

Related MCP server: RunPod MCP Server

Connect to the hosted server

To configure a client by hand, point it at the hosted server over HTTP (no local process, no API key stored).

Claude Code:

claude mcp add --transport http runpod -s user https://mcp.getrunpod.io/

Other clients (Cursor, VS Code, Claude Desktop connectors, …) — use a URL-based MCP entry:

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

An OAuth-capable client starts the "Sign in with Runpod" flow automatically on first connect: it opens a browser, you log in to the Runpod console and approve, and the server obtains a Runpod API key scoped to your session. Nothing is stored on disk.

Which account does OAuth pick? The key is minted for whichever account or team profile your browser's console session has selected when you approve. If you belong to multiple teams, switch to the right profile in the console first (or check afterwards — the resources the tools return are that profile's). To change it later, switch profiles in the console and re-authenticate from your MCP client.

Prefer your own API key over OAuth? Append --header "Authorization: Bearer YOUR_API_KEY" to the claude mcp add command (or add a headers block in the JSON). The server forwards that key to the Runpod API directly.

Usage analytics

The hosted server records one anonymous event per tool call (tool name, status, duration, transport — never your API key, arguments, or any resource data; your identity is an irreversible salted hash). To opt out, send the header X-Runpod-Analytics: off — e.g. append --header "X-Runpod-Analytics: off" to the claude mcp add command. Running locally, nothing is ever sent.

Run locally with `npx`

Run the server as a local stdio process with your own API key:

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

Local client setup

Local clients launch the stdio server and set RUNPOD_API_KEY in the environment.

Claude Code:

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

Use -s project for a project-local server. Verify with claude mcp list; in a session, /mcp reconnects.

Claude Desktop, Cursor, VS Code, Windsurf, and other clients — use the same command in the client's MCP config:

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

Claude Desktop's config lives at ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows); restart the app after saving. For a broader list of clients, see the MCP clients directory.

Usage examples

Ask your MCP client in natural language:

List all my Runpod Pods.

Create a Runpod Pod named test-pod with image
runpod/pytorch:2.1.0-py3.10-cuda11.8.0-devel-ubuntu22.04,
GPU type NVIDIA GeForce RTX 4090, 1 GPU.

Create a Serverless endpoint named my-endpoint with image
runpod/test-output:0.0.1, GPU pool AMPERE_80, 0 min workers, 3 max workers.

Endpoints are image-based — pass an image and a GPU pool (a pool value from list-gpu-types), not a template.

See docs/configuration.md for host overrides, private image pull (registry credentials vs ECR delegation), and large-output handling.

The tool surface

Hosted and local serve the same surface, with one deliberate exception: 68 tools (51 generated from the v2 OpenAPI spec + 17 curated) on both, plus the four hosted-only ALP tools — report_feedback, save_to_journal, ask_question, and read_journal, which returns the calling account's own journal and nobody else's — for 72 hosted. Those four need storage credentials the npm package cannot hold, so local stdio never registers them and they are simply absent from tools/list (see docs/agent-learning-protocol.md). Both transports also serve the ten Runpod task playbooks as MCP resources under runpod://skills/. New API endpoints become tools by regeneration, not by hand-writing code. Start with specgen/DESIGN.md for a progressive walkthrough, and specgen/README.md for the regeneration workflow and drift gates.

Upgrading from 3.x: eight tools follow their spec operationIds (e.g. create-container-registry-auth → create-registry, get-billing → list-billing) and start-pod/stop-pod/restart-pod fold into pod-action with an action argument. The full old→new map is specgen/old-mcp-tools.yaml. The server is v2-only; RUNPOD_REST_VERSION and the v1 fallback are retired.

Security

This server acts with the full permissions of the supplied API key.

Never share your API key.
Be deliberate with destructive tools.
Each request authenticates with its own caller-supplied token, which is forwarded to the Runpod API and never persisted server-side. The server never holds a credential of its own and never shares one across users.

Local development

git clone https://github.com/runpod/runpod-mcp.git
cd runpod-mcp
pnpm install
pnpm build

Run the local build directly:

RUNPOD_API_KEY=YOUR_API_KEY node dist/stdio.mjs

After changes:

pnpm type-check
pnpm lint
pnpm test    # offline unit suite — no network or API key required
pnpm build

This project uses changesets for versioning and npm publishing; every PR with user-facing changes needs a changeset. See CLAUDE.md and docs/context.md for full contributor guidance, architecture, and the test suite.

License

Apache-2.0

JavaScript API migration

This major release removes the @runpod/mcp-server/tools package export and its registerTools API. The legacy registration API is not compatible with the new generated surface. Applications should connect to the server through MCP using the runpod-mcp CLI, or use handleMcpRequest from @runpod/mcp-server/http when embedding the HTTP handler. The HTTP entry point also no longer re-exports the legacy registerTools or ToolContext.

Available Tools

36 tools

cancel-jobA

Cancel a Serverless job that is queued or in progress.

ParametersJSON Schema

Name	Required	Description	Default
`endpointId`	Yes	ID of the Serverless endpoint the job belongs to
`jobId`	Yes	ID of the job to cancel

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It states the action but does not describe consequences (e.g., irreversibility), required permissions, or what happens to the job after cancellation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence (10 words) that front-loads the purpose with no extraneous information, achieving ideal conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter tool with no output schema, the description covers the precondition but omits expected return value or confirmation behavior, leaving it partially incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing baseline clarity. The description does not add additional meaning beyond the schema's property descriptions, so no extra value is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (cancel) and resource (Serverless job) and adds a condition (queued or in progress), making it distinct from sibling tools like retry-job or delete-endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage only for jobs that are queued or in progress, but does not explicitly state when not to use it or mention alternatives such as retry-job or purge-endpoint-queue.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-container-registry-authD

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name for the container registry auth
`username`	Yes	Registry username
`password`	Yes	Registry password

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-endpointD

ParametersJSON Schema

Name	Required	Description
`name`	No	Name for the endpoint
`templateId`	Yes	Template ID to use
`computeType`	No	GPU or CPU endpoint
`gpuTypeIds`	No	List of acceptable GPU types
`gpuCount`	No	Number of GPUs per worker
`workersMin`	No	Minimum number of workers
`workersMax`	No	Maximum number of workers
`dataCenterIds`	No	List of data centers

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-network-volumeD

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name for the network volume
`size`	Yes	Size in GB (1-4000)
`dataCenterId`	Yes	Data center ID

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description
`name`	No	Name for the pod
`imageName`	Yes	Docker image to use
`cloudType`	No	SECURE or COMMUNITY cloud
`gpuTypeIds`	No	List of acceptable GPU types
`gpuCount`	No	Number of GPUs
`containerDiskInGb`	No	Container disk size in GB
`volumeInGb`	No	Volume size in GB
`volumeMountPath`	No	Path to mount the volume
`ports`	No	Ports to expose (e.g., '8888/http', '22/tcp')
`env`	No	Environment variables
`dataCenterIds`	No	List of data centers

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only offers a default image recommendation, lacking details on permissions, costs, failure modes, or idempotency for this mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose. Efficient but could include more substantive information without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters and no output schema, the description is insufficient. It omits details on return values, error handling, default behaviors, and parameter interactions, making it incomplete for a complex creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all parameters, providing baseline meaning. The description adds value by recommending a specific default Docker image beyond the schema's description for 'imageName', offering practical guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and resource 'new GPU/CPU pod on RunPod', which is specific and distinct from sibling tools like 'cancel-job' or 'create-endpoint'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. While sibling tools differ in resource, no direct usage context or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-templateD

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name for the template
`imageName`	Yes	Docker image to use
`isServerless`	No	Is this a serverless template
`ports`	No	Ports to expose
`dockerEntrypoint`	No	Docker entrypoint commands
`dockerStartCmd`	No	Docker start commands
`env`	No	Environment variables
`containerDiskInGb`	No	Container disk size in GB
`volumeInGb`	No	Volume size in GB
`volumeMountPath`	No	Path to mount the volume
`readme`	No	README content in markdown format

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete-container-registry-authD

ParametersJSON Schema

Name	Required	Description	Default
`containerRegistryAuthId`	Yes	ID of the container registry auth to delete

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete-endpointD

ParametersJSON Schema

Name	Required	Description	Default
`endpointId`	Yes	ID of the endpoint to delete

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete-network-volumeD

ParametersJSON Schema

Name	Required	Description	Default
`networkVolumeId`	Yes	ID of the network volume to delete

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete-podD

ParametersJSON Schema

Name	Required	Description	Default
`podId`	Yes	ID of the pod to delete

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete-templateD

ParametersJSON Schema

Name	Required	Description	Default
`templateId`	Yes	ID of the template to delete

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

endpoint-healthA

Get the health and operational status of a Serverless endpoint, including worker counts and job statistics.

ParametersJSON Schema

Name	Required	Description	Default
`endpointId`	Yes	ID of the Serverless endpoint to check health for

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool returns health status, worker counts, and job statistics, but does not clarify if the operation is read-only (implied), any potential side effects, authentication requirements, rate limits, or data freshness. The description covers basic behavioral output but omits important operational constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly states the tool's purpose and key outputs. It contains no redundant or ambiguous language, but could benefit from structuring the included elements (worker counts, job statistics) for easier scanning. Overall, it is efficient and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple health-check tool with one parameter and no output schema, the description adequately specifies the returned information (health status, worker counts, job statistics). However, it lacks completeness in behavioral transparency and usage context, leaving minor gaps especially given the absence of annotations or output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage with a clear field description ('ID of the Serverless endpoint to check health for'). The tool description does not add further parameter details beyond what the schema already provides, functioning at the baseline for schema-rich definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves health and operational status of a Serverless endpoint, including specific details like worker counts and job statistics. This verb-resource combination (Get + health) effectively distinguishes it from related sibling tools like get-endpoint which likely provides general endpoint information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used to check endpoint health but provides no explicit guidance on when to use it versus alternatives (e.g., get-endpoint), nor any prerequisites or caveats. No exclusion criteria or alternative suggestions are given, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-container-registry-authD

ParametersJSON Schema

Name	Required	Description	Default
`containerRegistryAuthId`	Yes	ID of the container registry auth to retrieve

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-endpointD

ParametersJSON Schema

Name	Required	Description
`endpointId`	Yes	ID of the endpoint to retrieve
`includeTemplate`	No	Include template information
`includeWorkers`	No	Include information about workers

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`endpointId`	Yes	ID of the Serverless endpoint the job belongs to
`jobId`	Yes	ID of the job to check

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It correctly identifies this as a read operation (check status, return output) and lists possible statuses, providing sufficient behavioral context. However, it does not mention rate limits or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences covering purpose, return value, and status list. Every sentence is informative with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with full schema coverage and no output schema, the description fully explains what the tool does and what it returns. No gaps are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both jobId and endpointId described. The description adds no extra parameter detail beyond the schema, so baseline 3 is appropriate given the small parameter count.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'check', the resource 'status of an asynchronous Serverless job', and specifies that it returns current status and output when complete. It effectively distinguishes from sibling tools like 'cancel-job' and 'retry-job'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking job status but lacks explicit guidance on when to use this tool versus alternatives. No when-not scenarios or alternative tool mentions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-network-volumeD

ParametersJSON Schema

Name	Required	Description	Default
`networkVolumeId`	Yes	ID of the network volume to retrieve

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-podD

ParametersJSON Schema

Name	Required	Description
`podId`	Yes	ID of the pod to retrieve
`includeMachine`	No	Include information about the machine
`includeNetworkVolume`	No	Include information about attached network volumes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-templateD

ParametersJSON Schema

Name	Required	Description	Default
`templateId`	Yes	ID of the template to retrieve

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-container-registry-authsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-data-centersD

ParametersJSON Schema

Name	Required	Description	Default
`region`	No	Filter by region/location (e.g., 'United States', 'Europe', 'Canada')

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-endpointsD

ParametersJSON Schema

Name	Required	Description	Default
`includeTemplate`	No	Include template information
`includeWorkers`	No	Include information about workers

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-gpu-typesD

ParametersJSON Schema

Name	Required	Description
`minMemoryGb`	No	Filter to GPUs with at least this much VRAM in GB
`secureCloudOnly`	No	Filter to only GPUs available in secure cloud
`communityCloudOnly`	No	Filter to only GPUs available in community cloud
`searchTerm`	No	Search term to filter GPUs by name (e.g., 'A100', 'RTX 4090')
`includeUnavailable`	No	Include GPUs that are currently out of stock. Default is false

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-network-volumesD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-podsD

ParametersJSON Schema

Name	Required	Description
`computeType`	No	Filter to only GPU or only CPU Pods
`gpuTypeId`	No	Filter to Pods with any of the listed GPU types
`dataCenterId`	No	Filter to Pods in any of the provided data centers
`name`	No	Filter to Pods with the provided name
`includeMachine`	No	Include information about the machine
`includeNetworkVolume`	No	Include information about attached network volumes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description
`includeRunpodTemplates`	No	Include official RunPod templates in the response
`includePublicTemplates`	No	Include community-made public templates in the response
`includeEndpointBoundTemplates`	No	Include templates bound to Serverless endpoints in the response

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses default filtering and the effect of one parameter. Recommends a specific template ID. However, with no annotations, it does not cover rate limits, authentication needs, or edge cases like empty results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no redundancy. Front-loaded with main action, then provides important defaults and recommendations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simplicity (three booleans, no output schema), description covers defaults and a concrete recommendation. Could mention return format (list of template objects) but not required for agent to use tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds context for includeRunpodTemplates but not for the other two parameters; their schema descriptions are already clear and match the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists available templates, specifies default behavior (user's own templates) and flags to expand scope. It distinguishes from sibling tools like create-template, delete-template, get-template.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear guidance on when to use includeRunpodTemplates to include official templates. Lacks explicit when-not-to-use or comparisons with other list tools, but context is sufficient for correct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`endpointId`	Yes	ID of the Serverless endpoint to purge the queue for

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that only queued jobs are affected and in-progress jobs continue, which is the key behavioral trait. It could mention reversibility or permissions but is sufficient for a simple action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the action, and contains no superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required param, no output schema), the description covers the essential context. It could mention the expected response or lack of undo, but it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter endpointId, which is fully described in the schema. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool removes all pending jobs from a Serverless endpoint queue, and explicitly distinguishes between queued and in-progress jobs, avoiding ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It specifies use cases: error recovery or clearing outdated requests. It does not explicitly mention when not to use it or compare to sibling tools like cancel-job, but the purpose is clear enough for agent selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`endpointId`	Yes	ID of the Serverless endpoint the job belongs to
`jobId`	Yes	ID of the job to retry

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description discloses that previous output is removed and job is requeued. Adds behavioral context beyond schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no fluff, front-loaded with purpose and condition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description covers preconditions and effect. Lacks return value info, but overall adequate for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 100% with descriptions for both parameters. Description does not add substantial meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Retry', resource 'Serverless job', and conditions 'failed or timed-out'. Differentiates from sibling tools like cancel-job.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly notes only works for FAILED or TIMED_OUT status, providing clear usage context. Could mention alternatives for other statuses, but still strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description
`endpointId`	Yes	ID of the Serverless endpoint to run
`input`	Yes	Input payload for the worker handler. The expected fields depend on the deployed model or worker.
`webhook`	No	Webhook URL to receive job completion notifications instead of polling
`policy`	No	Execution policy options
`s3Config`	No	S3-compatible storage config for large outputs

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the job is asynchronous, returns a job ID, and results expire in 30 minutes. Missing details include error handling, authentication requirements, rate limits, and behavior on invalid endpoint IDs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two sentences that front-load the primary action and return behavior. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, nested objects, and no output schema, the description misses important context. It does not mention polling alternatives like webhook (though present in schema), nor S3 config for large outputs. The 30-minute result expiry is helpful, but overall incomplete for a moderately complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are already described in the schema. The tool description adds no further meaning about parameters like input, policy, webhook, or s3Config, resulting in baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool submits an asynchronous job to a Serverless endpoint, returns a job ID immediately, and directs to use get-job-status for polling. It distinguishes itself from the synchronous sibling runsync-endpoint and the polling-focused get-job-status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when to use (async jobs) and mentions polling via get-job-status. However, it does not explicitly state when not to use it, nor does it mention alternatives like runsync-endpoint or webhook-based notification, though the webhook parameter is present in the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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).

ParametersJSON Schema

Name	Required	Description
`endpointId`	Yes	ID of the Serverless endpoint to run synchronously
`input`	Yes	Input payload for the worker handler. The expected fields depend on the deployed model or worker.
`wait`	No	How long in milliseconds the server should wait for a result before returning a job ID to poll (1000–300000). Defaults to 90000 (90 seconds).
`webhook`	No	Webhook URL to receive job completion notifications instead of polling
`policy`	No	Execution policy options
`s3Config`	No	S3-compatible storage config for large outputs

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavioral traits. It covers synchronous wait, timeout behavior, fallback to polling, max payload (20 MB), result expiration (1 minute), and the ability to extend wait via parameter. It lacks details on error handling, permissions, or idempotency, but the key behaviors are well communicated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-structured paragraph of four sentences, front-loading the main purpose. Each sentence adds value: purpose, timing constraints, fallback mechanism, and parameter usage. It is concise with no wasted words, though bullet points could improve scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, nested objects, no output schema), the description adequately explains the high-level behavior, response types (result vs. job ID), and key constraints. It covers the main aspects needed for an agent to select and invoke the tool, though it omits error handling details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining the overall timing behavior and how the wait parameter affects server-side waiting. It also places parameters like endpointId and input in the context of a synchronous job submission.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair ('Submit a synchronous job to a Serverless endpoint') and clearly distinguishes itself by stating 'Best for tasks completing within 90 seconds' and explaining the fallback to polling, which differentiates it from asynchronous alternatives like run-endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (tasks completing within 90 seconds) and explains the behavior for longer tasks (returns job ID to poll). It mentions the wait parameter to extend server-side wait but does not explicitly exclude other tools or provide when-not-to-use guidance relative to siblings like run-endpoint.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start-podD

ParametersJSON Schema

Name	Required	Description	Default
`podId`	Yes	ID of the pod to start

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

stop-podD

ParametersJSON Schema

Name	Required	Description	Default
`podId`	Yes	ID of the pod to stop

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`endpointId`	Yes	ID of the Serverless endpoint the job belongs to
`jobId`	Yes	ID of the job to stream results from

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Clearly explains polling behavior, endpoint pattern, terminal states, and that it collects every chunk. Could mention rate limits or timeouts but sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with main action, no wasted words. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description explains it collects chunks. Could be more explicit about return format (e.g., concatenated output or array), but reasonable for a polling tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with 100% coverage. Description adds value by explaining polling endpoint pattern and that jobId is used in the stream endpoint, reinforcing purpose beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it retrieves all streaming output from a Serverless job by polling, specifying the resource (Serverless job) and action (retrieve streaming output via polling). Distinguishes from siblings like get-job-status (which gives current status) and cancel-job.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context that the worker must support streaming output, indicating when to use. However, lacks explicit when-not-to-use or alternative tool guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update-endpointD

ParametersJSON Schema

Name	Required	Description
`endpointId`	Yes	ID of the endpoint to update
`name`	No	New name for the endpoint
`workersMin`	No	New minimum number of workers
`workersMax`	No	New maximum number of workers
`idleTimeout`	No	New idle timeout in seconds
`scalerType`	No	Scaler type
`scalerValue`	No	Scaler value

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update-network-volumeD

ParametersJSON Schema

Name	Required	Description
`networkVolumeId`	Yes	ID of the network volume to update
`name`	No	New name for the network volume
`size`	No	New size in GB (must be larger than current)

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update-podD

ParametersJSON Schema

Name	Required	Description
`podId`	Yes	ID of the pod to update
`name`	No	New name for the pod
`imageName`	No	New Docker image
`containerDiskInGb`	No	New container disk size in GB
`volumeInGb`	No	New volume size in GB
`volumeMountPath`	No	New path to mount the volume
`ports`	No	New ports to expose
`env`	No	New environment variables

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update-templateD

ParametersJSON Schema

Name	Required	Description
`templateId`	Yes	ID of the template to update
`name`	No	New name for the template
`imageName`	No	New Docker image
`ports`	No	New ports to expose
`env`	No	New environment variables
`readme`	No	New README content in markdown format

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesv1.1.0Apr 30, 2026
- Addedcancel-job
- Addedendpoint-health
- Addedget-job-status
- Addedlist-data-centers
- Addedlist-gpu-types
- Changedlist-templates3 fields changed
  - addedInput schema / properties / includeEndpointBoundTemplates
```
Added value: +{
+  "description": "Include templates bound to Serverless endpoints in the response",
+  "type": "boolean"
+}
```
  - addedInput schema / properties / includePublicTemplates
```
Added value: +{
+  "description": "Include community-made public templates in the response",
+  "type": "boolean"
+}
```
  - addedInput schema / properties / includeRunpodTemplates
```
Added value: +{
+  "description": "Include official RunPod templates in the response",
+  "type": "boolean"
+}
```
- Addedpurge-endpoint-queue
- Addedretry-job
- Addedrun-endpoint
- Addedrunsync-endpoint
- Addedstream-job
26 tool updatesDec 10, 2025
- First observedcreate-container-registry-auth
- First observedcreate-endpoint
- First observedcreate-network-volume
- First observedcreate-pod
- First observedcreate-template
- First observeddelete-container-registry-auth
- First observeddelete-endpoint
- First observeddelete-network-volume
- First observeddelete-pod
- First observeddelete-template
- First observedget-container-registry-auth
- First observedget-endpoint
- First observedget-network-volume
- First observedget-pod
- First observedget-template
- First observedlist-container-registry-auths
- First observedlist-endpoints
- First observedlist-network-volumes
- First observedlist-pods
- First observedlist-templates
- First observedstart-pod
- First observedstop-pod
- First observedupdate-endpoint
- First observedupdate-network-volume
- First observedupdate-pod
- First observedupdate-template

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2/5.0

Scored 2026-09-10 02:09 across 36 tools

Disambiguation3/5

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.

Naming Consistency3/5

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.

Tool Count2/5

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.

Completeness5/5

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.

Maintenance

ActivityNo data

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128

Related MCP Servers

my-mcp-server
Code Execution Developer Tools
15972289829
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that allows integration with Claude Desktop by creating and managing custom tools that can be executed through the MCP framework.
Updated a year ago (2025-06-03 06:36 UTC)
25 npm
-
RunPod MCP Server
Niel-RunPod
A
license
D
quality
D
maintenance
A Model Context Protocol server that enables interaction with the RunPod REST API through Claude or other MCP-compatible clients for managing pods, endpoints, templates, network volumes, and container registry authentications.
Updated a year ago (2025-07-08 12:45 UTC)
26
MIT
OpenAPI MCP Server
API Testing Developer Tools
luciVuc
A
license
Not graded
quality
C
maintenance
A generic MCP server that dynamically converts OpenAPI-defined REST APIs into tools for LLMs like Claude. It supports multiple authentication methods and transport protocols, enabling seamless interaction with any OpenAPI-compliant API.
Updated 2 months ago (2026-07-21 01:58 UTC)
20 npm
MIT
Rancher MCP Server
Cloud Platforms Developer Tools
LokiMCPUniverse
F
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server that exposes the Rancher Manager v2.x API to LLM clients.
Updated 5 months ago (2026-04-18 15:24 UTC)
11
3
-

Runpod MCP server

Quick start

Or install the whole Runpod plugin

Requirements

Connect to the hosted server

Usage analytics

Run locally with npx

Local client setup

Usage examples

The tool surface

Security

Local development

License

JavaScript API migration

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Run locally with `npx`