Skip to main content
Glama

List Public Photos

hudu_list_public_photos
Read-onlyIdempotent

List public photos stored in Hudu, returning each image's public URL and the record it belongs to, so you can identify images used in articles or asset notes.

Instructions

List public photos in Hudu. A public photo is an image published at a public URL and attached to an article or an asset note, so it can be rendered inside that content.

Each entry gives the image url plus the record_type and record_id it belongs to. The URL is public: anyone holding it can fetch the image without authenticating, so treat these links as shareable-by-accident and do not paste them somewhere they will outlive the conversation.

There is no filter on this endpoint — page through and match record_id yourself to find the photos for one article.

Creating and re-pointing public photos needs multipart/form-data, which hudu-mcp 0.1.0 does not implement, so this list is the only public-photo operation available here. Use the Hudu web UI to add or change one.

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.
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.
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 readOnlyHint and idempotentHint annotations, the description adds critical behavioral context: public URLs are shareable-by-accident, the API returns no total count so page_was_full is the only honest pagination signal, and multipart/form-data is unimplemented. These details materially affect how an agent should invoke the tool and interpret results.

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?

Every sentence earns its place: the definition, security note, filtering limitation, implementation constraint, and pagination caveat are all necessary. The description is front-loaded with the core purpose and organized into scannable paragraphs without redundancy.

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?

Despite no output schema, the description explains the return shape ('items plus pagination facts'), warns about the missing total count, and covers the resource's public nature and operational boundaries. For a read-only list endpoint with rich annotations, this is fully complete.

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?

The input schema already provides 100% description coverage for all four parameters, including defaults, ranges, and the enum for response_format. The description adds only a passing reference to paging ('page through') and no additional parameter-level meaning, so the baseline score of 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 opens with 'List public photos in Hudu', a specific verb+resource statement, and immediately defines what a public photo is. It distinguishes itself from siblings by being the only public-photo operation available, explicitly stating 'this list is the only public-photo operation available here'.

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 provides clear when-to-use guidance ('page through and match record_id yourself') and an explicit alternative for creating/re-pointing photos: 'Use the Hudu web UI to add or change one.' It also notes that no filter exists, setting correct expectations for usage.

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