Skip to main content
Glama
Sign In
nubiia-dev

MCP Holded

by nubiia-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_daily_ledger

Retrieve ledger entries for a date range to get journal lines with accounts, debit, and credit for balance-sheet and tax figures.

Instructions

Get ledger entries / journal (asientos) for a date range (Holded API v2, GET /ledger-entries). Returns one row per ledger line with entryNumber, line, timestamp, type (collect/payment/purchase/…), description, account (PGC num), debit, and credit. This is the authoritative source for balance-sheet and tax-return figures.

Date arguments (at least one form of each bound is required — the v2 API returns 422 without both): • Primary form : start_date / end_date — ISO 8601 date strings (YYYY-MM-DD) • Legacy form : starttmp / endtmp — Unix timestamps in seconds; converted automatically to ISO

If both forms are supplied for the same bound, the ISO string takes precedence.

Cursor-paginated: pass nextCursor from a previous response as cursor to retrieve subsequent pages. Large date ranges may require multiple pages. Set groupByEntry to nest lines into full double-entry entries with per-entry debit/credit totals (applied page-scoped). See also: list_ledger_entries in ledger tools — both tools target the same v2 endpoint. Read-only.

Input Schema

NameRequiredDescriptionDefault
limitNoMax items per cursor page (server-paginated; use limit to control page size)
cursorNoCursor token from a previous response nextCursor
endtmpNoRange end as a Unix timestamp in seconds (legacy form, converted to ISO). Use end_date when possible.
end_dateNoRange end as an ISO 8601 date (YYYY-MM-DD, inclusive). Required unless endtmp is provided.
starttmpNoRange start as a Unix timestamp in seconds (legacy form, converted to ISO). Use start_date when possible.
start_dateNoRange start as an ISO 8601 date (YYYY-MM-DD, inclusive). Required unless starttmp is provided.
groupByEntryNoGroup lines by entryNumber into full journal entries (each with totalDebit/totalCredit), applied to the current page. Default: false (flat lines)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv2.0.3
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Cursor token from a previous response nextCursor",
+  "type": "string"
+}
    • addedInput schema / properties / end_date
      Added value: +{
+  "description": "Range end as an ISO 8601 date (YYYY-MM-DD, inclusive). Required unless endtmp is provided.",
+  "type": "string"
+}
    • changedInput schema / properties / endtmp / description
      Previous value: -"Range end as a Unix timestamp in seconds (inclusive)"New value: +"Range end as a Unix timestamp in seconds (legacy form, converted to ISO). Use end_date when possible."
    • changedInput schema / properties / groupByEntry / description
      Previous value: -"Group lines by entryNumber into full journal entries (each with totalDebit/totalCredit). Default: false (flat lines)"New value: +"Group lines by entryNumber into full journal entries (each with totalDebit/totalCredit), applied to the current page. Default: false (flat lines)"
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Max items per cursor page (server-paginated; use limit to control page size)",
+  "type": "number"
+}
    • addedInput schema / properties / start_date
      Added value: +{
+  "description": "Range start as an ISO 8601 date (YYYY-MM-DD, inclusive). Required unless starttmp is provided.",
+  "type": "string"
+}
    • changedInput schema / properties / starttmp / description
      Previous value: -"Range start as a Unix timestamp in seconds (inclusive)"New value: +"Range start as a Unix timestamp in seconds (legacy form, converted to ISO). Use start_date when possible."
    • changedInput schema / required
      Previous value: -[
-  "starttmp",
-  "endtmp"
-]New value: +[]
  2. Addedv1.7.0

TDQS

A4.3/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it declares the tool read-only, warns the v2 API returns 422 without both bounds, documents automatic timestamp conversion and ISO precedence, and flags that `groupByEntry` is applied page-scoped — a genuinely non-obvious caveat.

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?

Front-loads purpose and return shape, then uses a short bulleted block for the date-form rules and a compact paragraph for pagination/grouping. Slightly dense but every sentence carries operational information.

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?

For a 7-parameter, no-annotation, no-output-schema tool, the description covers purpose, return fields, required argument combinations, precedence, error behavior, pagination, and the grouping mode. An agent could invoke it correctly without opening the schema.

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 coverage is 100%, so baseline would be 3, but the description adds real meaning beyond the schema: the dual date-input forms, their precedence order, and the page-scoped nature of `groupByEntry`. Pagination interplay between `limit` and `cursor` is left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get ledger entries / journal for a date range') plus the exact API endpoint, and lists the returned fields. It names the sibling `list_ledger_entries` and admits both hit the same endpoint, but never says which to prefer, so differentiation is only partial.

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 concrete operational guidance: at least one bound per date form is required, ISO takes precedence over the legacy Unix form, and `cursor`/`nextCursor` drives pagination. It lacks explicit when-to-use guidance against `list_ledger_entries`, which is the one clear gap.

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