Skip to main content
Glama

List Activity Logs

hudu_list_activity_logs
Read-onlyIdempotent

Retrieve Hudu audit trail entries to see who changed a record, what they did, and when. Use filters for resource, user, or start date to narrow the log.

Instructions

List activity logs in Hudu. The activity log is Hudu's audit trail: one entry per action, recording who did it, what they did it to, and when.

This is the tool for "who changed this, and when". Each entry carries user_id and user_email (the actor), resource_type and resource_id (what they touched), and an action_message describing the action.

Combine the filters to answer a real question rather than paging the whole log:

  • History of one record: resource_type plus resource_id together. Sending one without the other does nothing.

  • What one person did: user_id, or user_email if you only have the address.

  • A time window: start_date. There is no end-date filter, so a log is bounded at the start only; to look at "last week" specifically, set start_date to the beginning of that week and read forward.

  • One kind of action: action_message.

Entries are ordered by Hudu, not by this server, and no total count is returned — so to find the most recent change to a record, request a page and read it rather than assuming the first entry is newest.

Reading the log never alters it. Purging it is a separate tool, hudu_purge_activity_logs, and is destructive.

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.
user_idNoNumeric id of the person whose actions you want. Resolve it with hudu_list_users.
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.
start_dateNoReturn only entries from this moment onward. Hudu documents this as ISO-8601, e.g. "2026-03-01T00:00:00Z". Send an explicit UTC offset rather than a bare date — a date alone leaves the time of day to the server to decide.
user_emailNoEmail address of the person whose actions you want, when you have no user id.
resource_idNoNumeric id of the record whose history you want. Must be sent together with `resource_type`; on its own it is ignored.
resource_typeNoHudu record type, written exactly as Hudu spells it: "Asset", "AssetPassword", "Company", "Article", "Website" and so on. Must be sent together with the matching id — either one alone is ignored.
action_messageNoMatch on the text of the recorded action, e.g. the word used for a create, update or view. Hudu publishes no list of legal values, so treat this as a text filter and confirm against an unfiltered sample before relying on a particular wording.
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, idempotent, not destructive), the description discloses that entries are ordered by Hudu not the server, there is no total count returned, and page_was_full is the only honest pagination signal. It also explains the read-only nature explicitly, which is consistent with annotations.

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 long but well-organized with bullet points and clear sections. It front-loads the purpose and then systematically covers parameter behaviors. Some redundancy exists (no total count is mentioned twice), but the complexity of the 10-parameter tool justifies the length.

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 10 parameters and no output schema, the description is remarkably complete. It covers return shape (items plus pagination facts), filter combinations, ordering, pagination caveats, and the distinction from the destructive purge tool. No operational aspect is left unaddressed.

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?

Even though the input schema already covers all parameters with descriptions, the tool description adds substantial semantic context: resource_type and resource_id must be used together, start_date should include an explicit UTC offset, action_message has no enumerated values, and fields can be used to keep lists small. This goes far beyond the schema details.

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 activity logs in Hudu' and then defines the tool as 'the tool for who changed this, and when', giving a clear verb+resource+scope. It describes the audit trail contents (actor, resource, action) which distinguishes it from other list tools, and explicitly contrasts with the destructive purge tool.

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 provides explicit 'when to use' guidance ('who changed this, and when') and detailed filter combination rules, including what not to do (e.g., sending resource_type without resource_id does nothing). It also points to an alternative destructive tool (hudu_purge_activity_logs) for purging, helping the agent avoid misuse.

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