meshive-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Submit Task

submit_task

Submit a one-off Python script to run to completion on a GPU or CPU, preview cost before confirming, then poll status and read logs.

Instructions

Submit a one-off task (a script that runs to completion on a GPU or CPU). It is billed while it runs, up to max_duration. With confirm=false (default) it only returns the estimate; call again with confirm=true after the user agreed. Then poll the tasks tool for status and read output with logs.

script is Python source (max 256 KiB) run inside image (or a template_id); use print(..., flush=True) so output reaches the logs. Pass exactly one of gpu_model (GPU task, optional gpu_count/gpu_vram_gb) or cpu_preset (e.g. "micro-2c8g", "small-4c16g", "standard-8c32g"). max_duration seconds (3600..86400) is a hard stop. max_price_per_hour caps the final compute rate only; storage, Asset Hub retention and fetch-time charges are separate. The estimate is not a total-bill ceiling. input_assets attaches Asset Hub assets as ["asset_id" or {"asset": id, "target_dir": dir}] under /inputs. output_include uploads only the /outputs files matching these globs, relative to /outputs and case-sensitive: [".safetensors"] matches at any depth, ["samples/.png"] only in that folder, ["checkpoints/"] every folder of that name with its contents; omitted = every file. Files left out still use /outputs disk while the task runs. A task's output_include is null when no filter was given; if you passed output_include and the submitted task's is null, the server ignores the filter and uploads every file. 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

Name	Required	Description	Default
`env`	No
`args`	No
`name`	Yes
`image`	No
`script`	Yes
`confirm`	No
`gpu_count`	No
`gpu_model`	No
`workspace`	No
`cpu_preset`	No
`gpu_vram_gb`	No
`secret_keys`	No
`template_id`	No
`webhook_url`	No
`input_assets`	No
`max_duration`	No
`operation_id`	No
`requirements`	No
`output_include`	No
`max_price_per_hour`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, it discloses billing behavior ('billed while it runs, up to max_duration'), that max_duration is a hard stop, that max_price_per_hour caps only compute and not storage/retention/fetch charges, and that the estimate is not a total-bill ceiling. It also explains output_include filtering semantics and the requirement to reuse operation_id across confirmation and retries.

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 front-loads the core purpose and confirmation workflow before moving into execution, pricing, asset, output, and retry details. Most sentences carry useful constraints, though the output_include null-handling sentence is slightly convoluted and the overall length is substantial.

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?

An output schema exists, so the description need not explain return values, and it already covers the critical workflow, billing, output filtering, and retry behavior. It is nearly complete for safe invocation, with minor gaps around several secondary parameters (workspace, secret_keys, requirements, webhook_url).

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?

With 0% schema description coverage across 20 parameters, the description carries the explanatory burden and does so well for the ambiguous/complex ones: script/image/template_id, gpu_model/gpu_count/gpu_vram_gb/cpu_preset, max_duration, max_price_per_hour, input_assets, output_include, confirm, and operation_id. It leaves several parameters (env, args, workspace, secret_keys, webhook_url, requirements) to inference, which keeps it from a 5.

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 opens with a specific verb and resource: 'Submit a one-off task (a script that runs to completion on a GPU or CPU).' It distinguishes the tool from long-running pod tools by defining the task as one-off and to-completion, and it explicitly names the sibling tools used for follow-up (tasks, logs).

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 provides an explicit two-step confirmation workflow (confirm=false returns an estimate; call again with confirm=true after user agreement), explains how to poll status via tasks and read output via logs, and gives retry guidance after timeouts using operation_status. It also states the exact-one-of rule for gpu_model vs cpu_preset.

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