Skip to main content
Glama
nubiia-dev
by nubiia-dev

list_expenses_accounts

Retrieve expense and purchase accounts (PGC group 6) from Holded with cursor-based pagination and optional field filtering to fetch account IDs, names, and account numbers.

Instructions

List expenses accounts (Holded API v2). Cursor-paginated: pass the previous response nextCursor as cursor. Response fields are snake_case; amounts are strings with decimal comma. Each account has id (Holded internal id), name, and accountNum (the PGC account number, e.g. 62900000). NOTE: this endpoint only returns expense/purchase accounts (PGC group 6). Income accounts (group 7, e.g. 700/705/759) are NOT listed here — fetch the full chart via get_chart_of_accounts, or read a known account by id via get_expenses_account.

Input Schema

NameRequiredDescriptionDefault
limitNoMax items per page (server-paginated; use limit to control page size)
cursorNoCursor from a previous response nextCursor
fieldsNoProject only these fields per item (e.g. ["id", "name", "accountNum"]). Reduces response size. NOTE: the PGC number field is `accountNum` (not `code`).
summaryNoReturn only count and pagination metadata without items (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.0.3
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "Cursor from a previous response nextCursor",
      +  "type": "string"
      +}
    • changedInput schema / properties / fields / description
      Previous value: -"Select specific fields to return (e.g., [\"id\", \"name\", \"accountNum\"]). Reduces response size. If not provided, returns default fields: id, name, accountNum. NOTE: the PGC number field is `accountNum` (not `code`)."New value: +"Project only these fields per item (e.g. [\"id\", \"name\", \"accountNum\"]). Reduces response size. NOTE: the PGC number field is `accountNum` (not `code`)."
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Max items per page (server-paginated; use limit to control page size)",
      +  "type": "number"
      +}
    • removedInput schema / properties / page
      Removed value: -{
      -  "description": "Page number (starting from 1, default: 1)",
      -  "type": "number"
      -}
    • removedInput schema / properties / pageSize
      Removed value: -{
      -  "description": "Number of items per page (default: 50, max: 500)",
      -  "type": "number"
      -}
    • changedInput schema / properties / summary / description
      Previous value: -"Return only total count and page count without items (default: false)"New value: +"Return only count and pagination metadata without items (default: false)"
  2. Changed1 schema field changedv1.7.0
    • changedInput schema / properties / fields / description
      Previous value: -"Select specific fields to return (e.g., [\"id\", \"name\", \"code\"]). Reduces response size by 70-90%. If not provided, returns default fields: id, name, code"New value: +"Select specific fields to return (e.g., [\"id\", \"name\", \"accountNum\"]). Reduces response size. If not provided, returns default fields: id, name, accountNum. NOTE: the PGC number field is `accountNum` (not `code`)."
  3. First observedv1.6.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses cursor pagination mechanics (pass previous nextCursor), response encoding conventions (snake_case, amounts as strings with decimal comma), and the endpoint's hard scope limit. It also describes the field set returned (`id`, `name`, `accountNum`) since no output schema exists.

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 the verb+resource, then pagination, then response shape, then the exclusion note — a good information order. Slightly dense and the cursor explanation mildly repeats the schema's own cursor description, but every sentence carries substantive detail.

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?

No output schema and no annotations exist, so the description must cover returns, pagination, and scope on its own — which it does, including the per-item field list and the group 6 restriction. An agent has everything needed to call it correctly and interpret the response.

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 the parameter definitions already do the work and a baseline 3 would be defensible. The description adds real value on top by explaining the cursor round-trip and warning that the PGC number field is `accountNum`, not `code` — a naming trap the schema alone could not resolve.

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 expenses accounts') and immediately scopes it to the Holded API v2 expenses endpoint. The NOTE clarifies it returns only PGC group 6 accounts, which distinguishes it from get_chart_of_accounts and get_expenses_account.

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?

Explicitly names when-not-to-use this tool (income accounts, group 7, examples 700/705/759) and routes the agent to the correct alternatives: get_chart_of_accounts for the full chart, get_expenses_account for a known id. Nothing is left to inference.

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