Skip to main content
Glama
Sign In
nubiia-dev

MCP Holded

by nubiia-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_chart_of_accounts

Retrieves all accounting accounts from Holded with numbers, names, groups, and balances, including assets, liabilities, income, and expenses. Supports pagination and filters for archived, date range, and zero-balance accounts.

Instructions

Get accounting accounts (Holded API v2, GET /accounting-accounts). Returns every account with num (PGC number, e.g. 40000000), name, group, debit, credit, and balance. Unlike list_expenses_accounts (group-6 only), this includes all groups (assets, liabilities, income, expenses). Cursor-paginated: pass nextCursor from the previous response as cursor. Optional annex filters: archived (include archived accounts), start_date/end_date (ISO 8601, filter by activity period), include_empty (include zero-balance accounts). See also: list_accounting_accounts in ledger tools — both tools target the same v2 endpoint; consolidation is planned for release 2.1. Read-only.

Input Schema

NameRequiredDescriptionDefault
limitNoMax items per page
cursorNoCursor token from a previous response nextCursor
archivedNoInclude archived accounts (default: false)
end_dateNoFilter end date (ISO 8601, YYYY-MM-DD)
start_dateNoFilter start date (ISO 8601, YYYY-MM-DD)
include_emptyNoInclude zero-balance accounts (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.0.3
    • addedInput schema / properties / archived
      Added value: +{
+  "description": "Include archived accounts (default: false)",
+  "type": "boolean"
+}
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Cursor token from a previous response nextCursor",
+  "type": "string"
+}
    • addedInput schema / properties / end_date
      Added value: +{
+  "description": "Filter end date (ISO 8601, YYYY-MM-DD)",
+  "type": "string"
+}
    • addedInput schema / properties / include_empty
      Added value: +{
+  "description": "Include zero-balance accounts (default: false)",
+  "type": "boolean"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Max items per page",
+  "type": "number"
+}
    • addedInput schema / properties / start_date
      Added value: +{
+  "description": "Filter start date (ISO 8601, YYYY-MM-DD)",
+  "type": "string"
+}
  2. Addedv1.7.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does so well: it declares the tool read-only, explains cursor pagination, describes the returned account fields, and clarifies that all account groups are included. It stops short of covering auth requirements or rate limits, but the core behavior is disclosed.

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 front-loaded with the purpose and return shape, then moves into pagination, filters, and sibling notes. Most sentences earn their place; the consolidation note is slightly extraneous but useful for disambiguating a duplicate tool.

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 six-parameter read-only list tool with no output schema, the description is complete enough: it describes return fields, pagination handling, optional filters, account-group scope, read-only behavior, and sibling alternatives.

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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that `start_date`/`end_date` filter by activity period, that `include_empty` includes zero-balance accounts, and that `cursor` should be taken from the previous response's `nextCursor`.

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 a specific verb and resource ('Get accounting accounts'), identifies the underlying API endpoint, and lists the returned fields. It also explicitly distinguishes this tool from the sibling `list_expenses_accounts` by noting that this one includes all account groups rather than group-6 only.

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?

It gives a clear contrast with `list_expenses_accounts` and explains that the tool covers all groups. It also names `list_accounting_accounts` as a same-endpoint alternative and mentions planned consolidation, though it does not fully tell the agent which duplicate to choose in practice.

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