home / mcp / ibm storage insights mcp server
Provides MCP access to Storage Insights alerts, notifications, systems, and per-system performance data.
Configuration
View docs{
"mcpServers": {
"ibm-ibm-storageinsights-mcpserver": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/si-mcp-server-oss/src/si_mcp_server_oss",
"run",
"server.py"
],
"env": {
"LOG_LEVEL": "<DEBUG|INFO|WARN|ERROR>",
"LOG_FILE_PATH": "<Path to logs>",
"CONFIG_FILE_PATH": "/etc/si-mcp/config.json",
"DEFAULT_SI_API_KEY": "<Your API key>",
"DEFAULT_SI_TENANT_ID": "<Your tenant id>",
"ADDITIONAL_TENANT_API_MAPPING": "<Optional tenant mappings>"
}
}
}
}This MCP server provides a dedicated bridge to IBM Storage Insights observability data, enabling your AI agents to query tenant alerts, notifications, storage systems, and system-level performance metrics through a consistent Model Context Protocol interface. It simplifies integration by exposing a set of tools you can orchestrate from your MCP client to diagnose and observe Storage Insights assets.
You interact with this MCP server through your MCP client to retrieve alerts, notifications, and per-system metrics from Storage Insights. Start the server in stdio mode and connect your MCP client to run commands that fetch tenant data, system details, and performance metrics. You can chain tool calls in your workflow to build observability dashboards, trigger diagnostics, or trigger AI-assisted analysis across multiple storage systems.
Prerequisites: you need the MCP runtime environment (UV) installed on your machine. You also need Storage Insights credentials (tenant ID and API key) with access to the APIs described.
1. Prepare your environment file with Storage Insights credentials.
env
DEFAULT_SI_TENANT_ID = <Your Storage Insights tenant ID>
DEFAULT_SI_API_KEY = <Your Storage Insights External Rest API key>
ADDITIONAL_TENANT_API_MAPPING = <Additional tenant id and API key mapping if you want the server to support multiple tenants (optional)>
LOG_FILE_PATH = <Directory path to store mcp server logs (optional)>
LOG_LEVEL = <Log level fo the configured logger (optional)>
CONFIG_FILE_PATH = <Path to the config file (optional)>2. Create a Claude MCP configuration snippet for the local server. The following config runs the MCP server using the UV runtime in stdio mode.
{
"mcpServers": {
"si_mcp_server": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/si-mcp-server-oss/src/si_mcp_server_oss",
"run",
"server.py"
]
}
}
}3. Run the server and verify it starts without errors. You should see the server begin listening for MCP requests on standard input/output.
Environment and runtime details: the server reads Storage Insights credentials from environment variables. Ensure the following variables are set in your environment or in the .env file you reference when launching the server: DEFAULT_SI_TENANT_ID, DEFAULT_SI_API_KEY, ADDITIONAL_TENANT_API_MAPPING, LOG_FILE_PATH, LOG_LEVEL, and CONFIG_FILE_PATH. The server is designed to run in stdio mode using the UV runtime, but you can configure alternate transport methods if you plan to use streamable HTTP in your deployment.
Testing and debugging: you can use the MCP Inspector during development to observe logs and manually send requests. Start the inspector with the same run command used to start the MCP server to view live logs and test responses.
Notes on usage: the server exposes a set of tools for fetching tenant-level data, system-level details, and performance metrics. You can chain tool calls in your MCP client to obtain a comprehensive observability snapshot across tenants and systems, including alerts, notifications, and various IO/data metrics.
Retrieve a list of alerts for a tenant. Inputs: tenant_id_input (optional). Returns: List of alerts for the tenant.
Retrieve a list of notifications for a tenant. Inputs: tenant_id_input (optional). Returns: List of notifications for the tenant.
Get all storage systems added to the tenant. Inputs: tenant_id_input (optional). Returns: List of storage systems.
Get notifications of a specific system. Inputs: system_id (required), tenant_id_input (optional). Returns: List of system notifications.
Get details for a given system. Inputs: system_id (required), tenant_id_input (optional). Returns: System details.
Get IO rate metrics for a system. Inputs: system_id, tenant_id_input (optional), metric_types (optional), duration (optional). Returns: IO rate metrics such as volume_overall_read_io_rate, volume_overall_write_io_rate, volume_overall_total_io_rate.
Get data rate metrics for a system. Inputs: system_id, tenant_id_input (optional), metric_types (optional), duration (optional). Returns: Data rate metrics such as volume_read_data_rate, volume_write_data_rate, volume_total_data_rate.
Get response time metrics for a system. Inputs: system_id, tenant_id_input (optional), metric_types (optional), duration (optional). Returns: Response time metrics such as volume_read_response_time, volume_write_response_time, volume_total_response_time.
Get transfer size metrics for a system. Inputs: system_id, tenant_id_input (optional), metric_types (optional), duration (optional). Returns: Transfer size metrics such as volume_read_transfer_size, volume_write_transfer_size, volume_total_transfer_size.
Get CPU utilization for a system. Inputs: system_id, tenant_id_input (optional), metric_types (optional), duration (optional). Returns: CPU utilization metric.
Get capacity metrics for a system. Inputs: system_id, tenant_id_input (optional), metric_types (optional), duration (optional). Returns: Used and available capacity.
Get components for a system. Inputs: system_id, comp_type, tenant_id_input (optional). Returns: Requested components such as volumes, pools, enclosures, drives, fc-ports, ip-ports, host-connections, io-groups, managed-disks.
Get alerts for a system. Inputs: system_id, tenant_id_input (optional). Returns: List of system alerts.