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

No annotations were provided, but the description thoroughly discloses behavior: it never books money, remains a draft, lacks a voucher number until approval, and details debit/credit entry logic, including the credit_account override.

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 compact, three sentences, with no fluff. It front-loads the key draft behavior and then explains accounting details and a prerequisite, all relevant and efficiently stated.

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?

Though there is no output schema, the description explains the tool's side effects and accounting flow well. Minor gaps remain regarding expected return values or error conditions, but these are not critical given the overall clarity.

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 description adds meaning for credit_account and booking_date (open fiscal year), but many parameters (iban, reference, business_id, description, invoice_date, supplier_name) are only defined by schema names or minimal schema descriptions. Schema coverage is only 55%, leaving gaps that the description 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?

Clearly states the action 'Create a purchase invoice as a DRAFT' with a specific resource. The draft status and lack of ledger impact differentiate it from other 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?

Provides explicit guidance to call suggest_account first for consistent supplier accounts, and explains the draft workflow and accounting treatment, helping the agent choose when to use this tool.

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 must convey behavioral aspects. It implies a read operation (checking a balance) but does not disclose side effects, error behavior, or permissions. It offers minimal transparency beyond the basic function.

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, succinct sentence that directly conveys the tool's purpose and typical use. There is no unnecessary verbosity or convoluted structure, making it easy to parse.

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 description offers a clear use case but omits essential context such as what the account parameter represents or how the balance is formatted. This leaves some ambiguity for an agent deciding on the call.

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 description clarifies the 'on_date' parameter as 'as of a date', but provides no meaning for the 'account' parameter, which remains undescribed in the schema as well. Since the account is critical to the operation, the lack of semantic explanation is a notable gap.

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 indicates that the tool returns a balance for a specific date, with a clear use case of checking against a bank statement. However, it lacks an explicit verb and the term 'book's balance' is ambiguous, possibly meaning the account balance in the books.

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 a clear context for when to use this tool ('for checking against a bank statement'), but it does not mention any alternatives or explicitly state when not to use it. This gives a reasonable but incomplete usage guideline.

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?

The description implies a read-only operation and describes the returned data (ledger entries, running balance), but it does not clarify behavior when the optional account parameter is omitted, nor does it mention ordering, date inclusivity, or error conditions. With no annotations present, more transparency would be beneficial.

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 conveys the core purpose and output without unnecessary detail. It is well-structured and easy to parse.

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 description covers the main purpose and output shape (entries with running balance), but it omits useful context such as whether all accounts are included when account is absent, sort order, or the exact fields returned. Since there is no output schema, a bit more detail would improve completeness.

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 description mentions a date range and a bank account, which partially maps to the parameters, but the account parameter has no schema description and its optionality is not explained. The date parameter descriptions only give format, not semantics like inclusivity or timezone handling.

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 that the tool returns every ledger entry for a bank account within a date range, including a running balance. It is easily distinguishable from siblings like bank_balance or list_accounts because it emphasizes detailed transaction-level data for reconciliation.

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 explicitly mentions the intended use case: reconciling against a statement. It does not explicitly compare with alternatives or state when not to use it, but the purpose is clear enough to guide selection.

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 must disclose behavior. It states the key refusal condition and the inclusive scope, but does not mention irreversibility, permission requirements, or any side effects beyond deletion. It does not contradict annotations (none).

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 sentences, front-loaded with the main action, then scope clarification. Every word earns its place; no fluff.

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 one-parameter delete tool with no output schema, the description covers the essential usage conditions and exclusions. It could mention error behavior or irreversibility, but these are minor 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?

The schema has one required integer parameter with zero description coverage. The description does not explicitly define voucher_id beyond the tool's context, leaving the agent to infer that it is the identifier of the draft to delete. This is a gap given the lack of schema coverage.

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 states a specific verb (delete) and resource (voucher not yet in ledger), and clarifies the scope by including drafts Kitsas itself created. It clearly distinguishes from sibling tools like list_vouchers and add_purchase_invoice by its destructive nature and target state.

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?

