Raidcom MCP

Build a raidcom command

raidcom_build_command

Read-onlyIdempotent

Build and validate a single raidcom command from structured arguments without executing it or contacting storage; returns command text with errors and fixes for review.

Instructions

Build one raidcom command from structured arguments and validate it. Nothing is executed and no storage system is contacted: you get command text to review and run elsewhere. Unknown options, wrong value counts, missing required options, bad port names and out-of-range LDEV, LUN, pool and serial numbers are reported as errors with a fix. Example: {"command": "add ldev", "options": {"-pool": 0, "-ldev_id": 256, "-capacity": "100G"}, "model": "vsp-one-b28", "global": {"instance": 0}} → raidcom add ldev -pool 0 -ldev_id 256 -capacity 100G -I0. For many similar commands use raidcom_build_script, not repeated calls. When the user asks for a command, show them the command from the result.

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": {
      "command": "<command>"
    },
    "name": "raidcom_build_command"
  }
}

Input Schema

Name	Required	Description
`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.
`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.
`command`	Yes	Command name: action and object, e.g. "add lun", "get ldev", "modify host_grp".
`options`	No	raidcom options and their values, keyed by option name with or without the leading dash. A value is a string or number; an option that takes several values (for example -port takes a port and an optional host group name) takes an array: {"-port": ["CL1-A-0", "esx01"]}. An option with no value (a switch such as -allports) is true. Example for `add lun`: {"-port": ["CL1-A-0"], "-ldev_id": 200, "-lun_id": 1}.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.8Oct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuine beyond-annotation context: no execution, no array contact, the output is reviewable command text, and the full error set (unknown options, value counts, port names, LDEV/LUN/pool/serial ranges). The strict-flag caveat about manual-parsed catalogue false alarms is unusually candid.

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-loads the purpose and safety statement before the example and routing advice, and every sentence carries information. It is dense and long-ish, but the example and the strict-flag note justify their space.

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?

With no output schema, the description carries return-value explanation and does so partly ('you get command text', 'reported as errors with a fix', 'the `command` from the result'). The exact result envelope (fields for command vs. errors/warnings) is only implied, which keeps it short of a 5.

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 100%, so the baseline is 3; the description earns above baseline by walking a concrete example that maps structured arguments (options, model, global.instance) to emitted text, which clarifies how the nested `global` and `options` shapes combine. It does not restate the model-alias or enum rules, which the schema already covers.

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 ('Build one raidcom command ... and validate it') and immediately clarifies side effects ('Nothing is executed and no storage system is contacted'). The agent can distinguish it from raidcom_build_script, which the description names explicitly.

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?

Gives a clear when-not ('For many similar commands use raidcom_build_script, not repeated calls') and a workflow rule ('show them the `command` from the result'), and the strict param description routes to raidcom_describe_command for follow-up. The remaining sibling raidcom_check_command is not addressed, so routing is not fully exhaustive.

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

Deploy Server