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

iit-mcp-hudu

by msoukhomlinov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Group

hudu_get_group
Read-only

Resolves a Hudu user group by ID, name, or slug, optionally expanding it to return full group details and members. Use a known ID with the cheaper groups.get path when available.

Instructions

Resolve a user group from an id, name or slug; groups.get is cheaper for a known id. expand:true returns the full Group, members included.

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.1/5.0
Behavior4/5

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

Annotations already declare read-only and open-world behavior. The description adds useful context beyond annotations: expand:true returns the full Group including members, and it notes a cost tradeoff with groups.get. It does not cover auth requirements or rate limits, but those are less relevant for a read operation.

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 a single compact sentence with purpose front-loaded and zero waste. Every clause adds value: identifier forms, cost alternative, and expand behavior.

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?

With an output schema and annotations covering return shape and safety, the description supplies enough detail for correct invocation. The only gap is not mentioning all identifier variants (domain, external_id) supported by the schema.

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 description coverage is 0%, so the description must carry the burden. It explains that identifier accepts id, name, or slug and clarifies that expand:true returns full records with members. It omits the domain and external_id identifier forms allowed by the schema, so it is helpful but not exhaustive.

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?

The description states a specific verb and resource ('Resolve a user group') and enumerates accepted identifier forms (id, name, slug). It also contrasts with 'groups.get' for known ids, which aids differentiation, though it does not name a sibling tool from the provided list.

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?

It gives an explicit usage condition: use this for id/name/slug resolution, but 'groups.get is cheaper for a known id.' No explicit exclusions or prerequisites are stated, keeping it just short of a 5.

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