Click on "Install 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., "@svc-mcp-server List all volumes"
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.
IBM SAN Volume Controller (SVC) 用の Model Context Protocol (MCP) サーバーです。 このサーバーを使用すると、IBM Bob などの AI アシスタントから SVC ストレージシステムを操作できます。
このMCPサーバーは以下の操作をサポートしています：
システムステータス確認 (check_system_status): SVCシステムの状態を確認（lssystemコマンドを実行）
汎用コマンド実行 (execute_svc_command): 任意のSVC CLIコマンドを直接実行できる汎用ツール。lsvdisk、lshost、mkvdiskなど、あらゆるSVCコマンドに対応
Related MCP server: IBM Storage Insights MCP Server
Node.js 18以上
npm または yarn
IBM SVC へのSSHアクセス権限
リポジトリをクローン：
git clone <repository-url>
cd svc-mcp-server依存関係をインストール：
npm installプロジェクトをビルド：
npm run build.env.template をコピーして .env ファイルを作成します：
cp .env.template .env.env ファイルを編集して、SVC接続情報を設定します：
# SVC ホスト名またはIPアドレス（必須）
SVC_HOST=your-svc-host.example.com
# SVC SSHポート（デフォルト: 22）
SVC_PORT=22
# SVC SSH ユーザー名（デフォルト: superuser）
SVC_USERNAME=superuser
# SVC SSH パスワード（パスワード認証を使用する場合）
SVC_PASSWORD=your-password
# SVC SSH 秘密鍵のパス（鍵認証を使用する場合）
SVC_PRIVATE_KEY_PATH=/path/to/svc/private/key
# SSHプロキシ設定（SSHトンネル経由で接続する場合）
SVC_PROXY_HOST=proxy.example.com
SVC_PROXY_PORT=22
SVC_PROXY_USERNAME=proxy-user
SVC_PROXY_PASSWORD=proxy-password
SVC_PROXY_PRIVATE_KEY_PATH=/path/to/proxy/private/keySVC認証方法：
パスワード認証: SVC_PASSWORD を設定
鍵認証: SVC_PRIVATE_KEY_PATH を設定
どちらか一方を設定してください
SSHプロキシ認証方法：
パスワード認証: SVC_PROXY_PASSWORD を設定
鍵認証: SVC_PROXY_PRIVATE_KEY_PATH を設定
どちらか一方を設定してください
プロキシを使用しない場合は、これらの設定を省略できます
IBM Bob の設定ファイル（.bob/mcp.json）を作成します：
cp .bob/mcp.json.example .bob/mcp.json.bob/mcp.json を編集して、SVC接続情報を設定します：
{
"mcpServers": {
"svc": {
"command": "node",
"args": ["${PWD}/build/index.js"],
"env": {
"SVC_HOST": "your-svc-hostname",
"SVC_PORT": "22",
"SVC_USERNAME": "superuser",
"SVC_PASSWORD": "your-password",
"SVC_PRIVATE_KEY_PATH": "/path/to/svc/private/key",
"SVC_PROXY_HOST": "your-proxy-hostname",
"SVC_PROXY_PORT": "22",
"SVC_PROXY_USERNAME": "proxy-username",
"SVC_PROXY_PASSWORD": "proxy-password",
"SVC_PROXY_PRIVATE_KEY_PATH": "/path/to/proxy/private/key"
}
}
}
}SSHプロキシについて：
このMCPサーバーは、SSHトンネル（ポートフォワーディング）を使用してプロキシ経由でSVCに接続します
プロキシサーバーへのSSH接続が確立された後、そのトンネルを通じてSVCへ接続します
プロキシ認証は、パスワード認証または鍵認証のどちらかを使用できます
プロキシを使用しない場合は、プロキシ関連の設定を省略してください
または、.env ファイルを使用する場合（環境変数が自動的に読み込まれます）：
{
"mcpServers": {
"svc": {
"command": "node",
"args": ["${PWD}/build/index.js"]
}
}
}設定を反映するため、IBM Bob を再起動してください。
IBM Bob で以下のようなプロンプトを使用できます：
SVCシステムのステータスを確認してくださいすべてのボリュームをリストアップしてくださいpool1に100GBのボリュームを作成してください。名前はtest_vol01ですtest_vol01という名前のボリュームの詳細情報を表示してください登録されているすべてのホストを表示してくださいhost1という名前のホストの詳細情報を確認してください最新のイベントログを表示してくださいすべてのストレージプールの使用状況を確認してください注意: execute_svc_command ツールを使用することで、上記以外のあらゆるSVC CLIコマンドを実行できます。IBM Bobに自然言語で指示すると、適切なSVCコマンドに変換して実行します。
npm run buildnpm startSVC_HOST が正しく設定されているか確認
ネットワーク接続を確認
SSHプロキシを使用する場合：
SVC_PROXY_HOST と SVC_PROXY_PORT が正しく設定されているか確認
プロキシへのSSH接続が可能か確認（ssh user@proxy-host でテスト）
プロキシ認証情報（パスワードまたは秘密鍵）が正しいか確認
プロキシサーバーからSVCホストへの接続が許可されているか確認
ユーザー名とパスワード/秘密鍵が正しいか確認
SSH接続が許可されているか確認
SVCユーザーに適切な権限があるか確認
コマンド構文が正しいか確認
.env ファイルは .gitignore に含まれており、Gitリポジトリにコミットされません
パスワードや秘密鍵は安全に管理してください
本番環境では、秘密鍵認証の使用を推奨します
本コードは現状有姿（AS-IS）で公開しており、動作保証はありません。検証環境等で十分テストの上、自己責任でご利用ください
Check SVC system status (lssystem)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only reveals the underlying command (lssystem) but does not state whether this operation is read-only, requires authentication, or has any side effects. The agent has no information on consequences.
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?
The description is very short but fits the tool's simplicity. It front-loads the action and mentions the underlying command. It could be slightly more self-contained without relying on the parentheses notation.
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?
For a simple status check tool, the description provides adequate purpose but lacks context on output/return values, whether the command can fail, and how it differs from the sibling tool. An agent would have to guess the output format.
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?
The tool has zero parameters and schema coverage is 100%, so there is little for the description to add. The description confirms the tool takes no input, which is useful. A baseline of 4 is appropriate.
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 description states that the tool checks system status, which is a clear verb-resource combination. However, it does not distinguish this from its sibling tool 'execute_svc_command' – both could plausibly be used to run a command like lssystem, creating ambiguity.
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?
No guidance is provided on when to use this tool versus 'execute_svc_command'. Without any usage context, an agent cannot determine whether this tool is safer, more limited, or preferred for read-only queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute any SVC CLI command. This is a generic tool that allows you to run any SVC command directly.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The SVC CLI command to execute (e.g., "lsvdisk", "lshost", "mkvdisk -mdiskgrp pool0 -size 10 -unit gb -name vol1") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits such as destructive potential, authentication requirements, output format, and error behavior. It only says 'execute any SVC CLI command', which implies high risk but does not warn about possible destructive actions (e.g., 'rmvolume', 'rmhost') or output variability. This is a critical gap for a generic execution tool.
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?
The description is very short (two sentences) and front-loaded. It wastes no words, though one sentence could be removed by merging the two.
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 the tool executes arbitrary CLI commands with no output schema and no behavioral transparency, the description is insufficient. It should cover safety warnings, expected output, required permissions, and when to prefer the sibling tool. The current text does not meet the needs of an agent deciding whether to invoke this tool.
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 description coverage is 100%, so the parameter is fully documented in the schema. The description only adds the phrase 'any SVC command' which is already conveyed by the schema's dynamic example. Baseline 3 is appropriate.
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 description clearly states the tool executes SVC CLI commands and highlights its generic nature. It differentiates from check_system_status by being a catch-all execution tool.
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 description provides no guidance on when to use this tool versus check_system_status, nor does it mention any prerequisites, limitations, or when alternatives should be preferred. The agent is left without usage boundaries.
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. Dates show when Glama detected each change.
v1.0.0check_system_statusexecute_svc_commandThe two tools have clearly distinct purposes: one checks overall system status, and the other executes arbitrary SVC commands. There is no ambiguity between them.
Both tools use a verb_noun pattern (check_system_status, execute_svc_command) which is consistent. Minor deviation is that the noun phrases are of different lengths, but it's still readable.
With only 2 tools, the server feels underdeveloped for any practical SVC management use case. While a check + generic execute pattern can work in principle, it suggests the tool surface is very thin.
The generic execute_svc_command tool compensates for missing specific operations, but the server lacks dedicated tools for common tasks like listing volumes, managing hosts, or creating storage pools. The set is not complete for typical SVC administration workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Manage Rackspace Spot Kubernetes Cloudspaces, node pools, and VMs from your AI assistant.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cu0001/svc-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
