Provides tools for interacting with the Hitachi VSP One Block REST API (Configuration Manager), enabling AI agents to manage and query storage system operations such as volumes, pools, servers, snapshots, and replication pairs via 425 API operations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vsponeblock-mcp list all volumes on the VSP One Block array"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Hitachi VSP One Block REST API (Configuration Manager, microcode 10.5.4), built from the OpenAPI spec spec/vsponeblock-10.5.4.yaml. It gives Claude (or any other MCP client) access to 425 API operations, from both the simple API (/simple/v1/...) and the detail API (/v1/objects/...). The two session endpoints are excluded because the server manages its own session.
It is a fork of vsp360-mcp, the community MCP server for VSP 360, adapted to talk to a VSP One Block storage system directly.
Not an official Hitachi Vantara product: vsponeblock-mcp is an independent, community project, and isn't supported by or affiliated with Hitachi Vantara. Hitachi and VSP One are trademarks of their owners.
The spec is too large to load as 425 separate tools. The server therefore always provides three discovery tools:
Tool | Purpose |
| Lists the API areas (tags such as |
| Shows the parameters, request body and response schema for one operation. |
| Calls any operation by |
For the areas you use most, set VSPONEBLOCK_TOOLSETS to add direct tools: one tool per operation, each with a full input schema. For example:
VSPONEBLOCK_TOOLSETS="simple/volumes,simple/pools,simple/servers"vsponeblock_list_operations finds operationsBM25 ranking orders the operations. The operationId and summary count more than the long description, storage vocabulary is mapped onto the spec's wording (LUN → LDEV, host → server and host group, GAD → global-active device pair), and spec/examples.json adds example questions for common operations.
A confidence rating (HIGH, MEDIUM or LOW) says how far to trust the top result. With HIGH confidence, the top result's parameters come with the results, so Claude can usually call it straight away.
npm run eval scores search against labelled requests in tests/cases.mjs: currently 46/48 top-1 on the tuning set and 14/20 top-1 (17/20 top-3) on a held-out set. npm test fails if either drops.
Related MCP server: MinIO MCP Server
By default only GET operations are allowed, plus downloading a configuration report (a POST that only reads). All other operations are refused, and direct tools are not created for them. These include creating, expanding and deleting volumes and pools, attaching volumes to servers, snapshots and replication pairs, users, encryption keys and the DKC power state. To allow them, set VSPONEBLOCK_ALLOW_WRITES=true. DELETE tools are marked destructiveHint, so Claude asks for confirmation before running them.
Use a least-privilege storage user. The server acts with the permissions of the user it signs in as. For read-only use, sign in as a user whose only role is Storage Administrator (View Only), so the array itself refuses changes even if the server's own check were bypassed.
Local files. Claude chooses save_to and upload paths, so text it reads from the API could try to steer them. save_to therefore only writes inside VSPONEBLOCK_DOWNLOAD_DIR and never overwrites a file (set VSPONEBLOCK_SAVE_ANYWHERE=true to lift the folder rule). Uploads (certificates, encryption key restores) refuse hidden files and folders such as ~/.ssh or .env; set VSPONEBLOCK_UPLOAD_DIR to allow uploads only from one folder.
Sessions: Opens a REST API session with POST /ConfigurationManager/v1/objects/sessions using the configured user and password (HTTP Basic), then sends Authorization: Session <token> on every call. A session ends after VSPONEBLOCK_SESSION_ALIVE_TIME seconds without a request (300 by default), so one left idle for nearly that long is replaced before use, and a 401 opens a new one once. The server discards its session on exit, so it doesn't hold one of the array's 64 session slots until it times out. The two DKC power-state operations use Basic authentication, as the spec requires, and the version and storage-list reads need none.
Asynchronous jobs: Detail-API changes run as jobs and return 202 with a job. Pass the header parameters Response-Job-Status: "Completed" and Response-Max-Wait (seconds) to wait for the job in the same call, or follow it up with getJob.
Downloads: Binary responses, such as configuration reports and encryption key backups, are streamed to VSPONEBLOCK_DOWNLOAD_DIR and the file path is returned. Any call can also pass save_to: "volumes.json" (a file name or a path inside the download folder).
Uploads: Multipart operations take local file paths, for example files: {"file": "~/certs/kms.pem"}. Files are streamed from disk.
TLS: Use VSPONEBLOCK_CA_CERT for a private CA. Use VSPONEBLOCK_INSECURE_TLS=true only for lab systems with self-signed certificates, which most arrays have out of the box.
Compact responses: JSON responses and vsponeblock_describe_operation output are returned without indentation. Responses longer than VSPONEBLOCK_MAX_RESPONSE_CHARS are truncated, with a note telling Claude how to narrow the request (for example with count, poolId or startVolumeId).
INSTALL.md has the full installation and deployment guide, including Windows, CI/CD pipelines, checksums, upgrading and troubleshooting. In short:
First, create a user on the storage system for the server, with the roles your use case needs (see Safety). Note the address of the REST API server: the SVP, or the storage controller for the VSP One Block 20 series.
Then install the server in one of these ways. Each GitHub release has the packages and a SHA256SUMS file.
Package | Needs | Use it for |
| Claude Desktop | One-click install: open the file and Claude Desktop asks for the URL, user and password. |
| nothing | Standalone install on macOS, Linux or Windows (x64 and arm64), with Node.js bundled in. |
npm package ( | Node.js 20+ |
|
Claude Code plugin | Claude Code, Node.js 20+ | The server plus capacity and health-check skills: |
Docker image | Docker |
|
Source | Node.js 22+ | Development: |
Standalone. Unpack the archive anywhere and use bin/vsponeblock-mcp (bin\vsponeblock-mcp.cmd on Windows) as the server command. You can symlink it onto your PATH:
tar -xzf vsponeblock-mcp-0.1.0-linux-x64.tar.gz -C /opt && ln -s /opt/vsponeblock-mcp-0.1.0-linux-x64/bin/vsponeblock-mcp /usr/local/bin/vsponeblock-mcpnpm or CI/CD. The vsponeblock-mcp command then starts the server:
npm install -g vsponeblock-mcpThe examples below use vsponeblock-mcp as the command; substitute the path from whichever install you chose.
claude mcp add vsponeblock -e VSPONEBLOCK_URL=https://192.0.2.10 -e VSPONEBLOCK_USER=claude-ro -e VSPONEBLOCK_PASSWORD=REPLACE_ME -e "VSPONEBLOCK_TOOLSETS=simple/volumes,simple/pools" -- vsponeblock-mcpThe .mcpb package is the easiest way. To configure it by hand instead, add this to ~/Library/Application Support/Claude/claude_desktop_config.json. Claude Desktop does not read your shell's PATH, so give the command's full path:
{
"mcpServers": {
"vsponeblock": {
"command": "/usr/local/bin/vsponeblock-mcp",
"env": {
"VSPONEBLOCK_URL": "https://192.0.2.10",
"VSPONEBLOCK_USER": "claude-ro",
"VSPONEBLOCK_PASSWORD": "REPLACE_ME",
"VSPONEBLOCK_TOOLSETS": "simple/volumes,simple/pools"
}
}
}
}To try the tools interactively, run npm run inspect. It opens the MCP Inspector and needs the environment variables set in your shell.
Variable | Default | Description |
| (required) | Address of the REST API server, e.g. |
| (required) | Storage system user |
| (required) | That user's password |
|
| Session idle timeout to ask for, 1–300 seconds |
|
| Allow operations that change the storage system |
| (none) | Comma-separated API areas (tags) to expose as direct tools. |
| PEM file of the CA that signed the storage system's certificate | |
|
| Skip TLS verification (lab use only) |
|
| Request timeout; uploads are exempt |
|
| Truncation limit for text responses |
|
| Where binary downloads and |
|
| Let |
| (any non-hidden path) | Only allow uploads from inside this folder |
| (none) | Path prefixes to rewrite, as comma-separated |
| bundled | Example user questions per operation, used to rank search results. Set to an empty string to turn them off. |
| bundled spec | Path to a different OpenAPI file, YAML or JSON, e.g. for another microcode release |
| (off) | Path to a JSON Lines file. When set, each search, describe and call is logged locally (operation names and argument names only, never values or credentials), for improving search. |
Remote copy operations that also need a session on the remote storage system (the Remote-Authorization header) are listed but can't pass that header yet.
Pagination on this API is by query parameters such as count, headLdevId or startVolumeId, not page links, so all_pages has no effect; ask Claude to page by those parameters instead.
VSPONEBLOCK_TOOLSETSCall vsponeblock_list_operations with no arguments for the full list with counts. The simple API's areas are simple/storage, simple/drives, simple/pools, simple/volumes, simple/volume-server-connections, simple/snapshots, simple/servers, simple/ports, simple/qos-groups, simple/health-status and others; the detail API's are detail/ldevs, detail/pools, detail/host-groups, detail/luns, detail/remote-mirror-copypairs, detail/snapshots, detail/users and others.
npm run package builds every release package into release/. Use --only npm,mcpb,standalone and --targets linux-x64,... to build fewer, e.g. npm run package -- --only standalone --targets darwin-arm64. The standalone packages bundle Node.js 24, downloaded from nodejs.org and checked against its published SHA-256 sums.
The Release workflow runs when a v* tag is pushed. It runs the tests, builds the packages and attaches them to the tag's GitHub release; if that release doesn't exist yet, it's created from the version's CHANGELOG.md section. It then publishes the same .tgz to the npm registry with trusted publishing (set up on npmjs.com under the package's Settings → Trusted Publisher, repository visubramaniam/vsponeblock-mcp, workflow release.yml); this is skipped if that version is already on npm. It pushes the linux/amd64 and linux/arm64 Docker image to ghcr.io/visubramaniam/vsponeblock-mcp using the workflow's own token, and also to Docker Hub if the DOCKERHUB_USERNAME and DOCKERHUB_TOKEN repository secrets are set.
The Claude plugin in plugin/ installs the server from its own lockfile, so it can only pin a version that's already on npm. After a release is published, update it in a follow-up pull request; see README.plugin.md.
Replace spec/vsponeblock-10.5.4.yaml (or point VSPONEBLOCK_SPEC at the new file) and restart the server. No code is generated from the spec. npm run build keeps a pre-parsed copy of the bundled spec in dist/openapi-cache.json; it's only used while the YAML file is unchanged. If the new release adds POST operations that only read data, add them to READ_ONLY_POSTS in src/spec.ts.
The code in this repository is released under the MIT License. The VSP One Block OpenAPI definition in spec/ describes Hitachi Vantara's product API and is not covered by this license.
Call any VSP One Block REST API operation by operationId. Authentication is handled automatically. Pass path, query and header parameters by name in params, and the JSON request body in body. Lists are filtered with query parameters (e.g. count, startVolumeId, poolId); describe an operation to see them. Detail (non-simple) write operations run as asynchronous jobs that return a job: pass the header parameters Response-Job-Status="Completed" and Response-Max-Wait (seconds) to wait for it, or follow it up with getJob. Binary responses (configuration reports, key backups) are saved to the download folder and the file path is returned. Only read operations are allowed; the server runs read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Request body (JSON object or array) for POST/PUT/PATCH operations. For multipart uploads, the non-file form fields. | |
| files | No | Multipart uploads only: form field name -> local file path | |
| params | No | Path, query and header parameters by name, e.g. {"id": "123", "limit": 100} | |
| save_to | No | Write the response to this file instead of returning it: a file name, or a path inside the download folder. Existing files are not overwritten. | |
| all_pages | No | Follow RFC 8288 `next` links and return every page (GET collections only). | |
| max_pages | No | Page cap when all_pages is set (default 20). | |
| operationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive/openWorld, and the description goes well beyond them: automatic authentication, asynchronous job semantics for detail writes with the exact header parameters and getJob fallback, binary responses saved to the download folder with the returned path, and the read-only server constraint. This is unusually rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose and mode of operation, then layers on async, binary, and read-only details in a tight sequence. Dense but nearly every sentence carries distinct operational information; minor length for a tool with this much behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 burden and does so for binary (file path returned) and async (job) cases, and covers the read-only safety constraint. It is a bit thin on paginated collection returns and save_to semantics, but overall sufficient for a generic dispatcher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so the baseline is 3, but the description adds real meaning by explaining that path/query/header parameters are keyed by name in `params` and that body carries JSON for POST/PUT/PATCH. It omits how save_to, all_pages, and max_pages interact, leaving those to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Call any VSP One Block REST API operation by operationId') and its generic-passthrough scope is unambiguous against siblings vsponeblock_list_operations and vsponeblock_describe_operation. An agent can immediately tell this is the execution tool versus the discovery tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating context: auth is automatic, params are passed by name, async writes wait via Response-Job-Status/Response-Max-Wait or are followed with getJob. It nudges toward describe_operation ('describe an operation to see them') but never states an explicit when-to-use-this-vs-sibling rule or when to prefer all_pages/save_to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show everything needed to call one VSP One Block operation: method and path, required permissions and prerequisites, parameters, request body schema and response schema.
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes | operationId from vsponeblock_list_operations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, and the 'Show' verb is consistent with that safe, read-only profile. The description goes beyond the annotations by naming the exact content categories returned (permissions, prerequisites, request/response schemas), though with no output schema it could say more about response format or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with a colon-delimited list of return contents and zero filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a trivial single-parameter schema and no output schema, the description does the necessary work of enumerating what is returned. It is nearly complete, missing only edge-case behavior such as what happens with an invalid or stale operationId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, and the schema provides 100% description coverage, including the provenance hint 'operationId from vsponeblock_list_operations'. The description text adds no further meaning beyond what the schema already supplies, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The single sentence uses a specific verb ('Show') on a specific resource ('one VSP One Block operation') and enumerates exactly what it returns: method/path, permissions, prerequisites, parameters, request/response schemas. This clearly separates it from the sibling list_operations (enumerate) and call_operation (invoke).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'everything needed to call one VSP One Block operation' strongly implies the workflow context (introspect before calling), and the schema ties the input to vsponeblock_list_operations as the source of the operationId. However, no explicit when-to-use/when-not-exclusion or sibling name is stated in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the VSP One Block REST API. With no arguments, lists the API areas (tags) and how many operations each has. With tag and/or query, lists matching operations (operationId, method, path, summary). Use this first to find the operationId you need, then vsponeblock_describe_operation and vsponeblock_call_operation. Operations marked [write] are blocked because the server runs read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | API area, e.g. 'simple/volumes', 'detail/ldevs', 'detail/pools'. Case-insensitive. | |
| limit | No | Maximum results for a query (default 10). | |
| query | No | What you want to do, in plain words (e.g. 'free capacity of each pool', 'volumes mapped to a server'). Ranked by BM25 relevance with a confidence rating. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds a genuinely non-derivable behavioral fact: '[write]' operations are blocked because the server runs read-only, which tells the agent some listed operations cannot be called. It also discloses that query results are BM25-ranked with a confidence rating and describes the returned fields for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler, front-loaded with 'browse with no arguments' before the filtered mode and the follow-up workflow. Every sentence carries a distinct piece of information (default mode, filtered mode, routing).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the returned fields and the confidence rating on query results, plus the read-only restriction on [write] operations. An agent has everything required to discover an operationId and route to the next sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with rich per-parameter descriptions (tag examples, limit max/default, BM25 query semantics), so the baseline is 3. The description goes beyond the schema by stating that 'tag' and 'query' can be combined ('and/or') and that omitting all arguments switches to tag-listing mode — call-pattern semantics the schema does not express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Browse the VSP One Block REST API') with two precisely enumerated modes: no-arg lists API areas/tags, tag/query lists matching operations. It names the exact return fields (operationId, method, path, summary), so an agent knows exactly what comes back without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sequencing: 'Use this first to find the operationId you need, then vsponeblock_describe_operation and vsponeblock_call_operation.' It names both siblings and the condition under which each is used, and explicitly excludes write operations from the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0vsponeblock_call_operationvsponeblock_describe_operationvsponeblock_list_operationsScored across 3 tools
The three tools map to a clean discover → inspect → invoke pipeline (list, describe, call), each with an unambiguous role and no overlap. The descriptions even instruct the intended ordering, making misselection unlikely.
All tools share the vsponeblock_ prefix and a verb_noun pattern (describe_operation, list_operations, call_operation). The only nit is singular/plural inconsistency between 'operation' and 'operations', which is minor and readable.
This is a gateway/proxy pattern exposing an entire REST API, so three tools is exactly the right scope rather than a thin surface. Each tool earns its place and adding more would only fragment the discovery flow.
The set fully covers the read-only lifecycle: browse areas, list operations, inspect schemas, and invoke any operation, including async job and binary-response handling. Write operations are deliberately blocked, so the declarative surface can't create/update/delete, but this is a stated constraint rather than an oversight.
Any REST/SOAP/GraphQL/OData/SQL API as MCP tools for Claude & ChatGPT. 474 connectors: SAP, ERP.
Remote MCP for 1,500+ APIs. Vault-managed credentials; OAuth or API key. Search, load, and execute.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
