Holded accounting

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add some useful details: ledger dates use DD/MM/YYYY and amounts use a dot decimal separator, and it notes that start_date/end_date add debit/credit/balance for list_accounts. However, it omits critical behaviors such as the confirm gating mechanism (mentioned in the schema but not the description), pagination semantics (cursor/limit), side effects of create/update/delete actions, and reversibility. The coverage is thin for a tool with 23 actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single block that lists the general purpose then a long list of actions with parenthetical parameter hints. It is not verbose, but it is not well-structured; it could be broken into logical sections (e.g., accounts, ledger, taxes, etc.). The front-loaded purpose is helpful, but the dense list makes scanning harder. It earns a middling score for being concise yet poorly organized.

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

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

Given the complexity (23 actions, 15 parameters, no output schema, no annotations), the description is notably incomplete. It does not explain return values or pagination behavior, does not mention the confirm gating flow, does not describe error cases, and leaves many parameters undefined in context. An agent would need to rely heavily on the schema and possibly make trial calls to understand expected behavior. The description provides only a high-level list of actions and a few formatting notes, which is insufficient for a tool of this scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 60%, so the description must compensate for the missing 40%. It does add meaning to several parameters: it explains that start_date and end_date add debit/credit/balance for list_accounts, that list_ledger requires them, that tax_keys takes a country, that series_type is used for list_numbering_series, and that delete_tag requires name. However, many parameters (id, data, section, archived, include_empty, cursor, limit) are not addressed in the description, and the meaning of the 'data' object is left to the schema. It provides partial compensation but not full.

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

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

The description opens with 'Chart of accounts, journal, taxes and configuration lists', which clearly scopes the tool to accounting data and configuration. The long action list reinforces the domain. It distinguishes from siblings like holded_sales and holded_contacts by focusing on accounting-specific entities. However, the purpose is stated as a list of domains rather than a single unified verb+resource, so it's not perfectly crisp.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The description never mentions other Holded modules or conditions that would route an agent to a sibling. The only implicit cue is the domain name, which is not enough for clear decision-making. It does not state exclusions or alternatives.

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