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

With no annotations provided, the description carries a heavier burden. It adds useful behavioral context: balances are accumulated from the start of the fiscal year and accounts are organized into current/non-current categories. It does not explicitly disclose read-only behavior, response format, or potential limitations, but the 'get_' naming and report-generation framing suggest a safe read operation.

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 three concise sentences with no filler: it states the main output, the classification scheme, and the accumulation period. The most important information is front-loaded.

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?

For a parameterless report-generation tool, the description sufficiently covers what is produced, how it is categorized, and the accounting period involved. It could mention return format, but no output schema exists and the accounting definition is adequate for selecting and invoking the tool correctly.

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?

The tool has zero parameters and an empty input schema, so there is no parameter-semantic burden for the description to carry. The baseline for a no-parameter tool is 4, and the description appropriately avoids unnecessary parameter-related text.

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 deliverable ('balance de situación') and the source accounting framework ('Plan General Contable'), and explains the grouping into assets, equity, and liabilities. This is specific enough to distinguish it from siblings such as profit-loss, VAT, and document tools.

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 communicates the core use case: generating a balance sheet with accumulated balances from the start of the fiscal year. It does not explicitly state when to choose this over alternatives like holded_get_profit_loss, but the specialized output makes the intended usage inferable.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the operation and does not confirm read-only behavior, error handling, authorization requirements, or response characteristics. For a getter there are no destructive side effects implied, but the description does not state this explicitly.

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?

A single sentence that front-loads the verb and resource, contains no filler, and communicates the essential input and output expectation. Every word contributes to meaning.

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?

For a one-parameter get-by-ID tool, the description plus schema provide enough to invoke it correctly. The absence of an output schema and annotations is a minor gap, as the return shape and error behavior are not described, but the tool is simple enough that this does not critically block usage.

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?

The schema already documents contactId with 'ID del contacto' (100% coverage). The description's 'por su ID' simply repeats the same concept without adding format, constraints, or usage nuance beyond what the schema provides.

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 uses a specific verb ('Obtiene') and resource ('detalle de un contacto específico') and specifies the lookup key ('por su ID'). This clearly distinguishes it from sibling tool holded_list_contacts, which returns a collection rather than a single entity.

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 tool's purpose is self-evident: it is used when the agent has a contact ID and needs the full detail of that one contact. It does not explicitly name alternatives or exclusions, but the context is clear enough for correct selection among the sibling tools.

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

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

No annotations are provided, so the description carries the burden. 'Obtiene el detalle' clearly signals a read/retrieval operation, which is the core behavior. However, it does not disclose response format, error behavior, permissions, or any other behavioral context beyond the basic fetch.

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, front-loaded sentence that immediately states the action and the key qualifiers. There is no filler or redundant information, making it appropriately concise for a simple two-parameter tool.

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?

For a simple getter, the description provides enough to select and invoke the tool correctly given the complete schema. However, with no output schema and no annotations, it does not clarify what the returned 'detalle' includes or how errors are handled, leaving a moderate completeness gap.

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?

The input schema already documents both parameters fully, including an enum for docType and descriptions for both fields (100% coverage). The description only restates 'por su tipo e ID' and adds no additional meaning about parameter values, formats, or relationships.

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 uses a specific verb ('Obtiene') and clearly identifies the resource: a specific Holded document filtered by type and ID. This distinguishes it from list-oriented siblings like holded_list_documents, though it does not explicitly name the alternative.

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 phrase 'documento específico' implies the tool is for retrieving a single known document rather than listing documents, but there is no explicit guidance on when to use it versus alternatives or what prerequisites apply. Usage context is implied, not stated.

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

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

No annotations are provided, so the description carries the behavioral burden. It explicitly warns that balances come from the chart of accounts and are cumulative, meaning startDate and endDate are informational rather than filters. This is a meaningful behavioral disclosure beyond the name; it could only be stronger by stating the expected response shape or read-only nature more directly.

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?

Two compact sentences put the main purpose and calculation logic first, with the important caveat about accumulated balances at the end. No filler or repetition; every sentence earns its place.

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?

