Skip to main content
Glama
meshive

meshive-mcp

Official
by meshive

Estimate Pod Price

estimate_pod
Read-onlyIdempotent

Estimate a pod's hourly price and hardware before creation so you can confirm costs and resources without spending credit.

Instructions

Estimate the hourly price of a pod before creating it; nothing is created and no credit is spent. Call this first, show the user the price and hardware, then call create_pod with the same arguments.

workspace takes the id from the workspaces tool (a label also works). template_id comes from the templates tool. GPU pod: pass gpu_model (from the gpus tool) and optionally gpu_count/gpu_vram_gb; vCPU/RAM default to the GPU's recommended sizes. CPU pod: omit gpu_model; cpu_line picks the CPU line (a cpu_line value from the cpus tool; CPU pods only, default the cheapest line that fits) and vCPU/RAM default to 8 cores / 32 GiB like the console (or the nearest sizes that line offers). vcpu and ram_gb are totals for the pod and must be sizes the console offers; a rejected size comes back with the allowed values. The system disk is sized by the server (shown as resources.disk_gb in the estimate). volumes attaches EXISTING network (nfs) storage from the storages tool: [{"storage": pv_name, "mount_path": "/data"}]. Existing local storage can't be attached to a new pod. local_volumes creates NEW local storage on the pod's machine together with the pod: [{"name": "scratch", "mount_path": "/scratch", "size_gb": 50}] with optional "encrypted", "usage_warning" and "usage_warning_threshold" (0-1). Each needs at least 10 GiB and spot pods can't have one. It is billed hourly by size until it is deleted, also while the pod is stopped and after the pod is deleted unless delete_pod lists it; the estimate includes it as breakdown.local_storage. ports opens new ports: a list like [8888, {"port": 6006, "name": "tb", "external": false}]; don't repeat ports or port names the template already has. template_ports changes the ports the template opens, like the console's deploy screen: [{"port": 8188, "name": "ui", "new_port": 8189, "external": false}], where port is the template's port and "name" (rename), "new_port" (renumber) and "external" (true = exposed over HTTPS, false = internal only) are optional. Template ports can't be removed; use ports to open new ones. env is a dict and secret_keys names the secret ones; template variables the template leaves blank need a value. command overrides the start command (at most 4096 characters). max_price_per_hour is checked against the estimate (compute plus new local_volumes) before creating and caps the final COMPUTE hourly rate at placement; an over-cap placement fails asynchronously. Existing storage you attach and Asset Hub retention are billed separately and excluded from this cap. region is accepted for compatibility and ignored. input_assets places Asset Hub assets in the pod: ["asset_id" or {"asset": id, "target_dir": "/workspace/models", "role": role, "paths": ["sub/folder/"], "strip_prefix": ""}] (default place /inputs/ or the template's path for that role); "paths" picks some files or folders, copied from the asset's file list exactly as written there, and "strip_prefix": "" keeps their folder structure (left out, the folder they share is stripped). Only these keys are accepted. They add an input volume billed by size. watched_folders uploads new files in those folders as assets: ["/workspace/results" or {"path": p, "include": [".png"], "include_existing": false, "enabled": true}] (the template's own output folders are watched already). It works on templates without an output folder too (for example NIM or vLLM), as long as the pod has storage the folders sit in (volumes or local_volumes). watched_template_folders changes those template folders from the start, like the console's create screen: {"/outputs": {"enabled": false}} turns one off, {"/outputs": {"include": [".png"]}} uploads only matching files, and {"/workspace/output": {"path": "/workspace/results"}} moves an output folder (its $MESHIVE_OUTPUT_DIR and storage follow; output folders only). harvest_destination {"mode": "user_s3", "credential_id": n} sends them to the user's bucket instead of managed storage. model_set adds one model set to the pod: a slug from the model_sets tool for this template (only templates whose list is selectable; one set per pod). Its files are added as input assets before the pod is created, so creating takes longer, often several minutes. The estimate shows the set as model_set with its file count, size and minimum GPU memory. If a file can't be added, no pod is created (model_set_unavailable) and the files already added are reused next time. hf_token_id is for Quick Deploy templates whose model set is gated on Hugging Face (the model_sets tool shows hf_token_required and gated_sources): the id of a workspace token from the source_credentials tool whose Hugging Face account accepted the model's license. The set's files download with that token, so the user must first accept the license on the page in gated_sources with the same Hugging Face account. Without it the server refuses with hf_token_required; hf_license_not_accepted / hf_access_not_approved mean that account hasn't accepted the license or isn't approved yet, and hf_token_rejected means the token is invalid. Like model_set, a confirmed create with it returns only after the files were linked, which can take minutes.

Input Schema

NameRequiredDescriptionDefault
envNo
nameYes
vcpuNo
portsNo
ram_gbNo
regionNo
commandNo
volumesNo
cpu_lineNo
gpu_countNo
gpu_modelNo
model_setNo
workspaceNo
cpu_premiumNo
gpu_vram_gbNo
hf_token_idNo
rental_typeNodemand
secret_keysNo
template_idYes
input_assetsNo
local_volumesNo
template_portsNo
uptime_premiumNo
watched_foldersNo
internet_premiumNo
max_price_per_hourNo
harvest_destinationNo
watched_template_foldersNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as read-only, idempotent, and non-destructive, and the description reinforces this by stating nothing is created and no credit is spent. It also adds behavioral context beyond annotations, including that max_price_per_hour is checked against the estimate, that over-cap placement fails asynchronously, and that local volumes are billed hourly even while stopped and after pod deletion.

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 front-loaded with purpose and call order, then proceeds through parameters in a dense but mostly purposeful way. Given 28 parameters and 0% schema coverage, most sentences earn their place, though the result is a long wall of text that could be easier to scan.

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 complex 28-parameter tool with no schema descriptions but an output schema and useful annotations, the description provides enough operational context to construct estimates correctly. The output schema covers return values, and the description fills in pricing, storage, port, asset, and token behavior beyond what structured fields provide.

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 does so for most of the 28 parameters: workspace, template_id, GPU/CPU sizing, volumes, local_volumes, ports, env, command, input_assets, watched folders, model_set, and hf_token_id all get concrete syntax and behavior. However, it does not explain notable parameters such as rental_type, cpu_premium, uptime_premium, or internet_premium, so it stops short of full coverage.

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: estimate the hourly price of a pod before creating it. It immediately distinguishes this from the mutation sibling by saying nothing is created and no credit is spent, and directs the agent to call create_pod afterward. An agent can tell exactly what this tool is for without opening another schema.

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 an explicit call order: call estimate_pod first, show the user the price and hardware, then call create_pod with the same arguments. This directly names the alternative and the condition that selects it, leaving little to inference.

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