Skip to main content
Glama

Update Asset

hudu_update_asset
Idempotent

Update an existing Hudu asset by replacing supplied fields. Requires the owning company ID and asset ID; each provided value overwrites the stored one, so fetch the asset first to avoid data loss.

Instructions

Update an existing asset. An asset is any documented thing that belongs to a company — a server, a workstation, a firewall, a licence, a contact. The asset layout it was created from decides which custom fields it carries.

Assets are read globally but written per company. This tool needs the owning company id as well as the asset id, because Hudu exposes no /assets/{id} route. If you found the asset with hudu_list_assets, take company_id straight from that record; if all you have is an asset id, call hudu_list_assets with id set to it and read company_id off the result.

Only the arguments you supply are sent, but each one replaces the stored value outright — this is a PUT, not a merge. Read the asset with hudu_get_asset first whenever you intend to add to a field rather than overwrite it. The same applies to custom_fields: send the full label/value set you want the asset to end up with.

Operation class: Update. Impact: Overwrites the supplied fields on this asset with the values given.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesNumeric id of the asset, as returned by hudu_list_assets or hudu_list_company_assets.
nameNoDisplay name of the asset, e.g. a hostname.
company_idYesNumeric id of the company that owns this asset. Not optional and not guessable — an asset id belonging to company A returns 404 under company B, indistinguishable from a deleted asset.
primary_mailNoPrimary email address associated with the asset.
custom_fieldsNoValues for the custom fields the asset layout defines, as an array holding one object that maps field label to value: [{"brand": "Apple", "model": "MacBook Pro"}]. Each key is a layout field label in snake_case — lower-cased with spaces replaced by underscores, so a field labelled "Serial Number" is the key "serial_number" — and Hudu requires each key to match a field that already exists on the layout given by asset_layout_id. Call hudu_get_asset_layout first to read the exact labels. Values are documented as strings, so send numbers and dates as strings ("42", "2026-01-01"). Note the asymmetry with reads: a fetched asset returns this data under `fields` as {id, label, value, position} objects, which is not a shape this parameter accepts — rebuild the label/value pairs yourself rather than sending back what you read.
primary_modelNoHardware or product model.
primary_serialNoSerial number shown at the top of the asset.
asset_layout_idNoNumeric id of the asset layout this asset uses. The layout is the template that decides which custom fields the asset has; list the choices with hudu_list_asset_layouts.
primary_manufacturerNoManufacturer or vendor name.
Behavior5/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds substantial context: each supplied argument replaces the stored value outright (PUT, not merge), and reads with hudu_get_asset are recommended before adding to fields. It also discloses the 404 behavior for company mismatches, adding value beyond the structured hints.

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?

Though long, every paragraph serves a purpose: definition, required parameters, behavior (PUT), custom_fields shape, and impact statement. It is front-loaded with the main purpose and organized logically. No filler or tautology.

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 tool with 9 parameters and complex semantics, the description covers prerequisites (company_id, id), overwrite semantics, custom_fields format, asset layout coupling, and guidance for safe updates. There is no output schema, so the description's omission of return value is acceptable; essential knowledge is fully addressed.

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 baseline is 3. The description adds extra semantics for custom_fields by explaining the exact expected shape, the label-to-snake_case conversion, the need to send full label/value sets, and the asymmetry with read responses. This goes beyond the schema, justifying a 4.

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 asset' and then defines what an asset is, making the verb and resource explicit. It clearly distinguishes itself from siblings like hudu_create_asset and hudu_archive_asset by specifying 'existing' and 'Update' operation class.

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 gives explicit when-to-use guidance: 'This tool needs the owning company id as well as the asset id' and instructs how to obtain it via hudu_list_assets. It also tells when to use hudu_get_asset first ('whenever you intend to add to a field rather than overwrite it') and explains the PUT vs merge behavior, providing clear alternatives.

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