It provides clear conditions for when to use: when a voucher is not yet in the ledger, including drafts. It states what it refuses (ledger vouchers), implying not to use for posted vouchers. However, it does not explicitly name alternatives or provide a 'when not to use' beyond the refusal condition.

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. It does not disclose whether the operation is read-only, how results are returned (single vs. list), or any side effects. The name implies a read operation but this is not explicitly stated.

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 directly conveys the tool's function. It is well-structured and free of unnecessary words, making it easy to parse quickly.

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 search tool, the description provides sufficient context to understand its purpose and input requirements. It does not explain output format or edge cases, but given the lack of an output schema and the tool's simplicity, these omissions are acceptable.

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 has a single 'query' string parameter with no description. The tool description indicates it can be a name, business id, or IBAN, providing some meaning, but it does not clarify matching behavior (exact vs. partial), format expectations, or handling of ambiguous inputs.

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's purpose with a specific verb ('Find') and resource ('partner'), and specifies the search criteria (name, business id, or IBAN). It is distinguishable from sibling tools, none of which are find operations.

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 does not explicitly state when to use this tool over alternatives, but the sibling context (e.g., banking, vouchers) suggests it is for supplier lookup. No explicit conditions or alternatives are mentioned, leaving some ambiguity.

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 'Get' which implies a read operation, but it does not explicitly state that it is read-only, mention error handling (e.g., what happens if the voucher is not found), or describe any side effects. The disclosure is minimal and leaves important behavior to inference.

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, tightly written sentence that front-loads the core purpose and the key output details. There is zero wasted verbiage, and the sentence is immediately clear.

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 simplicity of the tool (one parameter, no output schema, no annotations), the description is adequate but not complete. It specifies that entries and attachment names are included, which is useful, but it omits information about error cases, pagination (if any), or whether the operation is read-only. For a simple get, the description is sufficient for basic use but lacks robustness for an agent to anticipate edge cases.

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 has one parameter, voucher_id (integer), which is self-explanatory by name. However, the description does not mention this parameter at all, and schema description coverage is 0%. The description adds no semantic meaning beyond the schema; the agent must rely on the parameter name and type, which is adequate but not enhanced. With a single obvious parameter, the lack of description is a minor gap, but it does not fully compensate.

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 states a specific verb (Get), a specific resource (one voucher), and adds detail about what is returned (all its entries and attachment names). This clearly distinguishes it from list_vouchers, which presumably returns multiple vouchers. The use of 'one' explicitly signals a single-object retrieval.

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 for retrieving a single voucher, which differentiates it from list_vouchers, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. There is no direct guidance on when to prefer get_voucher over list_vouchers or other siblings.

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 burden. 'List' implies a read-only operation, and the search behavior is described. However, it doesn't explicitly state that no data is modified or mention any side effects, authentication, or rate limits.

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, no unnecessary words, and gets straight to the point. It is well-structured and easy to parse.

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 tool with one optional parameter and no output schema, the description is sufficiently complete. It states the action and the filtering behavior, which is all an agent needs to decide to use it.

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 covers the only parameter 'search' with a clear description, and the tool description reinforces it by explaining that it matches a substring of the name or the start of the number. This adds clarity about optionality and matching rules.

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 the book's chart of accounts, with a specific verb and resource. It is distinct from the sibling tools, which handle drafts, bank balances, fiscal years, suppliers, vouchers, and invoices.

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 clear context for when to use this tool—whenever a list of accounts is needed—and the optional search parameter indicates how to narrow results. It doesn't explicitly reference alternatives, but the purpose is self-explanatory.

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?

The description discloses that confirmed years are immutable ('Nothing can be written into a confirmed year'), which is a behavioral constraint beyond just listing. It does not explicitly state side effects (though listing implies read-only), but the warning adds useful transparency.

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 conveys the purpose and an important behavioral note without 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?

The description fully explains what the tool does (lists fiscal years, identifies current and confirmed) and includes a relevant warning about confirmed years, providing enough context for a user to know when and why to call it.

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 has no parameters, so coverage is complete. The description adds nothing about parameters, but since there are none, this is neutral and meets the 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 clearly states the action ('List') and the resource ('fiscal years'), and specifies the output includes current and confirmed status. This distinguishes it from sibling tools like delete_draft or add_purchase_invoice.

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 does not explicitly mention when to use this tool versus alternatives. The note that nothing can be written into a confirmed year provides indirect guidance (e.g., check before writing), but it lacks clear when-to-use or when-not-to-use instructions.

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 of disclosing behavioral traits. It does not explicitly state that the tool is read-only or has no side effects, although the verb 'list' may imply it. Since no safety or permission information is mentioned, transparency is limited.

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 concise sentences with no redundant words. It front-loads the primary action and then adds a critical conditional behavior, making it easy to parse and remember.

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 operation, the description fully covers what an agent needs to know: what is listed, the required date range, and the optional state filter with its default behavior. No missing context that would prevent correct 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?

Four of five parameters have meaningful descriptions: date_from and date_to include format hints, state gives the integer code meaning, and supplier clarifies it is a partner id. The account parameter lacks any description, preventing full coverage of the parameter semantics.

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?

Clearly states the action (list vouchers), the scope (date range), and the default behavior (ledger vouchers unless a state is given). The verb and object are specific enough to immediately distinguish this from other list-type tools in the sibling set.

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?

Provides no explicit guidance on when to use this tool versus the sibling tools (e.g., get_voucher, list_accounts). The note about state is a behavioral detail, not a comparative usage guideline, so the agent is left to infer when this is the right choice.

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?

The description explains output behavior (most used first, empty for no history) but does not explicitly state whether the operation is read-only or if it has side effects. With no annotations provided, the description carries the full burden, and this omission is a minor gap.

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, consisting of two short sentences with no redundant information. It efficiently conveys purpose, usage, and output behavior without unnecessary elaboration.

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 tool with one parameter and no output schema, the description provides all necessary context: what it does, when to use it, what it returns, and edge cases. Nothing essential 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 parameter 'supplier' is described as 'partner name, or the partner id as a number or a digit string', adding meaningful detail beyond the schema's type definition. This clarifies exactly what values are acceptable and how to provide them.

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's function: suggesting expense accounts based on a supplier's historical bills, ordered by frequency. It distinguishes itself from siblings like list_accounts by being supplier-specific and from add_purchase_invoice by being a pre-step.

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?

Explicitly instructs to call this tool before add_purchase_invoice to ensure recurring suppliers land on the same account, avoiding guesses. This provides clear when-to-use guidance and implies an alternative (guessing) that this tool replaces.

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