Skip to main content
Glama

Update Asset Layout

hudu_update_asset_layout
Idempotent

Update an asset layout's name, icon, color, active flag, and file/photo/password/comment toggles. Only sent fields are applied and replace old values, so fetch the layout first.

Instructions

Update an existing asset layout. An asset layout is the template behind an asset type: its icon and colour, whether its assets can hold passwords, photos, comments and files, and the set of custom fields every asset of that type carries. Layouts are instance-wide rather than per-company. Field definitions can be set when a layout is created; the documented shape for changing them afterwards contradicts the shape creation accepts, so this server does not expose field edits on update. There is no delete endpoint for layouts — set active: false to retire one.

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

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesNumeric Hudu id of the asset layout.
iconNoFont Awesome icon class shown next to assets of this type, e.g. "fas fa-server".
nameNoName of the layout, e.g. "Server" or "Licence".
colorNoBackground colour as a hex code, e.g. "#2E86C1".
activeNofalse retires the layout without deleting it. Layouts have no delete endpoint, so this is the only way to take one out of use.
icon_colorNoIcon colour as a hex code, e.g. "#FFFFFF".
include_filesNoWhether assets of this type can hold file attachments.
include_photosNoWhether assets of this type can hold photos.
password_typesNoPassword categories offered on assets of this type, as one string with each category on its own line (newline-separated, not an array).
include_commentsNoWhether assets of this type can hold comments.
include_passwordsNoWhether assets of this type can hold linked passwords.
Behavior5/5

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

The description discloses meaningful behavioral traits beyond annotations: PUT semantics where sent fields replace old values outright, only supplied fields are sent, field definitions are not editable on update, and layouts are instance-wide. This adds substantial context not present in the sparse annotations.

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 somewhat lengthy but well-organized into paragraph sections with a clear opening purpose statement. Every sentence carries relevant information (caveats, alternatives, operational behavior), so it is justified despite being above average length.

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 tool's behavior, constraints, and relationships to sibling tools. Although there is no output schema and the return value is not explicitly stated, the operational impact and update semantics are clearly described, making the tool reasonably complete for an update operation.

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 provides 100% coverage with detailed descriptions for all parameters. The description adds a general note about partial updates and PUT replacement, but does not enrich individual parameter semantics beyond what the schema already states. Baseline 3 is appropriate.

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 layout,' a specific verb+resource, and then elaborates on what an asset layout is. It clearly distinguishes from creation (field definitions only set at creation) and deletion (no delete endpoint), making its scope unambiguous.

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?

Explicit guidance is provided: use this tool for updating fields, but not field definitions (reserved for creation); retire layouts by setting active:false since no delete endpoint exists; and read first with hudu_get_asset_layout before updating to avoid overwriting. This gives clear when-to-use and 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