Skip to main content
Glama
Sign In
proliant-mcp

proliant-mcp

by hjma29
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get Firmware Inventory

get_firmware_inventory
Read-onlyIdempotent

Retrieve all firmware components and versions for a specified HPE ProLiant server via iLO—including BIOS/System ROM, NICs, storage controllers, drives, and CPLD—to verify installed firmware levels.

Instructions

All firmware components and versions (iLO, BIOS/System ROM, NICs, storage controllers, drives, CPLD, ...).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "server": "<server>"
    },
    "name": "get_firmware_inventory"
  }
}

Input Schema

NameRequiredDescriptionDefault
serverYesServer name from list_servers (or its iLO host/IP).

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, covering the safety profile. The description adds nothing beyond that — no note on whether the iLO must be reachable/authenticated, how failures surface, or how long a full component sweep takes; its content is essentially a listing of returned fields, which the output schema already provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short, front-loaded line with no filler, and the component enumeration earns its place by scoping the result set. It is a sentence fragment rather than a complete statement, which slightly weakens structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full input schema, an output schema and complete annotations, the definition is adequate to invoke the tool correctly. What it omits is routing context — when an agent should pick this over get_ilo_info or get_server_summary — leaving a real gap for a fleet with many overlapping read tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is documented as 'Server name from list_servers (or its iLO host/IP)', which is more than the description offers. The description contributes no additional meaning about the server argument, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (firmware inventory) and enumerates the covered component classes (iLO, BIOS/System ROM, NICs, storage controllers, drives, CPLD), which lets an agent distinguish it from siblings like get_ilo_info or get_health. It lacks an explicit verb and never says it is scoped to a single server, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of alternatives such as get_ilo_info or get_server_summary, and no stated prerequisites. The agent must infer from the name alone that this is the tool for firmware version queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools