Skip to main content
Glama

List Procedures

hudu_list_procedures
Read-onlyIdempotent

List procedures from Hudu, showing ordered task checklists with completion counts for repeatable work. Returns both templates and active processes.

Instructions

List procedures in Hudu. A procedure — called a Process in the Hudu interface — is an ordered checklist of tasks with a completion count, used for repeatable work such as onboarding, offboarding and server builds.

This API version exposes procedures read-only. There is no create, update or delete endpoint for them, so no such tool exists here and none is being withheld — process templates are authored in the Hudu web interface. The one write available is hudu_kickoff_procedure, which starts a new process from an existing template.

Results include both templates and processes already started from one: parent_procedure names the template a running process came from and is null on the template itself. total and completed count tasks, completion_percentage arrives as a string like "0%", and a non-null asset means the process is pinned to a specific device or person. For instructions that are read rather than worked through, look at articles instead (hudu_list_articles).

Returns an object with items plus pagination facts. Note that the Hudu API returns no total count for any collection, so page_was_full is the only honest signal that more records exist — read pagination_note before concluding a list is complete.

Operation class: Read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoMatch against the procedure name.
pageNo1-based page number. Hudu has no cursor or offset — only pages.
slugNoMatch the URL slug, if you already have one.
fieldsNoReturn only these top-level fields on each record. Use it to keep large lists small — e.g. ["id","name","company_id"]. Unknown field names are ignored.
page_sizeNoRecords per page (1-100, default 25). Hudu publishes no maximum, so this client clamps at 100; larger values are rejected here rather than silently altered by the server.
company_idNoReturn only procedures belonging to this company, by numeric Hudu company id.
response_formatNoOutput shape. 'json' (default) is compact and machine-readable; 'markdown' is easier for a person to read but larger.json
Behavior5/5

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

The description adds substantial behavior beyond the annotations: read-only nature is already hinted, but it clarifies that results mix templates and started processes, explains parent_procedure, completion_percentage string format, asset pinning, and the critical pagination caveat that no total count exists and page_was_full is the honest signal. It also mentions the clamping behavior for page_size. This is rich, non-contradictory context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but every section earns its place: naming clarification, read-only caveat, template-vs-process semantics, pagination warning, and pointer to articles. It is well front-loaded with the core purpose and then structured into paragraphs. Slight redundancy with the operation class line at the end, but overall efficient for the complexity involved.

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 no output schema, the description fully covers return shape: an object with items plus pagination facts, total/completed counts, completion_percentage format, asset field semantics, and the page_was_full signal. It also addresses the lack of create/update/delete endpoints and directs to alternatives. For a list tool with 7 optional parameters and no output schema, this is complete and self-sufficient.

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 100% and each parameter has a clear description, so the baseline is 3. The tool description adds extra meaning around pagination by explaining that page_was_full is the only honest continuation signal and that the API has no total count, which adds practical semantics to the page/page_size parameters. It also explains the fields parameter's use case (keeping lists small), though the schema already covers this. This elevates it above baseline.

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 opens with a specific verb and resource ('List procedures in Hudu') and clearly differentiates this tool from siblings: it explicitly notes there is no create/update/delete for procedures, distinguishes from hudu_list_articles for read-only instructions, and points to hudu_kickoff_procedure for starting processes. This fully clarifies purpose and scope.

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?

The description gives explicit when-to-use context: repeatable work like onboarding/offboarding/server builds, read-only access, and no create/update/delete endpoint. It names hudu_kickoff_procedure as the only write, recommends hudu_list_articles for read-only instructions, and even explains how to interpret pagination. These are strong, actionable usage guidelines with alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZenixSolutions/hudu-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server