Skip to main content
Glama

List Networks

hudu_list_networks
Read-onlyIdempotent

List all IP networks (subnets) documented in Hudu, filtered by company, CIDR address, or other criteria. Returns complete results in one response, no pagination.

Instructions

List networks in Hudu. A network is one IP range documented in Hudu — a subnet in CIDR form, owned by a company, holding the individual ip_address records allocated inside it.

This endpoint documents neither page nor page_size, so there is no paging: the call returns everything matching your filters in a single response. If truncated comes back true the client cut records to stay inside its response budget, and because there is no next page the only ways to see the rest are narrower filters or a shorter fields list.

Filter by company_id when you are working for one customer; instances that document every client hold networks for all of them here. address matches the stored CIDR text, so it finds a subnet you already know the notation of rather than telling you which network a given host falls in — Hudu does not offer containment search. To see what is allocated inside a network, call hudu_list_ip_addresses with network_id set.

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
nameNoMatch against the network name.
slugNoURL slug, if you already know it.
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.
addressNoMatch against the stored CIDR text, e.g. "10.20.0.0/24".
company_idNoReturn only networks owned by this company. The most useful filter here.
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_idNoNumeric id of the Hudu location this network serves, for tenants that split a company across sites. The v1 API exposes no locations endpoint, so this server cannot list or resolve location ids; read an existing network at the same site to find the value.
network_typeNoNetwork type, as an integer. Hudu does not publish what each number means, and the mapping is not derivable from the API — read an existing network on this instance with hudu_list_networks to see which values are in use before setting one.
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?

Despite annotations already declaring readOnly and non-destructive, the description adds substantial behavioral context: no paging (returns everything in one response), the meaning of truncated, the absence of total counts, and the significance of page_was_full as the only honest signal. This goes far beyond the structured annotations and prepares the agent for response interpretation.

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 long but every sentence earns its place. It is structured into logical paragraphs: definition, paging behavior, filtering guidance, and return shape. It is front-loaded with the core purpose and uses precise, non-redundant language throughout. No filler or repetition.

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?

For a 10-parameter list tool with no output schema, the description covers the essential operational facts: no paging, the truncated flag, the lack of total count, the meaning of page_was_full, and the relationship to ip_addresses. It also explains the return shape ('items' plus pagination facts). The description, combined with the rich schema, gives the agent everything needed to use the tool correctly.

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. The description adds semantic value beyond the schema: clarifying that address matches stored CIDR text and does not perform containment search, calling company_id 'the most useful filter here,' and mentioning the fields parameter for keeping large lists small. It doesn't fully compensate for every param, but enriches the most important ones.

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 'List networks in Hudu' and immediately defines what a network is (a CIDR subnet owned by a company). It clearly distinguishes this from related tools by mentioning hudu_list_ip_addresses for viewing allocations inside a network, and the sibling list shows hudu_get_network for a single network. This is a specific verb+resource statement that differentiates from siblings.

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?

Provides explicit when-to-use guidance: filter by company_id when working for one customer, and states that address matches stored CIDR text rather than offering containment search. It also directs users to hudu_list_ip_addresses with network_id to see allocations, effectively naming an alternative. The no-paging caveat also tells users how to adapt filters if truncated, which is practical usage guidance.

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