Skip to main content
Glama
Sign In
nubiia-dev

MCP Holded

by nubiia-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_project_times

Retrieve time-tracking entries across all Holded projects with cursor pagination, then filter by approved status or date range on each returned page.

Instructions

List time-tracking entries across all Holded projects (Projects API v2). Returns a cursor-paginated flat list of entries; pass the previous nextCursor as cursor to fetch the next page. Each entry contains timeId, duration (seconds), date (Unix seconds), approved (0/1), projectId, and projectName. The approvedOnly, startDate, and endDate filters are applied client-side on the current page — use pagination to iterate over the full dataset. Read-only.

Input Schema

NameRequiredDescriptionDefault
limitNoMax items per cursor page (default: 50)
cursorNoCursor token from a previous response nextCursor to fetch the next page
endDateNoKeep only entries on or before this date (YYYY-MM-DD, inclusive) — applied client-side on the returned page
startDateNoKeep only entries on or after this date (YYYY-MM-DD, inclusive) — applied client-side on the returned page
approvedOnlyNoKeep only approved entries (approved === 1) — applied client-side on the returned page. Default: false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.0.3
    • changedInput schema / properties / approvedOnly / description
      Previous value: -"Keep only approved entries (approved === 1). Default: false"New value: +"Keep only approved entries (approved === 1) — applied client-side on the returned page. Default: false"
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Cursor token from a previous response nextCursor to fetch the next page",
+  "type": "string"
+}
    • changedInput schema / properties / endDate / description
      Previous value: -"Keep only entries on or before this date (YYYY-MM-DD, inclusive)"New value: +"Keep only entries on or before this date (YYYY-MM-DD, inclusive) — applied client-side on the returned page"
    • removedInput schema / properties / flatten
      Removed value: -{
-  "description": "Return a flat array of entries (each with projectId, projectName, and hours = duration/3600) instead of the nested per-project structure. Default: false",
-  "type": "boolean"
-}
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Max items per cursor page (default: 50)",
+  "type": "number"
+}
    • changedInput schema / properties / startDate / description
      Previous value: -"Keep only entries on or after this date (YYYY-MM-DD, inclusive)"New value: +"Keep only entries on or after this date (YYYY-MM-DD, inclusive) — applied client-side on the returned page"
  2. Addedv1.7.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden and does well: it declares "Read-only", explains cursor-pagination mechanics, enumerates the returned fields with units (duration in seconds, date as Unix seconds), and discloses the important gotcha that approvedOnly/startDate/endDate only filter the current page. It omits auth/permission requirements and rate-limit behavior.

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?

Purpose is front-loaded in the first clause, followed by pagination mechanics, return shape, and the filter caveat in that order of operational importance. No filler sentences; even the field enumeration earns its place because no output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with no output schema and no annotations, the description covers return shape, pagination, and the surprising client-side filter semantics — everything an agent needs to call it correctly and interpret results. Only missing element is guidance on when to prefer a sibling 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 description coverage is 100%, so all five parameters are already documented in the schema, including the client-side filtering caveat. The description restates the cursor and filter behavior but adds no syntax or format detail beyond what the schema provides, so the baseline of 3 applies.

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?

States a specific verb and resource ("List time-tracking entries across all Holded projects") plus the API family (Projects API v2). The "across all projects" scope distinguishes it from list_project_times_by_project and list_employee_times without needing to open either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational guidance for pagination ("pass the previous nextCursor as cursor to fetch the next page") and warns that filtering is client-side so pagination is needed for the full dataset. It does not explicitly route to sibling alternatives such as list_project_times_by_project when a single project is wanted, so it falls short of a 5.

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

Deploy Server

Other Tools