meshive-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Create Storage

create_storage

Create an NFS storage volume (10 GiB+) that any workspace pod can attach, with optional encryption and usage warnings; preview cost, then confirm to provision.

Instructions

Create a network (nfs) storage volume of size_gb GiB (at least 10, like the console) that any pod in the workspace can attach. It is billed hourly by capacity for as long as it exists, mounted or not. With confirm=false (default) it only returns the estimate; call again with confirm=true after the user agreed. encrypted turns on at-rest encryption. usage_warning warns the user when the volume fills past usage_warning_threshold (0-1, default 0.9 = 90% full), like the console's usage warning. Local storage can't be created on its own: create it together with a pod through create_pod local_volumes. storage_type stays "nfs" ("hostPath" is refused); disk_type and region are accepted for compatibility and ignored. The volume appears in the storages tool shortly after; attach it to a pod with create_pod volumes. 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	Default
`name`	Yes
`region`	No
`confirm`	No
`size_gb`	Yes
`disk_type`	No	NVMe
`encrypted`	No
`workspace`	No
`operation_id`	No
`storage_type`	No	nfs
`usage_warning`	No
`max_price_per_hour`	No
`usage_warning_threshold`	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?

Annotations are present but the description adds substantive behavior beyond them: hourly billing by capacity whether mounted or not, preview-vs-commit semantics, storage_type/disk_type/region handling and refusal of hostPath, and visibility lag before the volume appears in the storages tool. The operation_id paragraph covers idempotency/retry and timeout recovery, which is exactly the kind of context annotations alone don't convey.

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 action and size constraint, then organized into coherent paragraphs for behavior, caveats, and the operation_id protocol. Every sentence carries information, though the operation_id/retry block is generic boilerplate that lengthens the definition relative to the tool-specific content.

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 12-parameter mutating billed resource with an output schema, the description is nearly sufficient: it covers creation, billing, preview/confirm, encryption, warning thresholds, type handling, and follow-on steps. The main gap is that `max_price_per_hour` (a cost-control parameter with real consequences) and workspace targeting go unmentioned.

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 the description must carry all parameter meaning, and it does for most: size_gb minimum of 10, encrypted at-rest, usage_warning plus its 0-1 threshold default of 0.9, storage_type/disk_type/region accepted-and-ignored behavior, confirm, and operation_id. However `max_price_per_hour` is never explained, and `name`/`workspace` are left undocumented, so a few semantics gaps remain.

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 (create an nfs storage volume) with its scope (attachable by any pod in the workspace) and billing model. It also distinguishes itself from siblings by routing local storage to create_pod `local_volumes` and post-creation attachment to create_pod `volumes`.

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 to get an estimate, then confirm=true after user agreement. It also names the when-not case (local storage cannot be created standalone) and the fallback path (create it with a pod instead).

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