Pack local or remote codebases into AI-friendly files that LLMs and coding agents can read or search
Find raidcom commands. Use this first when you do not know the exact command name. With no arguments, lists every object (ldev, lun, host_grp, pool, ...) with the actions available on it. With query (plain words, e.g. "map a volume to a host group", "grow a pool", "show free ldev ids"), ranks matching commands and rates the confidence of the top result. With action and/or object, lists exact
A call is made on an account: it counts against an allowance and the publisher sees it, which is why this one asks who you are first.
What it does
raidcom-mcp lets your AI assistant write Hitachi raidcom commands for you, and get them right. Describe the task in plain English, such as “give esx01 four 100 GB volumes from pool 0 on CL1-A and CL2-A”, and you get back commands or a ready-to-run script instead of an afternoon in the CCI Command Reference.
Every command is checked before you see it. It knows all 178 raidcom commands and their syntax, and checks LDEV, LUN, pool and port values against the limits of your model (VSP One Block, VSP 5000, VSP E series). Scripts lock the resource group, wait for asynchronous commands and stop at the first failure. Fourteen ready-made recipes cover FC, iSCSI and NVMe/TCP provisioning, DP and mainframe pools, and more. It can also check a command you already have.
It’s build-only: it never connects to your array and needs no credentials, so you review the output and run it yourself on your CCI host. Open source (MIT), a community project, not an official Hitachi Vantara product.
Quickstart
# 1 — sign in once: npx mcprush@latest login
# it asks for a key from mcprush.com/dashboard#access
# 2 — install
npx mcprush@latest add visubramaniam/hitachi-raidcom-command-builder-community-mcp
# 3 — ask your agent for something these tools do
# raidcom_list_commands, raidcom_describe_command, raidcom_build_command and 5 more
Windows PowerShell says 'running scripts is disabled on this system'? Run Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once, or type npx.cmd instead of npx (codex.cmd, gemini.cmd, grok.cmd likewise). PowerShell 7 needs neither.
Hitachi raidcom command builder (Community) costs nothing on mcprush: there is no plan to choose here, no cap to set and nothing mcprush can bill you for.
Where are you running it?
Every route below installs the same thing and ends at the same approval screen. Nothing here runs on your machine — this server runs on the publisher’s own infrastructure behind our gateway, and what you install is the connection to it.
Claude Code has its own MCP command, and the key rides on it as a header — the gateway refuses a call that carries none. Claude Code reads MCPRUSH_KEY each time it connects, so the key stays out of its config: export your key from Access in your shell profile (macOS, Linux), or run setx MCPRUSH_KEY <your key> and open a new terminal (Windows). Or let npx mcprush@latest add visubramaniam/hitachi-raidcom-command-builder-community-mcp write the entry with the key for you; --scope user makes it available in every project.
claude mcp add --transport http --scope user hitachi-raidcom-command-builder-community-mcp https://mcprush.com/gw/hitachi-raidcom-command-builder-community-mcp/mcp --header 'Authorization: Bearer ${MCPRUSH_KEY}'Reconnect, or start a new session, and the tools appear in the model’s tool list.
Nothing is required, but it can take RAIDCOM_TRANSPORT (stdio (default) or http), RAIDCOM_HTTP_TOKEN (Bearer token for the HTTP transport (at least 32 characters)) if you want to set them.
One config entry pointing at the gateway. The server itself runs on the publisher’s own infrastructure, so nothing from this listing executes on your machine.
8 tools, with what each one reads, writes and reaches shown before you agree — the same list on every route above. Read the tool surface.
Tool surface
What the model actually sees. Descriptions are diffed on every release — see version history.
Find raidcom commands. Use this first when you do not know the exact command name. With no arguments, lists every object (ldev, lun, host_grp, pool, ...) with the actions available on it. With query (plain words, e.g. "map a volume to a host group", "grow a pool", "show free ldev ids"), ranks matching commands and rates the confidence of the top result. With action and/or object, lists exact
| Parameter | Type | Required | Notes |
|---|---|---|---|
| query | string | no | What you want to do, in plain words. |
| action | string | no | Only this action: add, delete, get, modify, extend, initialize, set, reset, ... |
| object | string | no | Only this object: ldev, lun, host_grp, hba_wwn, pool, dp_pool, port, parity_grp, ... |
| limit | integer | no | Maximum results for a query (default 10). |
Everything needed to build one raidcom command: what it does, which models support it, whether it is read-only, destructive or asynchronous, each syntax form, every option with the number and kind of values it takes (and the words it accepts, where it accepts only a few), and examples. Call it before raidcom_build_command when you are unsure which options a command needs or which of its syntax for
| Parameter | Type | Required | Notes |
|---|---|---|---|
| command | string | yes | Command name, e.g. "add lun" or "raidcom get ldev". |
| option | string | no | Only describe this option, e.g. "-ldev_id". |
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, "-l
| Parameter | Type | Required | Notes |
|---|---|---|---|
| command | string | yes | Command name: action and object, e.g. "add lun", "get ldev", "modify host_grp". |
| options | no | — | |
| model | no | — | |
| global | no | — | |
| strict | no | — |
Validate and explain a raidcom command line the user already has (for example one pasted from a runbook). It is parsed, not executed: shell operators such as ; | & > are refused. Returns the normalised command, what each option means, and every problem found. Credentials after -login are dropped.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| command_line | string | yes | One raidcom command, e.g. "raidcom add lun -port CL1-A-0 -ldev_id 200 -lun_id 1". |
| model | no | — | |
| strict | no | — |
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 scr
| Parameter | Type | Required | Notes |
|---|---|---|---|
| steps | array | yes | — |
| model | no | — | |
| global | no | — | |
| strict | no | — | |
| login | boolean | no | Add raidcom -login / -logout using $RAIDCOM_USER and $RAIDCOM_PASSWORD. |
| lock_resource | boolean | no | Wrap the commands in raidcom lock resource / unlock resource. Recommended for changing commands. |
| description | string | no | A one-line comment for the top of the script. |
Ready-made workflows: provision volumes to an FC, iSCSI or NVMe/TCP host, create or grow a pool, create a mainframe (3390) pool, extend or delete volumes, create a command device, reclaim zero pages, read-only inventory, copy groups. With no arguments lists them. With recipe, shows its parameters and steps. With query, ranks recipes by keyword. Use raidcom_build_recipe to turn one into a scrip
| Parameter | Type | Required | Notes |
|---|---|---|---|
| recipe | string | no | Recipe ID to show in detail, e.g. provision-fc-volumes. |
| query | string | no | Words describing the task, e.g. "new ESXi host". |
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 execut
| Parameter | Type | Required | Notes |
|---|---|---|---|
| recipe | string | yes | Recipe ID. |
| params | object | yes | Recipe parameters. |
| model | no | — | |
| global | no | — | |
| strict | no | — | |
| login | boolean | no | Add raidcom -login / -logout using $RAIDCOM_USER and $RAIDCOM_PASSWORD. |
| lock_resource | boolean | no | Wrap the commands in raidcom lock resource / unlock resource. |
Valid parameter ranges for a storage model (serial number, LDEV ID, pool ID, LU number, port names), taken from the Command Reference appendices. Without model, lists the models.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| model | no | — |
- Every tool, no call limit, and mcprush charges nothing
- A buyer key from your dashboard — the gateway refuses a call without one
- Answers through our gateway, so every call is in your log
- Nothing to cap, because mcprush bills nothing
What counts against your monthly calls
| Tool | Unit | Calls used | Out of the allowance |
|---|
Nothing here is billable: mcprush charges nothing to install Hitachi raidcom command builder (Community) or to call it, and its free tier carries no monthly call limit.
Two independent axes, because powerful and malicious are different questions. The grade is threat only. The capability level is blast radius, and it is never a penalty on the grade — it is priced as one subtract-only term in the score, where you can see it.
| Term | Level | What it prices | Points |
|---|---|---|---|
| capability-exposure | minimal | capability blast radius (minimal) — client exposure if the model is manipulated | −0 |
| verification-discount | repo | publisher verification (public source) — no provenance, but the source is public and inspectable | −1 |
| coverage-honesty | source | inspection depth (source) — how much of the target the scan could see | −0 |
What the scan could actually read
A grade is only as meaningful as its coverage, so the scanner publishes its own depth before it publishes its result.
No tools were enumerated, so prompt-injection, capability and toxic-flow analysis had no tool surface to inspect. To grade a package’s real runtime tools, scan the running server: --command "npx -y <package>".
Capability — what it could do if the model were manipulated
Tags derived from each tool’s schema and the implementation, not from what the tool calls itself. minimal is the level these add up to.
| Tool | Capability tags | Why the tag was assigned |
|---|---|---|
| No per-tool rows for this release — see the note below. | ||
Toxic-flow graph
The lethal trifecta, checked as a graph rather than as a checklist: untrusted input, a sensitive source and an external sink have to meet before there is a path worth worrying about.
The public result for this release does not print the flow graph, so there is nothing to show here. That is not the same as "no paths were found": what the scan did read is above, under coverage.
Supply chain and provenance
This is the first scan of this surface here, so there is nothing yet to compare it against.
Every result on this tab comes from one deterministic pass over the published package — offline, rule by rule, and auditable line by line above. Same methodology version, same bytes, same score.
Release history
The gateway serves every install the publisher’s current release, so a release cannot be pinned or rolled back to here yet. The history below is for reading; the current release on file is 0.1.6.
- New mainframe pool recipe, CU:LDEV support, and tighter safety checks on every generated command.
- The version this listing went live with, after review.
One review per account, from a signed-in account that does not publish this listing. Nothing else is asked — you can say what you think before you install it. Publishers can reply once per review, and a review can be edited or deleted by whoever wrote it.
Any signed-in account that does not publish Hitachi raidcom command builder (Community) can review it, once — before installing it or after. A review from an account that has installed it is marked as one.
Nobody has reviewed this listing. The rating on the card is the mean of the reviews written here and nothing else, so there is no rating until somebody writes the first — which takes a signed-in account that does not publish it, and nothing else.