With no output schema and no annotations, the description does enough by explaining the data source, the grouping logic, the metrics calculated, and the unusual date behavior. It does not describe the exact return format, but for an optional-parameter report tool the missing detail is minor.

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 100%, so the schema already explains both parameters. The description's note about accumulated balances reinforces the 'informativo' qualifier in the schema but does not add new parameter-level meaning beyond what is already structured.

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 is verb-driven and resource-specific: it 'generates a profit and loss account' from the Chart of Accounts and names the exact accounting groups and metrics (EBIT, BAI, BDI). This distinguishes it from siblings like holded_get_balance_sheet and holded_get_vat_summary without needing to open their schemas.

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 gives clear context that this tool is for P&L reporting, so an agent can infer when to select it over balance-sheet or VAT-report siblings. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5, but the context is unambiguous enough for routing.

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

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

With no annotations, the description carries the behavioral disclosure burden. The verb 'Obtiene' reasonably implies a read-only retrieval with no side effects, which is useful. However, it does not mention response format, pagination, rate limits, or authentication expectations, though the zero-parameter nature reduces the risk.

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 one short, focused sentence that states the action and the target resource with no filler. It is immediately parseable and front-loaded.

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?

For a zero-parameter, no-output-schema tool, the description is largely complete: it identifies the resource as the configured taxes in Holded. It does not describe the shape of the returned list, but the simple nature of the tool makes this a minor gap rather than a blocking omission.

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?

The tool has zero parameters and the schema coverage is 100%, so there are no parameter meanings for the description to clarify. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter detail.

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 uses a specific verb ('Obtiene') and a clear resource ('la lista de impuestos configurados en Holded'), making it evident that this tool returns the configured taxes. It is distinct enough from siblings like holded_get_vat_summary, though it does not explicitly differentiate itself from that related report tool.

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 guidance about when to use this tool versus alternatives such as holded_get_vat_summary or holded_list_documents. The description implies a simple retrieval operation but does not state any context, exclusions, or sibling comparisons.

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

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

Sin anotaciones, la descripción asume el peso: revela el algoritm (472/477, diferencia, resultado a ingresar o compensar/devolver), la fuente de datos (cuadro de cuentas) y el comportamiento acumulativo. Dado que es una operación de lectura/consulta, no hay mutaciones ni efectos colaterales que documentar.

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?

Dos frases escuetas, con el propósitoo al inicio y una nota breve al final. No hay relleno ni reduncancia con los campos estructurados del esquema.

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?

Aunque no hay output schema, la descripción enumera qué devuelve: saldos 472 y 477, diferencia y clasificación del resultado. También advierte sobre la acumulación y el carácter informativo de las fechas. Para una herramienta de conslta de baja complejidad, no falta información esencial.

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?

El esquema ya descrive ambos parámetros al 100% (startDate/endDate) indicando que son informativos y que los saldos son acumulados; la descripción no añade sintaxis ni formatos nuevos. Por eso se mantiene el baseline de 3.

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?

La descripción identifica un recurso específico (resumen de IVA) y una acción clara: mostrar saldos de IVA soportado (472) y IVA repercutido (477), calcular la diferencia e indicar si es a ingresar o a compensar/devolver. Esto la diferencia de las herramientas de listados o balances generals. Aunque no nombr alternatives, el propósitoo es inambigüo.

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?

No nombr alternatives ni exclusiones explícitas, pero describe un contexto claro: sirve para el resumen de IVA y la nota explica que los saldos son acumulados del cuadro de cuentas, lo que implica que las fechas son informativas. Esto evita que el agente espere un filtrado por rango temporal aunque no se diga cuándo no usar la herramienta.

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

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

With no annotations, the description carries the full burden. It reveals that the call is a read-only style check and returns uptime, so it is not misleading, but it does not disclose behavior such as error responses, failure handling, or whether any server-side state is changed. The basic behavior is transparent but thin.

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 front-loaded sentence with no filler or repetition. It states the verb, the resource, and the returned value in under fifteen words.

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?

