meshive-mcp

Official

by meshive

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Connect to Storage

connect_storage

Idempotent

Get an SSH command and one-time password to connect to a storage volume when the user asks; preview connection state first, then confirm after agreement.

Instructions

Get an SSH login to a storage volume's files, like the console's Connect, only when the user asks to connect: the command to run and a one-time password that expires in a few minutes (expires_at). storage is the pv_name from the storages tool. Encrypted storage is unlocked and an access pod is started for it; it locks again by itself after auto_lock_minutes (remaining_seconds left). Other storage is reached through the access pod that already runs for it. With confirm=false (default) it only returns the storage's connection state and changes nothing; call again with confirm=true after the user agreed. It needs a read & write key. The confirmed call waits up to wait seconds (0-90, default 60) for the storage to be ready; if it isn't yet, the result has no password and says to call again. Give the command and password to the user and nobody else: never run the command yourself or put the password in files, commits or other tools. Each confirmed call issues a new password, and it isn't kept as an operation record. 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
`wait`	No
`confirm`	No
`storage`	Yes
`workspace`	No
`operation_id`	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.8/5.0

Behavior5/5

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

Far exceeds the annotations: it discloses that encrypted storage is unlocked and an access pod spun up, that it re-locks after auto_lock_minutes, that a read & write key is required, that each confirmed call mints a new short-lived password, that the password is not persisted as an operation record, and how waiting/timeouts behave. The only mild tension is with idempotentHint=true, but the operation_id reuse rules explain the intended semantics.

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 credential-delivery warning, then organized into preview/confirm, timing, and operation_id sections. The operation_id paragraph is generic boilerplate that repeats across write tools, but it is load-bearing here because retries can mint new passwords.

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?

Covers everything needed to invoke safely despite a rich output schema: the preview/confirm gate, the required key scope, the wait window and the 'no password yet, call again' outcome, and the handling rules for the returned credentials. Only the workspace parameter is left unexplained.

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 carries the burden and does well for four of five parameters: storage (pv_name from the storages tool), confirm (default false = no changes), wait (0–90, default 60, with timeout behavior), and operation_id (reuse preview ID or a pre-generated UUID, keep across retries). The workspace parameter is never mentioned, leaving one of five undocumented in both schema and text.

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 concrete verb and resource — 'Get an SSH login to a storage volume's files' — and immediately anchors it to a known analogue ('like the console's Connect'), which distinguishes it from siblings like ssh_access and storages. The scope qualifier 'only when the user asks to connect' further narrows what the tool produces versus adjacent storage tools.

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 states when to use it ('only when the user asks to connect') and when not to act (do not run the command yourself, do not put the password in files, commits or other tools). It also gives the two-step protocol — confirm=false preview first, confirm=true after user agreement — and names the storages tool as the source of the storage identifier.

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