Skip to main content
Glama
Sign In
iit-mcp-hudu

iit-mcp-hudu

by msoukhomlinov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Asset Layout

hudu_get_asset_layout
Read-only

Resolve a Hudu asset layout by ID, name, or slug, and set expand=true to retrieve the full layout instead of a compact summary.

Instructions

Resolve an asset layout from an id, name or slug; asset_layouts.get is cheaper for a known id. expand:true returns the full AssetLayout, not the summary.

Input Schema

NameRequiredDescriptionDefault
optsNo
identifierYes

Output Schema

NameRequiredDescriptionDefault
foundYes
recordYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.6.0
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / identifier / anyOf
      Previous value: -[
-  {
-    "exclusiveMinimum": 0,
-    "maximum": 9007199254740991,
-    "type": "integer"
-  },
-  {
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "properties": {
-      "domain": {
-        "description": "Domain, for resources that have one.",
-        "type": "string"
-      },
-      "external_id": {
-        "description": "Vendor-side external id.",
-        "type": "string"
-      },
-      "id": {
-        "description": "Numeric id - the direct fetch.",
-        "exclusiveMinimum": 0,
-        "maximum": 9007199254740991,
-        "type": "integer"
-      },
-      "name": {
-        "description": "Exact name.",
-        "type": "string"
-      },
-      "slug": {
-        "description": "Exact slug.",
-        "type": "string"
-      }
-    },
-    "type": "object"
-  }
-]New value: +[
+  {
+    "exclusiveMinimum": 0,
+    "type": "integer"
+  },
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "properties": {
+      "domain": {
+        "type": "string"
+      },
+      "external_id": {
+        "type": "string"
+      },
+      "id": {
+        "exclusiveMinimum": 0,
+        "type": "integer"
+      },
+      "name": {
+        "type": "string"
+      },
+      "slug": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  }
+]
    • removedInput schema / properties / identifier / description
      Removed value: -"Id, exact name/slug, or an identifier object."
    • changedInput schema / properties / opts / properties / expand / description
      Previous value: -"Return the full typed records instead of the compact summaries (default false)."New value: +"Full records, not compact summaries."
    • removedOutput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
  2. First observedv0.2.3

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine behavioral context the annotations lack: a relative cost characteristic versus the direct getter and the output-shape difference between expand:true (full AssetLayout) and the default summary.

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?

Two dense sentences, zero filler, with the resolution capability and the cheaper-alternative caveat front-loaded before the expand semantics. Every clause carries information an agent would otherwise have to guess.

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?

An output schema exists, so return-shape explanation is unnecessary, and annotations cover read-only/open-world semantics. The description covers resolution inputs and the expand trade-off, but does not state failure behavior (unknown identifier, ambiguous name) or the full set of accepted identifier forms.

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?

Schema description coverage is 0% and `identifier` is a nested anyOf (integer, string, or object with id/name/slug/domain/external_id), so the description carries real weight. It correctly explains that id, name, or slug resolve the layout, but omits the object form, the `domain` and `external_id` keys, and does not clarify bare-integer/string behavior, leaving part of a complex parameter undocumented.

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?

States a specific verb and resource ('Resolve an asset layout') and immediately clarifies the accepted identifier kinds and the cheaper sibling path for known ids. An agent can distinguish this from `asset_layouts.get` or `hudu_resolve_any` without opening any schema.

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?

Explicitly names the alternative (`asset_layouts.get`) and the condition that selects it ('for a known id'), and states when to set expand:true. It stops short of guiding preference against the other resolution-adjacent siblings like `hudu_resolve_any` or `hudu_get_asset_context`, so it is strong but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools