proliant-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ILO_HOST | No | iLO host of a single server, used instead of an inventory file (e.g. 192.0.2.10). | |
| ILO_NAME | No | Optional name for the server configured via environment variables. Defaults to "default". | default |
| ILO_PASSWORD | No | iLO password for the single server configured via environment variables. | |
| ILO_USERNAME | No | iLO username for the single server configured via environment variables (e.g. Administrator). A read-only iLO account is enough. | |
| ILO_VERIFY_SSL | No | Set to 1 to enable TLS verification for the iLO connection. TLS verification is off by default because iLO uses a self-signed certificate. | |
| PROLIANT_MCP_CONFIG | No | Path to an inventory .ini file listing several iLO servers (defaults to ~/.config/proliant-mcp/inventory.ini, and an existing proliant-cli inventory at ~/.config/proliant-cli/inventory.ini is picked up automatically). Set "verify_ssl = true" in the ini to enable TLS verification (self-signed iLO certificates are accepted by default). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Tools for HPE ProLiant servers through their iLO (Redfish) management processor.
Start with list_servers to learn the configured server names, then pass a name as
server. All tools are read-only. If a tool returns an error for a server, report it
and suggest checking that the iLO is reachable; never invent values.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_serversA | List the configured ProLiant servers (name and iLO host). Credentials are never returned. |
| get_ilo_infoB | iLO details: model (iLO 5/6/7), firmware version and date, license, Compute Ops Management connection status, and the iLO's own network (hostname, IP, MAC, DHCP). |
| get_server_summaryB | Server identity and state: model, product ID, serial, power and POST state, health, UID light, BIOS and iLO versions, CPU count/model and total memory. |
| get_fleet_summaryA | get_server_summary for every configured server at once. Unreachable servers are
returned with an |
| get_healthA | Overall and per-subsystem health (processors, memory, storage, network, fans, power supplies, temperatures) plus fan / power-supply redundancy. |
| get_firmware_inventoryC | All firmware components and versions (iLO, BIOS/System ROM, NICs, storage controllers, drives, CPLD, ...). |
| get_processorsB | CPUs (socket, model, cores, threads, speed) and GPUs that iLO reports. |
| get_memoryA | Memory: total GiB, populated/empty slot counts, and each DIMM (slot, size, type, speed, vendor, HPE part number, health). |
| get_storageB | Storage subsystems: controllers (model, firmware), physical drives (model, media, capacity, serial, firmware, bay) and logical volumes / RAID. |
| get_network_adaptersB | Host network adapters: model, part number, slot, firmware, and ports (MAC, link, speed, LLDP neighbor switch/port when available). |
| get_event_logB | Newest entries from the IML or iLO event log, optionally filtered by severity. |
| redfish_getA | Raw read-only GET of any iLO Redfish resource, for data the other tools don't cover. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool targets a distinct resource or granularity, but get_server_summary overlaps meaningfully with get_health, get_processors, get_memory, and get_firmware_inventory, since it reports power/health state, CPU count, total memory, and BIOS/iLO versions. get_fleet_summary is clearly framed as a bulk variant of get_server_summary, and redfish_get is explicitly positioned as the escape hatch for uncovered data.
Eleven of the twelve tools follow a clean verb_noun pattern (list_servers, get_ilo_info, get_firmware_inventory, get_event_log, etc.). The lone deviation is redfish_get, which inverts the order to noun_verb, though it remains readable.
Twelve tools is well within the ideal range and each is scoped to a distinct slice of iLO data (firmware, memory, storage, network, health, events). Nothing feels padded or missing in terms of breadth.
Read-only inventory and health coverage is thorough, including a raw Redfish escape hatch for anything not modeled. However, there are no write/action operations (power control, UID light toggle, log clearing) even though power/UID state is reported, and redfish_get is GET-only so agents have no remediation path.