Roadmap

What's planned for the next two releases. Plans can change; the milestones track progress, and the changelog records what actually shipped.

Release	Theme	Milestone
0.1.24	One MCP server for several VSP 360 instances	0.1.24
0.1.25	The Fleet Management API, once Hitachi Vantara releases it	0.1.25

Recent releases

The latest release is 0.1.23 (milestone 0.1.23). The server code is unchanged since 0.1.22.

• The plugin uses vsp360-mcp 0.1.22 (#33).
• CI smoke-tests a standalone package (#32): every pull request builds the Linux x64 package and runs the same smoke test the release runs on the Windows packages.

The release before, 0.1.22 (milestone 0.1.22), fixed the rest of the security review's findings and an extension bug on Windows:

• Security review findings S3–S11 (#24), described on Safety and Security and in SECURITY.md:

  Finding	Change
  S3	The token request never follows a redirect. API requests follow redirects only within VSP360_URL
  S4	vsp360VerifyDirectory is treated as a write, because it makes VSP 360 connect to any LDAP host
  S5	analyticsRunQuery is a read only with action=query
  S6	The two Block SSO operations that return a client secret need VSP360_ALLOW_SECRET_READS
  S7	save_to is checked through symlinks, and refuses hidden folders
  S8	. and .. path parameter values are refused
  S9	max_pages is capped at 200, and responses at VSP360_MAX_RESPONSE_BYTES (64 MiB)
  S10	An http:// VSP360_URL needs VSP360_ALLOW_HTTP=true
  S11	Actions are pinned by SHA and the base image by digest, the Node.js runtime's signed checksums are verified, and Dependabot is on

• Empty optional settings in the Claude Desktop extension (#22, #23): leaving CA certificate or Download folder empty no longer fails every call with ENOENT ... ${user_config.ca_cert}.

• No dependency alerts (#21): the extension packer runs with npx at build time, so tmp and node-forge are out of the lockfile.

Upgrading to 0.1.22 or later: an http:// VSP 360 URL is refused unless you set VSP360_ALLOW_HTTP=true. The directory connection test and analytics actions other than query now need VSP360_ALLOW_WRITES=true. The default read-only setup needs no other changes.

Before that, 0.1.21 made the Claude Code Plugin ready for Anthropic's plugin directory and added the Windows package tests.

0.1.24: multiple VSP 360 instances

One vsp360-mcp server will connect to several VSP 360 instances, for example two data centers, so Claude can query either one or compare them in a single request. Setups with a single VSP 360 keep working unchanged.

Today's workaround

Add one MCP server entry per VSP 360 in your client configuration, each with its own URL and credentials. It works, but every tool definition is loaded once per entry, and Claude can't compare instances in one call.

How it will work

An instances file (VSP360_INSTANCES_FILE) names each VSP 360 and its settings:

{
  "default": "dc1",
  "instances": {
    "dc1": { "url": "https://vsp360-dc1.example.com", "clientId": "mcp-reader", "clientSecretEnv": "VSP360_DC1_SECRET" },
    "dc2": { "url": "https://vsp360-dc2.example.com", "clientId": "mcp-reader", "clientSecretEnv": "VSP360_DC2_SECRET",
             "caCert": "~/certs/dc2-ca.pem" }
  }
}

• Secrets stay out of the file: clientSecretEnv names the environment variable that holds each secret.
• Per-instance settings: each instance can have its own TLS settings, timeout and policy (read-only or writes, secret reads, upload folder). Anything not given falls back to the usual VSP360_* settings.
• No file needed for one VSP 360: without an instances file, VSP360_URL, VSP360_CLIENT_ID and VSP360_CLIENT_SECRET work as now.

Tools

• vsp360_call_operation and the direct tools gain an instance argument: an instance's name, or "all". It's optional when there's one instance or a default.
• A new vsp360_list_instances tool shows each instance's name, host and policy, and on request whether it's reachable and its version.
• Search and describe don't change, and tool definitions are loaded once, however many instances there are.

Comparing instances ("all")

• Reads run on every instance in parallel, and each result is labelled with its instance.
• Combined lists carry an _instance field on every item.
• If one instance is unreachable, the others still answer.
• Writes can't use "all"; a change must name one instance.

Safety

• Each instance has its own read-only, secret-read and upload policy. For example, production can stay read-only while a lab allows writes.
• Each instance keeps its own sign-in token and connection, so credentials never cross instances.
• Text from one instance can't steer a write to another: writes must name their instance, and instances are read-only by default. The safety model in SECURITY.md will cover this.

Files and logs

• Downloads go into a folder per instance.
• The decision log and the startup message record which instance was used.

Before it's built

These still need deciding: the instance names, whether one instance is the default, how each instance's TLS certificate is trusted, and which instances (if any) allow writes. See Configuration and Safety and Security for how settings and safety work today.

0.1.25: the Fleet Management API

When Hitachi Vantara releases its Fleet Management API, vsp360-mcp will add it to the bundled OpenAPI spec, so Claude can reach the new operations the same way as today's.

• The spec: update or extend the bundled spec and rebuild the pre-parsed copy the server starts from.
• Safety: decide which new POST operations only read (and are allowed in read-only mode), and mark any that return credentials.
• Search: add example questions for the new operations, rerun the search evaluation and retrain the learned hint.
• Docs: list the new API areas for VSP360_TOOLSETS, and update this wiki.

The timing depends on Hitachi Vantara's release. Until then, you can point VSP360_SPEC at a newer spec file yourself, as How It Works describes.