iit-mcp-hudu

Discover Operations (Catalog)

hudu_list_operations

Read-only

Lists Hudu SDK operations with their exposed tools, effects, dry-run or confirmation needs, and required arguments; filter or page results (1–100 rows) to find the operation to describe or run.

Instructions

List SDK operations with the tool exposing each, its effect, dry-run/confirm need and required arguments. This server is a curated SUBSET: hudu_describe_operation gives one operation's contract, hudu_read/hudu_write/hudu_delete run it. Bounded 1-100 rows (default 40), offset pages; the catalog is large, so filter or page.

Input Schema

Name	Required	Description
`limit`	No	1-100, default 40.
`effect`	No
`offset`	No	Row offset, for paging.
`resource`	No	Resource, e.g. "assets".
`unexposed_only`	No	Only rows with NO tool of their own.

Output Schema

Name	Required	Description	Default
`rows`	Yes
`limit`	Yes
`offset`	Yes
`matched`	Yes
`has_more`	Yes
`total_operations`	Yes
`reachable_operations`	Yes
`unexposed_operations`	Yes
`unreachable_operations`	Yes

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"

removedInput schema / properties / effect / description
```
Removed value: -"Only rows with this effect."
```

changedInput schema / properties / limit / description

Previous value: -"Rows per page (1-100, default 40); the whole catalog is ~10k tokens, so page it."New value: +"1-100, default 40."

removedInput schema / properties / offset / maximum
```
Removed value: -9007199254740991
```

changedInput schema / properties / resource / description

Previous value: -"Only rows of this registry resource (e.g. \"assets\")."New value: +"Resource, e.g. \"assets\"."

changedInput schema / properties / unexposed_only / description

Previous value: -"Only rows with NO tool of their own — the capabilities reachable only through hudu_read / hudu_write / hudu_delete."New value: +"Only rows with NO tool of their own."

removedOutput schema / $schema

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

First observedv0.2.3Oct 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare read-only and closed-world behavior, and the description adds non-obvious context: this is a curated subset, rows are bounded 1-100 with a default of 40, and paging is required for a large catalog. It does not cover error behavior or authentication, but with annotations present this is solid added context.

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 front-loaded with purpose and output fields, then scope/alternatives, then paging constraints. Every sentence contributes useful selection or invocation guidance with no repetition.

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 an output schema and read-only annotations, the description supplies everything an agent needs: what the catalog returns, how it differs from siblings, and how to avoid an unbounded large result. No material gap remains for this discovery tool.

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 80%, so the schema already documents limit, offset, resource, and unexposed_only well. The description reinforces paging and filtering, but does not add significant meaning for effect values or explain unexposed_only beyond what the schema provides, so baseline 3 is appropriate.

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?

The description states a specific verb and resource (list SDK operations) and names the fields returned for each row: exposing tool, effect, dry-run/confirm need, and required arguments. It also clearly distinguishes this catalog tool from hudu_describe_operation and the hudu_read/hudu_write/hudu_delete execution siblings.

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?

It explicitly routes the agent: use this to browse operations, hudu_describe_operation for one contract, and hudu_read/hudu_write/hudu_delete to run it. It also advises filtering/paging because the catalog is large, which tells the agent how to use the tool correctly.

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

Deploy Server