For a zero-parameter, no-output-schema tool, the description provides enough to invoke it and interpret the main return value (uptime). It could be more complete by describing the exact status/response format, but nothing about required inputs is missing.

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?

The tool has zero parameters and the input schema is empty, so there are no parameter semantics for the description to add; the baseline for zero-parameter tools applies. The description mentions uptime, which is the relevant operational output, not a parameter.

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 uses a specific verb ('Comprueba') and resource ('estado del servidor MCP') and states the return value ('tiempo de actividad'). This clearly differentiates the tool from the sibling data-retrieval tools such as holded_list_accounts or holded_get_document.

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 intended use is implied by 'Comprueba el estado del servidor MCP'—an agent can infer it is for server health checks—but the description does not explicitly state when to prefer it or rule out alternatives. No usage exclusions or prerequisites are mentioned.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states that the action is a listing operation and describes the optional filter behavior (group by first digit of the account code). It does not mention pagination or output format, but for a simple read-only list tool, the core behavior is transparent enough.

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 concise: two short sentences in Spanish, with the core action front-loaded and the optional parameter explained in the second sentence. No filler or redundant details are present.

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?

The tool has only one optional parameter and no output schema, so the description does not need extensive context. It explains what the tool lists and how the filter works, which is sufficient for an agent to select and invoke it correctly. A small gap is the absence of details about the returned account fields, but this is minor for a simple list operation.

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?

The input schema already describes the only parameter 'group' at 100% coverage with the same meaning: filtering by first digit of the account code 1-9. The description essentially repeats this information in natural language without adding new semantic details, so it sits at the schema-coverage baseline.

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 uses a specific verb ('Lista') and a precise resource ('las cuentas del Plan General Contable configuradas en Holded'), making its function immediately clear. It also distinguishes itself from sibling tools that list other resources like documents, contacts, or treasury items.

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 implies the tool should be used when an agent needs to list the chart of accounts configured in Holded, optionally filtered by PGC group. However, it provides no explicit guidance on when not to use it or which sibling tool to prefer for other accounting data, such as ledger entries or balance sheets.

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

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

Without annotations, the description carries the full burden of disclosing behavior. It conveys a read-only list action and the optional type filter, but does not mention output structure, pagination, or any edge cases beyond the schema. The basic behavior is clear, but richer disclosure is absent.

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?

Two short sentences with no filler. The main action is front-loaded and the optional filter is stated efficiently. Every word contributes to understanding.

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?

For a simple list tool with one optional parameter, no output schema, and no annotations, the description covers the essential purpose and scope. It could be completeer by naming the debtor/creditor enum values or indicating the response shape, but that is a minor gap given the tool's simplicity.

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 100%, and the parameter's own description ('Filter by contact type') plus enum fully define the valid values. The description only reiterates that filtering is optional, adding little beyond the schema. Baseline 3 is appropriate because the schema already covers the parameter.

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 states the tool lists all Holded contacts (customers and suppliers) and can optionally filter by type. It specifies a concrete verb and resource, but does not explicitly distinguish itself from sibling tools like holded_get_contact, relying instead on the obvious singular/plural difference.

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 guidance about when to choose this tool over alternatives such as holded_get_contact or holded_list_accounts. The statement 'optionally filters by type' only describes parameter usage, not tool-selection context or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool retrieves entries and can filter them; it does not state whether the operation is read-only, how results are returned, whether pagination exists, or any other runtime behavior. The description is not misleading, but it is thin on behavioral detail.

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, front-loaded sentence that states the core purpose first and then the optional filtering capability. Every phrase earns its place, and there is no redundant or filler content.

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?

