Skip to main content
Glama
meshive

meshive-mcp

Official
by meshive

Start Pod

start_pod
Idempotent

Start a stopped GPU cloud pod, preview its state and hourly price, then confirm to resume billing; optionally choose same-node, any-node, or waiting placement.

Instructions

Start a stopped pod; hourly billing resumes. With confirm=false (default) it only returns the pod's current state and hourly price and changes nothing; call again with confirm=true after the user agreed to pay again. placement: omit it (default) and the server picks what the console's Start button would; the result's placement says which one it used. Or choose: "same_node" starts it on its original machine now; "wait_same_node" waits until that machine has room and then starts it there; "any_node" moves it to another machine now; "wait_any_node" waits until any machine has room and starts it there. A waiting pod shows as waiting in the pods tool. any_node and wait_any_node can move the pod: unpreserved workspace files are then permanently deleted and attached local storage stays on the old machine. For those two, set allow_data_loss=true only after separate explicit consent to that permanent loss for this pod and placement. allow_data_loss is only sent with an explicit placement: when the server's own pick would move a pod with unpreserved files, the call fails with data_loss_consent_required and names that placement. Asynchronous — poll pods for running. Every write requires operation_id. Reuse the ID returned by the preview, or generate a UUID before the first call. Keep it for confirmation and all retries; a new ID means a new operation. After a timeout, check operation_status and resource state before retrying.

Input Schema

NameRequiredDescriptionDefault
podYes
confirmNo
placementNo
workspaceNo
operation_idNo
allow_data_lossNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior1/5

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

The description says any_node and wait_any_node can permanently delete unpreserved workspace files and that allow_data_loss is required for explicit consent. This contradicts the annotation destructiveHint=false, which declares the tool non-destructive.

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 long but appropriately front-loads the core behavior and confirmation model before covering placement and data-loss semantics. It is dense and somewhat run-on, but most sentences carry operational information needed for safe invocation.

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?

It covers the confirmation flow, placement choices, data-loss consent, billing resumption, asynchronous polling, and operation_id retry behavior. The main gap is that the workspace parameter is not described, and the destructive data-loss behavior creates annotation inconsistency.

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 description coverage is 0%, so the description must carry parameter meaning, and it explains confirm, the placement values, allow_data_loss, and operation_id in useful detail. However, it does not explain the workspace parameter at all, leaving one of the six parameters undocumented.

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 states a specific verb and resource: start a stopped pod, and notes that hourly billing resumes. It also distinguishes the action from siblings such as stop_pod and restart_pod by focusing on starting an already-stopped pod.

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

Usage Guidelines5/5

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

It gives explicit two-step confirmation guidance: confirm=false only previews state and price, and confirm=true should be used only after the user agrees to pay again. It also details when to omit placement versus choose each placement option, and when allow_data_loss may be set.

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