Skip to main content
Glama

Create Rack Storage Item

hudu_create_rack_storage_item

Create a rack storage item in Hudu to represent a device mounted in a rack, specifying its unit range, side, and power draw.

Instructions

Create a new rack storage item in Hudu. 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.

Returns the created record, including the id Hudu assigned. Hudu answers 422 with the offending field named when validation fails.

Operation class: Create.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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?

Beyond annotations (readOnlyHint=false, etc.), the description discloses important behaviors: it returns the created record with the assigned id, Hudu returns 422 with the offending field on validation failure, and it labels 'Operation class: Create.' The parameter descriptions further disclose undocumented pitfalls like unit direction, inclusivity, and lack of conflict detection, greatly exceeding what annotations alone could convey.

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 front-loaded with purpose and is well-organized. It is longer than average, but given the complexity and the need to warn about undocumented behaviors, every section serves a purpose. No wasted words; it could be slightly trimmed but remains effective.

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

Completeness5/5

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

This tool has 10 parameters, no output schema, and many undocumented API behaviors. The description compensates fully: it explains return values, error responses, the relationship to rack storage, and how to resolve ambiguous values via sibling tools. This is a complete and actionable description for an agent.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. However, the top-level description adds conceptual meaning by explaining how parameters relate: 'occupies the units from start_unit to end_unit on one side of the rack, and carries its own power figures.' This contextual model enhances understanding beyond individual schema entries, so a 4 is warranted.

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 a specific verb and resource: 'Create a new rack storage item in Hudu.' It defines what a rack storage item is (one thing mounted in a rack) and explicitly distinguishes it from the cabinet itself, stating 'use the hudu_*_rack_storage tools for the cabinet.' This clearly positions the tool against siblings.

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 states when to use this tool versus the rack storage tools, and advises using list/get sibling tools to resolve undocumented conventions (e.g., 'Read an existing item from the same rack with hudu_list_rack_storage_items'). It does not enumerate all alternative tools but gives sufficient context for when this create tool is appropriate.

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