For a simple list-type tool with three optional parameters, the description is reasonably complete: it states what is returned and what filters are available. However, with no output schema and no annotations, details such as response format, pagination, and whether the operation is read-only are left unspecified.

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 100%, so the schema already documents all three parameters. The description adds a high-level note about filtering by date range and account number, but it does not provide additional semantic detail beyond what the schema already includes.

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 states the operation ('Obtiene los asientos del libro diario de Holded') and the resource, making it distinct from the sibling tools that target accounts, documents, contacts, or treasury items. It does not explicitly name an alternative, but the resource is specific enough that an agent can tell it apart from the other listed tools.

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 implies the tool is used to retrieve daily ledger entries and mentions optional filters, but it gives no explicit guidance on when to choose this tool over alternatives or any exclusions. The intended use case is understandable but not directly stated as a recommendation.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the basic listing/filtering behavior, but does not mention pagination, default ordering, response format, permission requirements, or any limits. This is a read operation by implication, but that is not explicit.

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 concise sentence that front-loads the core purpose and then mentions optional filters. It wastes no words, though it is brief enough that some behavioral details are omitted.

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?

The tool has 6 parameters, no output schema, and no annotations, yet the description only summarizes the input filtering behavior. It does not describe the return structure, pagination behavior, default sort, or other details an agent would need to confidently interpret the result of a list operation.

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 100%, so the schema already documents every parameter. The description adds only a general paraphrase of the date-range and contact filters, without providing additional semantics or clarifying the paid and sort parameters beyond what the schema already states.

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 uses a clear verb ('Lista') and resource ('documentos de facturación de Holded') with a scoping qualifier ('por tipo'). It is distinguished from sibling list tools by being specific to documents, and from holded_get_document by listing instead of fetching a single document.

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 implies when to use the tool: when listing Holded billing documents by type, optionally filtered by date range or contact. However, it does not explicitly state when not to use it or mention alternatives such as holded_get_document for retrieving a single document.

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

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

No annotations are present, so the description carries the full behavioral burden. It discloses that the tool lists payments and supports optional filtering by date range, but it does not mention pagination, return format, ordering, rate limits, or authentication requirements. Some useful behavior is disclosed, but key traits are missing.

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 two short sentences with no filler. The primary action is front-loaded, and the optional filter is stated as a secondary clause. Every word earns its place.

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?

For a simple list tool with two optional, well-documented parameters, the description is adequate for invoking correctly. However, there is no output schema and the description does not describe what fields a payment record contains, whether results are paginated, or any response envelope details. It is sufficient but not complete.

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 100%, so the schema already documents startDate and endDate with formats. The description's mention of 'rango de fechas' adds a conceptual layer but does not provide additional semantic detail beyond what the schema already states. This matches the baseline for fully covered parameters.

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 states a specific verb and resource: 'Lista los pagos registrados en Holded' (lists payments registered in Holded). It also mentions the optional date-range filter, which adds scope. It does not explicitly differentiate itself from sibling list tools, but the resource 'pagos' is distinct enough for basic selection.

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 implies when to use the tool: to list payments and optionally filter by date range. However, it provides no explicit guidance about when not to use it or how it compares to alternatives like list_treasuries or list_documents. The usage context is implied rather than directly stated.

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

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

There are no annotations, so the description carries the behavioral burden. It does convey that the operation is a non-destructive listing of all configured treasury accounts, which is minimally transparent. However, it does not mention pagination, permissions, error behavior, or output shape, though these are less critical for a parameterless list tool.

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?

A single, front-loaded sentence states the operation, the object, and examples of what counts as a treasury account. There is no filler, repetition, or unnecessary detail.

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?

For a zero-parameter listing operation, the description is adequate: an agent knows what the tool returns conceptually and that no arguments are needed. The lack of an output schema and absence of any mention of returned fields is a minor gap, but the low complexity keeps the description mostly complete.

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?

The tool has zero parameters and the schema properties are empty, so there is nothing for the description to explain. The description's 'todas' reinforces the unbounded scope, matching the parameterless design. This aligns with the baseline of 4 for parameterless tools.

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 uses a specific verb ('Lista') and a clear resource ('cuentas de tesorería'), with useful examples (bancos, cajas) that clarify the domain. It does not explicitly differentiate from the sibling holded_list_accounts, but the treasury-account scope is specific enough to avoid serious confusion.

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 gives no guidance on when to choose this tool over alternatives such as holded_list_accounts or holded_list_daily_ledger. It only states what it lists, leaving selection decisions to the agent without supporting context.

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