Skip to main content
Glama

List Rack Storages

hudu_list_rack_storages
Read-onlyIdempotent

List physical racks (rack storages) in Hudu, filtered by company, location, height, or width, to identify rack cabinets for IT documentation.

Instructions

List rack storages in Hudu. 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.

Filter by company_id for one customer's racks and location_id for one site. height, min_width and max_width filter on the rack dimensions, whose units the API never states — they are still usable for relative comparison against values already in the instance.

No name or free-text search filter is documented. To find a rack by name, list the company's racks and match the name field yourself.

This endpoint documents neither page nor page_size, so this tool sends neither and Hudu answers with everything matching in one response. The envelope reports page_was_full: false and next_page: null accordingly — there is no second page to ask for, and what you get back is the complete set for the filters given. If the result comes back marked truncated, that is this server trimming the response to fit its output budget, not the end of the data; narrow the filters or use fields to see the rest.

Returns an object with items plus pagination facts. Note that the Hudu API returns no total count for any collection, so page_was_full is the only honest signal that more records exist — read pagination_note before concluding a list is complete.

Operation class: Read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNoReturn only these top-level fields on each record. Use it to keep large lists small — e.g. ["id","name","company_id"]. Unknown field names are ignored.
heightNoReturn only racks whose height equals this value exactly. Unit undocumented.
max_widthNoReturn only racks at most this wide. Unit undocumented.
min_widthNoReturn only racks at least this wide. Unit undocumented.
company_idNoReturn only racks belonging to this company, by numeric Hudu company id.
created_atNoISO-8601 range as "start,end". Either side may be omitted — "2026-01-01T00:00:00Z," means everything since that moment, ",2026-01-01T00:00:00Z" everything before it. A bare timestamp with no comma matches that exact moment.
updated_atNoISO-8601 range as "start,end". Either side may be omitted — "2026-01-01T00:00:00Z," means everything since that moment, ",2026-01-01T00:00:00Z" everything before it. A bare timestamp with no comma matches that exact moment.
location_idNoReturn only racks at this location. No endpoint lists locations, so this id has to come from a rack you have already read.
response_formatNoOutput shape. 'json' (default) is compact and machine-readable; 'markdown' is easier for a person to read but larger.json
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds substantial behavioral context beyond that: pagination is not supported (no page/page_size sent), the endpoint returns everything in one response, page_was_full will be false, and 'truncated' indicates server-side trimming rather than the end of data. It also discloses that no total count is ever returned, which is crucial for interpreting list completeness.

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

Conciseness5/5

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

The description is relatively long but every sentence earns its place. It is well-structured: definition first, then filters, then pagination behavior, then return shape. No unnecessary words or repetition; each paragraph addresses a distinct aspect needed to invoke the tool correctly.

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?

Given there is no output schema, the description fully covers the return value (an object with items plus pagination facts), explains the pagination flags (page_was_full, next_page, truncated), and warns about the lack of total count. It also covers edge cases like missing name search and undocumented units, making it complete for a list endpoint with no schema.

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

Parameters5/5

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

Although parameter descriptions in the schema cover 100% of the parameters, the description adds extra semantics beyond the schema: it explains that dimension units are undocumented and only useful for relative comparison, and it clarifies that location_id must be obtained from an already-read rack because no endpoint lists locations. This enriches the agent's understanding of how to use the parameters correctly, going beyond the schema's descriptions.

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 clearly states this lists rack storages, defines the resource (physical racks in server rooms), and explicitly distinguishes it from rack storage items by naming the sibling hudu_*_rack_storage_item tools. The verb+resource+scope is specific and unambiguous, leaving no doubt what the tool does.

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

Usage Guidelines5/5

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

The description provides explicit usage context: filter by company_id/location_id for one customer/site, notes that no name/free-text search is available and tells the user how to match by name manually, and mentions that equipment is modelled separately via the rack_storage_item tools. It effectively explains when to use this tool and what alternatives/approaches exist.

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