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

iit-mcp-hudu

by msoukhomlinov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Company Context

hudu_get_company_context
Read-only

Fetches a Hudu company and its bounded context by numeric ID, with options to skip sub-lists, limit rows, or expand records.

Instructions

Fetch a company with its bounded context (CompanyContext). Required: numeric id, never a name or slug. Without password_access it 401s unless opts.skip omits asset_passwords; a refused sub-list answers UNAUTHORIZED.

Input Schema

NameRequiredDescriptionDefault
idYesNumeric company id.
optsNoRead options: limit, expand, skip.

Output Schema

NameRequiredDescriptionDefault
contextYes
skippedNo
markdown_lossyNo
markdown_lossy_codesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.6.0
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / properties / id / maximum
      Removed value: -9007199254740991
    • addedInput schema / properties / opts / description
      Added value: +"Read options: limit, expand, skip."
    • 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."
    • 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."
    • addedInput schema / properties / opts / properties / skip
      Added value: +{
+  "description": "Sub-lists to omit; no request is made for them.",
+  "items": {
+    "enum": [
+      "assets",
+      "articles",
+      "websites",
+      "asset_passwords"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • removedOutput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / properties / markdown_lossy
      Added value: +{
+  "type": "boolean"
+}
    • addedOutput schema / properties / markdown_lossy_codes
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / skipped
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observedv0.2.3

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the auth requirement (401 without password_access), the workaround (skip asset_passwords), and the per-sub-list failure mode (a refused sub-list returns UNAUTHORIZED). That is exactly the context annotations do not carry.

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 compact clauses with no filler, front-loading what the tool returns, then the required-parameter constraint, then the failure behavior. Every phrase carries information.

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?

An output schema exists so return values need no explanation, and the nested `opts` details are fully covered by the schema. Combined with the auth and error disclosure, nothing an agent needs to invoke this correctly is missing.

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 the baseline is 3, but the description adds real meaning: it reinforces that `id` is numeric-only and explains how `opts.skip` interacts with the auth model. The `limit` CONFIG_ERROR behavior is documented only in the schema, not the description.

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?

States a specific verb and resource — 'Fetch a company with its bounded context (CompanyContext)' — and pins the identifier as numeric. It distinguishes the tool from list/search siblings by its bounded-context scope, though it never names an alternative tool explicitly.

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?

'Required: numeric `id`, never a name or slug' gives a concrete precondition that shapes how the agent must call it, and the password_access/`opts.skip` clause tells the agent how to avoid a 401. There is no explicit when-to-use-versus-siblings guidance, so it stops 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