Skip to main content
Glama

Update Rack Storage Item

hudu_update_rack_storage_item
Idempotent

Update an existing rack storage item in Hudu to change its mounted asset, unit positions, side, or power details.

Instructions

Update an existing rack storage item. A rack storage item is one thing mounted in a rack: it points at the Hudu asset it represents, occupies the units from start_unit to end_unit on one side of the rack, and carries its own power figures. The rack itself is a rack storage — use the hudu_*_rack_storage tools for the cabinet.

Only the fields you supply are sent. Be aware that Hudu applies these as a PUT: for fields you do send, the new value replaces the old one outright — read the record first with hudu_get_rack_storage_item if you intend to append rather than overwrite.

Operation class: Update. Impact: Overwrites the supplied fields on this rack storage item.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesNumeric Hudu id of the rack storage item.
sideNoWhich face of the rack the item is mounted on. The spec contradicts itself on this field: the list filter documents it as the string "Front" or "Rear", while the create and update body documents it as an integer with no published mapping. This argument follows the body and takes an integer. The only reliable way to learn which integer means which face is to read an item you know the physical side of with hudu_get_rack_storage_item.
statusNoStatus code for the item, as an integer. Hudu publishes no list of legal values and no meaning for any of them, so copy a value from an existing item instead of choosing a number.
asset_idNoNumeric id of the Hudu asset this mounted item represents — the device record carrying the serial, model and custom fields. Resolve it with hudu_list_assets, or read it with hudu_get_asset. The item record also returns asset_name and asset_url for display; those are outputs, not ways to identify the asset when writing.
end_unitNoThe other end of the unit range this item occupies. Two properties of this range are not documented, and assuming either will place hardware in the wrong slot. First, direction: the API never says which physical end of the cabinet holds the lowest-numbered unit, so bottom-up and top-down are equally consistent with the spec. Second, inclusivity: it does not say whether a 2U device starting at unit 10 ends at 11 or at 12. Read an existing item from the same rack with hudu_list_rack_storage_items, compare it against hardware whose height you already know, and follow whatever convention that instance uses. Overlap is undocumented too — no conflict response is published for these endpoints, and create and update document only 422 "Unable to process request" — so do not rely on Hudu refusing to double-book a unit.
company_idNoNumeric id of the company this item belongs to. Note that the list tool documents no company filter, so this scopes the record without giving you a way to select on it later.
power_drawNoPower this item draws, for planning against the rack's `max_wattage`. The spec gives no unit for it at all. Hudu states no unit for this number, so it is comparable with other values from the same instance and with nothing else.
start_unitNoOne end of the unit range this item occupies, in the rack's own numbering, which begins at that rack's `starting_unit` and so is not necessarily 1-based. Two properties of this range are not documented, and assuming either will place hardware in the wrong slot. First, direction: the API never says which physical end of the cabinet holds the lowest-numbered unit, so bottom-up and top-down are equally consistent with the spec. Second, inclusivity: it does not say whether a 2U device starting at unit 10 ends at 11 or at 12. Read an existing item from the same rack with hudu_list_rack_storage_items, compare it against hardware whose height you already know, and follow whatever convention that instance uses. Overlap is undocumented too — no conflict response is published for these endpoints, and create and update document only 422 "Unable to process request" — so do not rely on Hudu refusing to double-book a unit.
max_wattageNoPower ceiling recorded for this mounted item. As with the rack field of the same name, the spec names the quantity as wattage but never states the unit. Hudu states no unit for this number, so it is comparable with other values from the same instance and with nothing else.
reserved_messageNoFree-text message carried on the item. The spec documents it only as "the reserved message for the rack storage item" and says neither when Hudu displays it nor what marks an item as reserved.
rack_storage_role_idNoNumeric id of the "rack storage role" this item takes. Read this carefully: it is NOT the rack the item sits in. The spec documents it as "the unique ID of the rack storage role", and the item record echoes rack_storage_role_name, rack_storage_role_description and rack_storage_role_hex_color beside it, so a role behaves as a named, colour-coded classification of the mounted thing. No endpoint lists the available roles and no schema defines one, so take an id from an existing item via hudu_list_rack_storage_items rather than expecting to look one up.
Behavior5/5

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

The description goes well beyond the annotations by explaining that Hudu applies a PUT semantics – only the supplied fields are sent, and each supplied field replaces the old value outright. It advises reading the record first before appending. This is critical behavioral context not captured by the annotations, and it fully aligns with the annotation hints.

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?

The description is well-structured with a clear first sentence stating purpose, followed by a definition of the resource, a PUT behavior warning, and an impact statement. It's a bit longer than necessary but every sentence adds value, especially given the complexities around overwrite semantics.

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

Completeness4/5

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

The description covers the crucial behavioral aspects (PUT, read-before-append, cabinet vs. item) and the schema covers all parameter details. There is no output schema, but the description doesn't need to explain return values. It could mention the need to copy certain IDs (status, role) from existing items, but the schema already does that. Overall, it's complete for a complex update tool.

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 description coverage is 100% and the schema itself provides extremely detailed per-parameter descriptions, including warnings about ambiguities in 'side', 'status', and unit ranges. The tool description adds a summary of what the item represents and the global PUT behavior, but it doesn't need to repeat parameter-specific details. The baseline of 3 applies.

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

Purpose5/5

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

The description opens with 'Update an existing rack storage item' – a specific verb and resource. It then defines what a rack storage item is and explicitly distinguishes the rack cabinet as a separate entity via 'use the hudu_*_rack_storage tools for the cabinet', making it clear this tool is for the item, not the cabinet.

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

Usage Guidelines4/5

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

The description tells the user to read the record first with hudu_get_rack_storage_item if they intend to append rather than overwrite, and points to hudu_*_rack_storage tools for the cabinet. It doesn't explicitly state when to use update vs. create, but the 'existing' in the first sentence implies creating new items should use the create tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZenixSolutions/hudu-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server