Holded treasury

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions that amounts are strings with a dot decimal separator, which is a useful detail. However, it does not disclose that delete and archive actions are destructive, that some actions require confirmation (confirm parameter is in schema but not echoed here), or any other side effects. The description is sparse on behavior beyond the amount format.

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 paragraph that front-loads the resource definition and then lists actions. It is reasonably concise but lacks structure; grouping actions by category (e.g., accounts, movements, remittances, forecasts) would improve readability. The note on amount format is placed at the end, which is acceptable but could be more prominent. No fluff, but it reads as a dense list.

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 tool's complexity—13 parameters, 17 actions, no output schema, and no annotations—the description is incomplete. It does not cover pagination (cursor, limit), status filtering, destructive-action warnings, confirmation requirements, or return value shapes. An agent would need to consult the schema extensively and still might miss behavioral nuances. The description lists actions but does not provide enough detail for correct invocation in many scenarios.

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 coverage is only 38%, so the description must compensate. It adds meaning for several parameters by tying them to actions: list_movements uses account id, start_date, end_date; create_movements is manual; reconcile uses movement_id plus data.documents. It also clarifies amount format. However, many parameters (cursor, limit, status, remittance_type, archived) are not explained in the description, leaving gaps that the low-coverage schema does not fill.

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 clearly identifies the resource as 'Banking accounts and their movements' and lists the supported actions, making its purpose evident. It is distinguishable from sibling modules by the treasury-specific domain, though it does not explicitly contrast with them. A specific verb and resource are present, but the description is more of an enumeration than a precise purpose statement.

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?

The description provides no guidance on when to use this tool versus alternative modules like holded_accounting or holded_payments. It only lists actions without any contextual routing, such as 'use this for treasury operations, use that for accounting.' Some action-specific parameter hints exist (e.g., list_movements uses id, start_date, end_date), but there is no explicit when/when-not guidance.

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