iit-mcp-hudu

Resolve Any

hudu_resolve_any

Read-only

Resolve an unknown Hudu identifier across multiple resources, returning matching records and listing unreadable resources as unauthorized.

Instructions

Resolve an identifier across resources when the type is unknown; else use hudu_get_. Unreadable resources are listed in unauthorized; fails only if all are refused. Narrow resources to skip asset_passwords/password_folders.

Input Schema

Name	Required	Description	Default
`opts`	No
`identifier`	Yes	Id, name/slug, or object

Output Schema

Name	Required	Description	Default
`hits`	Yes
`total`	Yes
`scanned`	Yes
`truncated`	Yes
`unauthorized`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.6.0Oct 25, 2026

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"
+  }
+]

changedInput schema / properties / identifier / description

Previous value: -"Id, exact name/slug, or an identifier object; resolved against every requested resource."New value: +"Id, name/slug, or object"

changedInput schema / properties / opts / properties / limit / description

Previous value: -"Maximum rows returned (1-100, default 25). A larger value throws CONFIG_ERROR - the SDK never silently clamps."New value: +"1-100 rows, default 25; larger is a CONFIG_ERROR."

changedInput schema / properties / opts / properties / resources / description

Previous value: -"Resources to try, in fan-out order; default this deployment's searchable set: articles, asset_passwords, assets, companies, groups, password_folders, users, websites. A resource outside HUDU_SEARCH_RESOURCES is refused before any request."New value: +"Default: articles, asset_passwords, assets, companies, groups, password_folders, users, websites; a resource outside HUDU_SEARCH_RESOURCES is refused before any request."

removedOutput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / properties / unauthorized

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedv0.2.3Oct 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only and open-world, but the description adds genuinely new behavior: partial failure semantics ('Unreadable resources are listed in `unauthorized`; fails only if all are refused'). That is exactly the kind of non-obvious behavior an agent needs. It stops short of describing cost/fan-out implications of resolving across eight resource types.

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?

Three short clauses, each doing distinct work: purpose, routing alternative, failure semantics, plus a sensitivity hint. Front-loaded with the primary rule and free of filler.

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 and the description wisely doesn't restate return shape, only the `unauthorized` failure contract. For a multi-resource fan-out tool this covers routing, partial-failure, and sensitive-resource skipping. It could note that resolution may make several upstream calls or how ambiguous matches across types are handled.

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 coverage is 50%; the `resources` default and HUDU_SEARCH_RESOURCES refusal already live in the schema, and the description only adds the recommendation to narrow it for sensitivity. The `identifier` shapes (id / name / slug / object with domain, external_id) and the `limit` constraint are left entirely to the schema, so the description does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Resolve an identifier across resources when the type is unknown', which is far more precise than the title 'Resolve Any'. It also draws the boundary against the sibling getters, though it names the alternative as a pattern ('hudu_get_<singular>') rather than an actual sibling name, so the agent still has to map the pattern to the real tool names.

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?

Explicitly states the selection condition (type unknown) and the alternative when the type is known ('else use hudu_get_<singular>'). It also gives a second, non-obvious usage instruction: narrow `resources` to skip asset_passwords/password_folders, which tells the agent how to avoid sensitive fan-out.

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

Deploy Server