Raidcom MCP

Build a raidcom recipe script

raidcom_build_recipe

Read-onlyIdempotent

Builds a validated raidcom script and individual commands from a recipe and parameters, so you can review provisioning commands before executing them yourself.

Instructions

Build the script for a recipe from its parameters (see raidcom_list_recipes). Lists such as ldev_ids accept ranges: ["100-109"]. Example: recipe provision-fc-volumes with {"pool": 0, "ldev_ids": ["100-103"], "capacity": "100G", "ports": ["CL1-A", "CL2-A"], "host_grp": "esx01", "host_mode": "VMWARE_EX", "wwns": ["210000e08b0256f8"]}. Returns the script and the individual commands. 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": {
      "recipe": "<recipe>",
      "params": "<params>"
    },
    "name": "raidcom_build_recipe"
  }
}

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.
`global`	No	Settings that apply to the whole command, not to one raidcom option.
`params`	Yes	Recipe parameters.
`recipe`	Yes	Recipe ID.
`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.
`lock_resource`	No	Wrap the commands in raidcom lock resource / unlock resource.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.8Oct 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with 'Nothing is executed' and discloses the return content ('the script and the individual commands'). The strict-mode caveat about manual-derived syntax producing false 'needs <option>' errors is genuinely useful behavioral context not in annotations.

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, followed by the most important format constraint (ranges) and a single compact example. The example is dense but earns its space by demonstrating an otherwise untyped params object.

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 7-param builder with no output schema, the description covers what is produced (script plus individual commands), that nothing is executed, and the param encoding conventions. No significant gap remains for correct invocation.

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, but the description adds real value for the free-form 'params' object: the worked example shows the exact shape (pool/ldev_ids/capacity/ports/host_grp/host_mode/wwns) and the note that list values accept ranges like ["100-109"]. That is information the schema cannot convey.

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?

States a specific verb+resource: 'Build the script for a recipe from its parameters', and points at raidcom_list_recipes for recipe discovery. It does not explicitly distinguish itself from the close sibling raidcom_build_script, so an agent must infer the recipe-vs-command split.

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 clear context: use raidcom_list_recipes to find the recipe ID, and it explicitly says 'Nothing is executed', so the agent knows this is a dry build step. It also prescribes a retry workflow with strict=false after consulting raidcom_describe_command, though it doesn't contrast the other build/check siblings.

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

Deploy Server