Skip to main content
Glama

List Magic Dash Items

hudu_list_magic_dash_items
Read-onlyIdempotent

List magic dash items from Hudu company dashboards, filtering by title and company ID to read a specific tile's status and details.

Instructions

List magic dash items in Hudu. A magic dash item is one of the coloured tiles across the top of a company page in Hudu — a title, a headline message, an optional shade and optional HTML detail. They are normally written by scripts and integrations to surface a live status ("Microsoft 365: 42 licences, 3 unassigned") next to the documentation.

The write endpoints identify the company by name, not by id — company_id is a read-side filter only, and there is no way to address a tile by company id when writing. The name has to match an existing Hudu company exactly. Take it from company_name on a listed item, or from name on the record hudu_list_companies returns.

There is no endpoint for fetching a single magic dash item, so this list is the only way to read one — filter by title and company_id to narrow to the tile you want and read its id and company_name from the result.

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
pageNo1-based page number. Hudu has no cursor or offset — only pages.
titleNoMatch the tile title, e.g. "Microsoft 365". Titles are not unique across companies.
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_idNoShow only tiles on this company's dashboard, 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?

Beyond the annotations (readOnlyHint=true, idempotentHint=true), the description discloses pagination behavior: no total count, page_was_full as the only honest signal, and the instruction to read pagination_note. It also reveals that the write side uses company_name while the read side uses company_id, adding valuable behavioral nuance.

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 well-structured with clear paragraphs: definition, write/read naming asymmetry, single-fetch limitation, return shape/pagination, and operation class. Every sentence adds value, and the most important information (what it lists) is front-loaded.

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?

With 6 parameters, no output schema, and a complex domain (magic dash items), the description covers all necessary context: return shape (items + pagination facts), pagination caveats, read-only nature, and filtering strategies. It fully compensates for the lack of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage, the description adds critical parameter meaning: company_id is 'a read-side filter only', titles are not unique, and fields is useful for keeping lists small. It also clarifies page_size clamping behavior, going beyond the schema's basic descriptions.

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 'List magic dash items in Hudu' and explains what a magic dash item is with a concrete example. It clearly distinguishes this read tool from the sibling write tool hudu_upsert_magic_dash_item by noting the asymmetry between read (by company_id) and write (by company_name).

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 explicitly says there is no single-fetch endpoint, so this list is the only way to read a tile, and advises filtering by title and company_id. It also warns that write endpoints identify companies by name, providing practical when-to-use context not available in schemas.

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