Skip to main content
Glama

Update Network

hudu_update_network
Idempotent

Update an existing network's fields in Hudu, such as name, CIDR address, owning company, or notes. Because Hudu overwrites supplied fields, read the current record first to avoid losing data.

Instructions

Update an existing network. 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.

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

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesNumeric Hudu id of the network.
nameNoName of the network as people refer to it, e.g. "Head Office LAN" or "Guest WiFi".
addressNoThe network as a CIDR block — the whole range, not one host. "10.20.0.0/24", "192.168.1.0/24", "2001:db8::/64". A single address belongs on an ip_address record instead; see hudu_create_ip_address.
company_idNoNumeric id of the company that owns this network. Resolve a customer name to an id with hudu_list_companies first.
descriptionNoFree-text notes about the network — its purpose, VLAN, gateway, whatever helps.
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.
Behavior5/5

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

The description discloses the PUT semantics: 'for fields you do send, the new value replaces the old one outright' and 'Only the fields you supply are sent'. This is critical non-obvious behavior beyond the annotations, which only indicate readOnlyHint false and destructiveHint false. It also clearly states 'Impact: Overwrites the supplied fields'.

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 concise and well-structured: three short paragraphs each focusing on a distinct aspect—definition, update semantics, and impact. No fluff or redundancy, and the opening sentence immediately states the purpose.

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 thoroughly covers the update behavior and suggests related tools for reading and resolving parameters. It lacks an explicit description of the return value, but since there is no output schema and the operation is an update, the impact is clearly stated and sufficient for most use cases.

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 has 100% coverage, with each parameter already described in detail (e.g., address as CIDR block, company_id resolved via hudu_list_companies). The description adds general field-update semantics but no per-parameter meaning beyond what the schema already provides.

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 network', clearly specifying the verb and resource, and further defines what a network is (one IP range in CIDR form). This distinguishes it from hudu_create_network and hudu_get_network, which are 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 important usage context: only supplied fields are sent, and it explicitly recommends reading the record with hudu_get_network before appending to avoid overwriting. It implicitly differentiates from create by focusing on 'existing network', but does not explicitly state when not to use this 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