Raidcom MCP

Build a raidcom script

raidcom_build_script

Read-onlyIdempotent

Build a validated shell script of raidcom commands from steps with foreach/zip expansion, per-step errors, exit-status checks, and optional locking—nothing is executed.

Instructions

Build a shell script of raidcom commands from steps. Each step is a command with options, optionally repeated with foreach (every combination) or zip (values advance together), so "create LDEVs 100 to 109 in pool 0, then map each to port CL1-A" is two steps. Every expanded command is validated; the script is returned only if all of them are valid, otherwise you get the errors per step. The script checks each command's exit status, adds raidcom get command_status after asynchronous commands, and can lock the resource group and log in (credentials are read from RAIDCOM_USER and RAIDCOM_PASSWORD in the user's shell, never written into the script). Nothing is executed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "steps": "<steps>"
    },
    "name": "raidcom_build_script"
  }
}

Input Schema

Name	Required	Description
`login`	No	Add raidcom -login / -logout using $RAIDCOM_USER and $RAIDCOM_PASSWORD.
`model`	No	Storage model, so values are checked against its limits: vsp-one-b24, vsp-one-b26, vsp-one-b28, vsp-5000, vsp-e590, vsp-e790, vsp-e990, vsp-e1090. Aliases such as B28 or E990 work. Omit it to check against the widest range of any model.
`steps`	Yes
`global`	No	Settings that apply to the whole command, not to one raidcom option.
`strict`	No	Default true. The command catalogue is parsed from the manual, whose syntax lines are occasionally incomplete, so a "needs <option>" error can be a false alarm. If one looks wrong after reading raidcom_describe_command, retry with strict=false: missing-option errors then become warnings. Unknown options and out-of-range values stay errors.
`description`	No	A one-line comment for the top of the script.
`lock_resource`	No	Wrap the commands in raidcom lock resource / unlock resource. Recommended for changing commands.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.8Oct 29, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well past the annotations: it discloses that every expanded command is validated and nothing is emitted on failure, that errors come back per step, that exit-status checks and raidcom get command_status are auto-inserted after async commands, that resource locking and login wrap the script, and that credentials come from RAIDCOM_USER/RAIDCOM_PASSWORD rather than being written in. It also closes with "Nothing is executed," which is exactly the operational fact an agent needs.

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?

A single dense paragraph that front-loads the core purpose and the foreach/zip example before moving to validation and execution behavior. Every sentence carries information, though the clause-per-topic packing makes it slightly hard to scan for a reader hunting one specific behavior.

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 deeply nested 7-parameter tool with no output schema, the description covers the things that matter: what the output is (a script), when output is withheld (any invalid command), and what side effects do not happen (nothing executes, no credentials embedded). Return values need no further explanation given no output schema exists.

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 coverage is already 86%, so the baseline is 3; the description earns a bump by explaining the foreach/zip distinction with a worked two-step scenario and by stating that strict=false only downgrades missing-option errors to warnings while unknown options and out-of-range values stay errors. The individual fields default/model/global are left to their schema text, which is fair given its richness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and artifact — "Build a shell script of raidcom commands from steps" — with a concrete multi-step example (create LDEVs 100-109, then map each to CL1-A). That scope clearly separates it from a single-command builder, but it never names the sibling tools it does not replace (raidcom_build_command, raidcom_build_recipe), so the agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is real routing guidance inside the parameter notes: retry with strict=false "after reading raidcom_describe_command" when a needs-option error looks wrong, and lock_resource is "Recommended for changing commands." It still gives no explicit when-not-to-use-this versus the command/recipe builders, so the contextual inference is left to the agent.

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

Deploy Server