MCP server rev 01
The administration MCP server lets an AI assistant — Claude Code, the ChatGPT desktop app, Codex, Cursor, VS Code, Claude Desktop configured with a local MCP server, and other MCP-capable clients — manage this storage server on your behalf. An assistant connected to it can inspect and change pools, volumes, datasets, snapshots, shares, iSCSI targets, virtual IPs, the HA cluster, services, users, disks and logs. It does not read or search the contents of your shares and volumes — only the storage server itself.
Note: the MCP Server is delivered as an optional Small Update. This article describes revision 01.
Enabling the server
- Go to System Settings → Administration → MCP Server (it can also be opened from its icon on the launchpad).
- Check Enable MCP server.
- Set the Connection address to the address you want AI clients to use to reach this node — normally its name or address on your local network, for example
https://storage1.example.com:9443. This address becomes part of how a client verifies it is talking to the right server, so use exactly what you intend to type into the client, port included if it is not9443. - Leave Bind address blank to listen on every network interface, or set it to listen on one only.
- Leave Allow dangerous operations and Read-only at their defaults for now — see What the assistant is allowed to do below — and click Save.
The page also shows the state of the Certificate the server will present (see The certificate below), a Download the certificate link, and a Connection page for users link — the same page described next.
What you need first
- The MCP server enabled, as above.
- The exact connection address from the settings page, with
/mcpappended — the address alone sends the client to a page that does not exist. The settings page prints the full address to use once a connection address is saved. - A certificate the client will accept — see below. A browser will let you click past a self-signed or expired certificate; an AI client will not.
- The client running on a computer that can reach this storage server — the same network, or a VPN into it.
Which clients can connect
What decides whether a client can connect is where it runs from, not which vendor makes it:
| Reaches a storage server on your network | |
|---|---|
| Claude Code, Cursor, VS Code, the ChatGPT desktop app's own MCP support, Codex | Yes — these run on your own computer and connect from there |
| claude.ai connectors, ChatGPT connectors, Claude Desktop custom connectors | No — these connect from the provider's cloud, which has no route into your network |
A storage server is normally on a private network, often behind a firewall. Reaching it from a cloud-based connector would need a public address, a public certificate, and a deliberate decision to expose an administration interface to the internet — none of which the local clients above require.
Connecting a client
The address to give the client is the connection address with /mcp appended, for example https://storage1.example.com:9443/mcp.
- Claude Code:
claude mcp add --transport http storage https://<storage-server>:9443/mcp - ChatGPT desktop app: Plugins → MCPs → Add server → Streamable HTTP, then give it a name and that address. Leave any bearer-token or header field empty — the token comes from signing in.
- Codex:
codex mcp add storage --url https://<storage-server>:9443/mcp, thencodex mcp login storage. - Claude Desktop, Cursor, VS Code and other MCP clients: add an HTTP (Streamable HTTP) MCP server with that address.
The certificate
The server presents the same certificate as this web interface. An AI client, unlike a browser, refuses a certificate it cannot verify and offers no way to continue, so its state matters more here than it does for a browser:
- Issued by a certificate authority. Nothing further is needed if the computer running the client already trusts that authority. If it does not — an authority private to your organization, for example — install that authority's certificate on the client machine; installing this server's own certificate does not help.
- Self-signed. The client machine has to be told to trust it. Download it from the connection page (or the settings page's Download the certificate link) and install it:
- Windows, as administrator:
certutil -addstore -f Root storage-server.crt - macOS:
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain storage-server.crt - Linux: copy it to
/usr/local/share/ca-certificates/(with a.crtname) and runsudo update-ca-certificates
- Windows, as administrator:
- Note: installing a certificate tells that computer to trust it for every site, not only this storage server, so install only a certificate you obtained from the storage server itself. The connection page shows its fingerprint so you can check it first.
- Expired. AI clients refuse it outright; installing a copy changes nothing. The certificate must be replaced before any client can connect.
Whichever case applies, the address you give the client must be one of the names the certificate covers — a certificate issued for a host name is not accepted when the client is given an IP address instead, or the other way round. The connection page lists the names the current certificate covers.
Signing in
The first time a client connects, it opens a sign-in page in your browser. The browser and the AI client must be running on the same computer — the page hands the result back to the client on that machine.
Sign in with your storage server account and password, the same one you use for the web GUI. If the account uses two-factor authentication, enter the current code (or one of your backup codes) as well.
What the assistant may then do follows that account: an administrator account gets read and write access (subject to the two switches below); an account with read-only GUI access gets read-only access.
Signing in is a one-off, not something you repeat every session:
- The connection stays signed in for as long as it is used; leaving it unused for 30 days requires signing in again.
- Restarting the storage server, or updating this software, does not sign you out.
- A factory reset clears the sign-in, along with other stored credentials.
If a client reports an authentication error, or asks you to sign in again but gives no way to do it, remove the server from that client and add it back — that discards its stored sign-in and starts a fresh one.
What the assistant is allowed to do
Two switches on the settings page limit what a connected assistant may change:
- Read-only — when enabled, the assistant can view configuration and status but cannot make any changes at all.
- Allow dangerous operations — dangerous operations are those that interrupt service or destroy a pool: rebooting or shutting down the storage server, starting or stopping cluster services, and exporting, destroying or extending a pool. With this switch off, the assistant can still make ordinary changes, including creating and deleting volumes, shares, snapshots and iSCSI targets. To block all changes, use Read-only instead.
What to ask it
The assistant already knows what it can do, so plain questions work: "is this storage server healthy?", "which pool is filling up?", "who is connected over SMB?", "show the SMART status of the disks". It also carries a built-in administration runbook it consults on its own for procedures that need extra care, such as a degraded pool, a pool running low on space, or cluster maintenance.
Ask it to make a change and it will, within the limits of the two switches above and of the account you signed in with.
Some tasks have no equivalent yet for the assistant to use — initial network setup and resetting the administrator password, for example — and still need the text console or the GUI directly.
Clusters
In an HA cluster, each node runs its own MCP server and manages only what is active on that node. Open the connection page on each node and connect the assistant to both; it uses the result from whichever node currently owns a given pool.
Administration skill
The connection page offers a downloadable administration skill package. Most users do not need it: any assistant connected to this server already gets the same cluster procedures from the built-in runbook it consults on its own. Upload the skill instead for an assistant that supports uploaded skills but is not currently connected to this server — for example, one being prepared for a task before it connects — so it can follow the same procedures without a live connection.
If it does not connect
| Symptom | Likely cause |
|---|---|
| The client reports a certificate or TLS error | The certificate is self-signed or expired. Install it (or its issuer's certificate) on the client machine, or replace an expired certificate. |
| The sign-in page never opens, or the connection times out | The client cannot reach the address: wrong network, a firewall, or a cloud-based connector that has no route into your network at all. |
| Sign-in fails with an address mismatch | The address typed into the client differs from the connection address on the settings page. |
| Sign-in is not available | The storage server's REST API does not provide the credential check this module needs — a property of the storage server software installed on this appliance, not of the MCP module. Update that software to a version that provides it. |
| The browser opens but the client never notices | The browser and the client are running on different computers. |
Known issues and limitations
- No data access. The assistant manages the storage server itself; it cannot browse, read or search the contents of your shares or volumes.
- Pre-GUI and recovery tasks are not covered. Initial network configuration, resetting the administrator password and other console-only tasks have no equivalent for the assistant to use yet.
- Cloud-based connectors cannot reach it. claude.ai connectors, ChatGPT connectors and Claude Desktop custom connectors connect from the provider's cloud and cannot reach a storage server on a private network. Use a client that runs on your own computer instead — including Claude Desktop configured with a local MCP server.
Changelog
rev 01
- Initial release: connect an AI assistant to this storage server to administer pools, volumes, datasets, snapshots, shares, iSCSI, virtual IPs, the HA cluster, services, users, disks and logs.
- Sign-in uses your storage server account, including two-factor authentication where the account has it enabled.
- Read-only and Allow dangerous operations switches control what changes a connected assistant may make.
- In an HA cluster, each node runs its own server; connect the assistant to both.
For background on the protocol itself, see the Model Context Protocol documentation.