Dell PowerEdge Fan Manager MCP Server - Read CPU/sensor temperatures and control Dell PowerEdge fan speed via IPMI
The Fan Manager MCP server has 4 tools with basic definitions but significant quality gaps. Tool naming follows verb-noun convention (get_temp, set_fan, auto_set_fan_speed, get_core_temp) which is acceptable. However, descriptions are minimal (avg 110 chars, baseline is 194), parameter descriptions are sparse or missing, and output schemas are not documented. The tools lack error recovery guidance, and several parameter constraints are not explicitly stated. No tool implements idempotent operation patterns or permission gating. The definitions are functional but would not pass production code review.
Adjust fan speed automatically from the current temperature (CONCEPT:FM-OS.governance.service-writes-fan-level). Takes min/max temperature thresholds and fan speed ranges to automatically determine optimal fan level.
Chassis info/control: status | identify | bootdev | restart_cause | poh (CONCEPT:FM-OS.governance.power-chassis).
Get the highest core temperature from the specified CPUs (CONCEPT:FM-OS.governance.service-reads-temperature-through). Pure computation over a supplied sensors mapping (no shell-out). Returns a dictionary with response, command, and status.
Get the current CPU temperature (CONCEPT:FM-OS.governance.service-reads-temperature-through). Reads the host's sensors via the injected CommandRunner (defaulting to a real sensors -j shell-out) and returns the hottest core temperature.
BMC LAN: print | set (param+value, e.g. ipaddr/netmask/defgw/access) (CONCEPT:FM-OS.config.bmc-config-lan-user).
Management controller: info | reset_cold | reset_warm | selftest (CONCEPT:FM-OS.config.bmc-config-lan-user).
Output schemas not documented. Callers cannot infer what fields the tools return or how to chain results to downstream operations.
get_core_temp has unclear input semantics. The 'sensors' parameter is a raw dict with no documentation of expected structure. LLMs cannot determine what data to pass.
set_fan description does not document the destructive/write nature. No confirmation step or dry-run capability. Description should state 'Modifies hardware fan speed, irreversible action'.
auto_set_fan_speed lacks error recovery guidance in description. Code shows fallback to maximum_fan_speed on temp read failure, but description does not explain this behavior or what LLM should do if it fails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 17 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Chassis power control: status | on | off | cycle | reset | soft (CONCEPT:FM-OS.governance.power-chassis).
Send a raw IPMI command, e.g. data='0x30 0x30 0x01 0x00' (CONCEPT:FM-OS.governance.raw).
System Event Log: list | elist | info | clear (CONCEPT:FM-OS.governance.event-log).
Sensor readings: list (sdr list) | full (sensor list) | type (sdr type <T>) (CONCEPT:FM-OS.governance.sensors).
Set the fan speed to the specified level (CONCEPT:FM-OS.governance.service-writes-fan-level). Validates fan_level (0-100) and drives the BMC through the injected CommandRunner (defaulting to ipmitool raw commands).
Serial-over-LAN: info | deactivate (CONCEPT:FM-OS.governance.serial-over-lan). Interactive 'activate' is not exposed via MCP.
BMC users: list | set_password | enable | disable (CONCEPT:FM-OS.config.bmc-config-lan-user). user_id required for the last three; set_password takes password parameter.
No parameter validation constraints documented. set_fan accepts 0-100 but description does not explicitly state range. auto_set_fan_speed accepts numeric minimums/maximums with no bounds stated (e.g., can you pass negative temps? 10000°C?).
get_temp and auto_set_fan_speed descriptions are under 50 chars and lack context. 'Get the current CPU temperature' does not explain WHEN to call it vs get_core_temp, what it returns, or prerequisites (must run on Dell PowerEdge with sensors installed).
No idempotency declaration. set_fan and auto_set_fan_speed modify hardware state. If an agent retries due to ambiguous failure, the tool may apply the fan level twice. No note in description that repeated calls with same params are safe.
Hardcoded CPU identifiers in code ('coretemp-isa-0000', 'coretemp-isa-0001'). Tool does not expose these as parameters, limiting flexibility. LLM cannot query other CPUs or multi-socket systems.