iit-mcp-hudu

List Records

hudu_list

Read-only

Lists one bounded page of Hudu companies, articles, assets, or asset layouts using resource-specific filters and pagination, without writing data or fetching additional pages.

Instructions

List ONE bounded page of companies, articles, assets (all companies) or asset_layouts. It takes no operation argument: it cannot become a write and never pages the tenant. Each collection accepts only its own filters; another is refused naming them. asset_layouts takes no page_size (the vendor ignores it): has_more is conservative (true for any non-empty page) — stop when a page comes back empty. Article bodies: compact rows carry none; expand:true returns stored HTML.

Input Schema

Name	Required	Description
`page`	No	Page number to fetch (1-based, default 1). This tool returns that one page and never follows it.
`expand`	No	Full records, not compact summaries.
`filters`	No	Resource-specific, closed per resource: companies: name, phone_number, website, city, id_number, state, slug, search, id_in_integration, updated_at; articles: name, company_id, draft, enable_sharing, slug, search, updated_at; assets: company_id, id, name, primary_serial, asset_layout_id, archived, slug, search, updated_at; asset_layouts: name, slug, active, updated_at. A filter outside its resource's set is refused naming the accepted ones.
`resource`	Yes	Which collection to list.
`page_size`	No	Rows per page (1-100, default 25); refused for asset_layouts, never clamped.

Output Schema

Name	Required	Description	Default
`page`	Yes
`rows`	Yes
`count`	Yes
`has_more`	Yes
`page_size`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.6.0Oct 25, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond readOnlyHint and openWorldHint, the description discloses important behavior: no operation argument, never pages the tenant, per-resource filter enforcement, asset_layouts page_size handling, conservative has_more semantics, and article body behavior under expand:true. This is exactly the kind of context an agent needs to invoke the tool correctly.

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 dense but front-loaded and every sentence carries operational information. Parentheticals are compact, and no sentence is redundant against the schema or annotations.

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?

Given five parameters, nested filters, an output schema, and rich annotations, the description covers the key behavioral gaps: bounded paging, stop condition, resource-specific filters, asset_layouts exception, and article body expansion. Nothing material is missing for correct invocation.

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 already 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining refusal behavior for filters, asset_layouts page_size behavior, has_more conservatism, and expand effects on article bodies.

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 clear verb and resource set: list one bounded page of companies, articles, assets, or asset_layouts. It clarifies that this is not a write and does not page the tenant, but it does not explicitly distinguish itself from nearby read/search/fetch siblings such as hudu_search or hudu_fetch_many.

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 useful usage constraints: one bounded page, per-resource filter sets with refusals, no page_size for asset_layouts, and a stop condition when a page is empty. It lacks explicit routing guidance naming when to use hudu_search or hudu_fetch_many instead.

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

Deploy Server