Skip to main content
Glama
meshive

meshive-mcp

Official
by meshive

Edit Pod

update_pod
Idempotent

Modify an existing pod by passing only changed settings, preview the estimated cost, restart impact, and changes, then confirm to apply them.

Instructions

Change an existing pod like the console's Edit: pass only what changes. pod is the pod_name from the pods tool (its display name also works). With confirm=false (default) it only returns the server's estimate (the changes, the hourly price before and after, and whether the pod restarts) and changes nothing; call again with confirm=true after the user agreed. A running pod restarts with the new settings and a stopped pod uses them at its next start; renaming alone (name) doesn't restart it. Input assets and watched folders are kept. Locked like the console: the pod type (GPU or CPU), premiums and the image can't change. Hardware: gpu_model/gpu_vram_gb/gpu_count for GPU pods, cpu_line for CPU pods, rental_type demand or spot. Changing the GPU resets vCPU and RAM per GPU to the new GPU's recommended sizes, changing only gpu_count keeps the per-GPU ratio, and changing the CPU line resets cores and RAM to the console's default. vcpu and ram_gb are pod totals and must be sizes the console offers. An older pod may need ram_gb passed with any change. template_id moves the pod to another template; its variables, ports and command then start from that template, and the preview's changes list what was added before that doesn't carry over. env sets or adds variables (secret_keys names the secret ones) and remove_env removes variables the user added. ports opens new ports, template_ports renames, renumbers or exposes/hides current ports ([{"port": 8188, "name": "ui", "new_port": 8189, "external": false}]) and remove_ports closes ports the user added. Template variables and ports can't be removed. command replaces the start command ("" = back to the template's). Storage: volumes attaches existing network storage ([{"storage": pv_name, "mount_path": "/data"}]) or local storage on the pod's current machine; local_volumes creates new local storage like create_pod (at least 10 GiB, billed hourly until deleted); detach_storages lists pv_names to detach (the storage and its data stay). Spot pods can't have local storage, so detach it to switch to spot. If the pod's machine can't fit the change, the call fails with node_migration_required and nothing changes. Only after the user agrees to a move, call again with allow_node_migration=true. A move permanently deletes unpreserved workspace files: when the pod has any, allow_data_loss=true is also needed, only after separate explicit consent (it is only sent together with allow_node_migration). If the edit would leave watched folders on no attached storage, it fails with harvest_roots_orphaned and their paths; after the user agrees to remove them, pass them as drop_watched_folders. enable_folder_saving=true adds the uploader to an older pod that has none (watched_folders shows editable false with reason no_sidecar), so its folders can be watched; it needs storage on the pod and restarts a running pod once. max_price_per_hour refuses the edit when the new estimate is above it. 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
envNo
podYes
nameNo
vcpuNo
portsNo
ram_gbNo
commandNo
confirmNo
volumesNo
cpu_lineNo
gpu_countNo
gpu_modelNo
workspaceNo
remove_envNo
gpu_vram_gbNo
rental_typeNo
secret_keysNo
template_idNo
operation_idNo
remove_portsNo
local_volumesNo
template_portsNo
allow_data_lossNo
detach_storagesNo
max_price_per_hourNo
allow_node_migrationNo
drop_watched_foldersNo
enable_folder_savingNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes far beyond the annotations: states which fields are locked (pod type, premiums, image), that running pods restart while renames do not, that inputs and watched folders are preserved, that a node move permanently deletes unpreserved workspace files and requires separate consent via allow_data_loss, and that max_price_per_hour refuses an edit. It also discloses the operation_id lifecycle and the timeout-recovery procedure, which no structured field conveys.

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?

Front-loaded with the core purpose and the confirm preview/apply rhythm, then organized by concern (hardware, template, env/ports, storage, failures). For a 28-parameter mutation tool almost every sentence earns its place, but the single dense block makes it harder to scan than a lightly sectioned version would.

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?

Given an output schema exists, return-value explanation is not required, yet the description still characterizes the preview contents (`changes`, before/after hourly price, `restarts`). Combined with the failure modes, consent gates, and operation_id rules, an agent has everything needed to invoke this correctly and safely.

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

Parameters5/5

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

With 0% schema description coverage across 28 parameters, the description carries the full burden and largely discharges it: it explains gpu_model/gpu_vram_gb/gpu_count versus cpu_line, the reset-vs-preserve rules for vCPU/RAM, pod-total semantics for vcpu/ram_gb, env/secret_keys/remove_env, the three port parameters with a concrete example object, volumes vs local_volumes vs detach_storages, and the consent flags. Only `workspace` goes unmentioned.

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?

States a specific verb and resource: "Change an existing pod like the console's Edit: pass only what changes," immediately distinguishing it from create_pod/estimate_pod by scoping it to mutation of an existing pod. It also anchors the required `pod` argument to the pods tool, so an agent knows the prerequisite lookup.

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?

Explicitly prescribes the two-step flow: call with confirm=false (default) for an estimate, then call again with confirm=true only after the user agrees. It also gives conditional branches for node_migration_required, harvest_roots_orphaned, and enable_folder_saving, each with the exact follow-up argument to pass and the consent required before passing it.

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