Skip to main content
Glama

Update Rack Storage

hudu_update_rack_storage
Idempotent

Update an existing rack storage in Hudu by its numeric id, setting fields like name, height, width, company, location, or max wattage. Only supplied fields are overwritten; read the record first to avoid accidental data loss.

Instructions

Update an existing rack storage. A rack storage is a physical rack — a cabinet in a server room — owned by a company and standing at a location, with a height, a width, a starting unit number and a maximum wattage. It is the container only: the equipment mounted in it is modelled separately as rack storage items, via the hudu_*_rack_storage_item tools.

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 if you intend to append rather than overwrite.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesNumeric Hudu id of the rack storage.
nameNoName of the rack as a person would refer to it, e.g. "DC1 Row A Cabinet 3".
widthNoHow wide the rack is. Hudu states no unit for this number, so it is comparable with other values from the same instance and with nothing else.
heightNoHow tall the rack is. The spec says only "the height of the rack storage" and gives no unit; rack height is conventionally a count of rack units, but the API does not confirm that. Read an existing rack and compare it against known hardware before trusting the interpretation.
company_idNoNumeric id of the company that owns this rack. Resolve a customer name to an id with hudu_list_companies first.
descriptionNoFree-text description of the rack.
location_idNoNumeric id of the location the rack physically stands in. This API publishes no locations endpoint at all, so there is nothing to look the id up in — take it from an existing rack at the same site via hudu_list_rack_storages.
max_wattageNoPower the rack is documented as being able to handle. The spec names the quantity ("the maximum wattage the rack storage can handle") but never states the unit, so whether it is watts or kilowatts is not published — match an existing rack rather than converting. Compare it against the `power_draw` of the items mounted inside; Hudu documents no automatic check of one against the other.
starting_unitNoThe number this rack's own unit numbering begins at, which is why an item's start_unit is not necessarily 1-based. The spec documents nothing further — not which physical end of the cabinet that unit is, and not what Hudu uses when the field is omitted.
Behavior5/5

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

The description discloses a critical behavioral trait: Hudu uses PUT semantics, so supplied fields replace old values outright, and it advises reading the record first. It also clarifies that the tool operates on the container only, not the equipment inside. This goes well beyond the annotations (readOnlyHint=false, idempotentHint=true) and provides actionable context.

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 and front-loaded with the core purpose. It includes necessary domain definitions and critical update semantics, but the final 'Operation class: Update. Impact: Overwrites...' statement is somewhat redundant with the earlier PUT explanation. Overall, it is efficient for the complexity of the tool.

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?

For a complex tool with 9 parameters, the description provides thorough domain context, clarifies the scope, and explains the PUT behavior. However, it does not mention what the tool returns (e.g., the updated record or a success status), which would be helpful given there is no output schema. The lack of error behavior or edge-case handling is a minor gap.

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?

The input schema already has 100% coverage with rich descriptions for all parameters, including caveats about units and lookup methods. The description adds no parameter-specific details beyond the schema; it only notes that only supplied fields are sent, which is already implied by the PUT semantics. The baseline for high schema coverage is 3, and this description does not elevate it.

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 clear verb+resource combination: 'Update an existing rack storage.' It goes on to define what a rack storage is and explicitly distinguishes it from rack storage items, which are handled by separate tools. This makes the tool's purpose unambiguous and differentiates it from sibling tools.

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 provides clear guidance on when to use the tool: updating an existing rack storage, and it warns to read the record first with hudu_get_rack_storage if appending is intended. It does not explicitly name hudu_create_rack_storage as the alternative for creating, but the context of 'update existing' versus create makes the usage clear.

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