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

With no annotations provided, the description carries full burden but only states it 'creates' without disclosing behavioral traits like permissions needed, whether it's idempotent, rate limits, or what happens on failure. It's a basic statement that doesn't address the mutation risks or operational context.

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, efficient sentence with zero waste—it directly states the tool's purpose without fluff. It's appropriately sized and front-loaded, earning full marks for conciseness.

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 of a creation tool with no annotations, no output schema, and nested objects, the description is incomplete. It doesn't explain what a credit note entails, the expected input structure, or the result, leaving significant gaps for the agent to infer.

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%, with the parameter 'creditNote' documented as 'Credit note data'. The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema does the heavy lifting but doesn't compensate with extra context.

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 'Create a new credit note' clearly states the action (create) and resource (credit note), but it's vague about what a credit note is in this context and doesn't differentiate from siblings like siigo_create_invoice or siigo_create_voucher. It's functional but lacks specificity about the business domain.

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 guidance is provided on when to use this tool versus alternatives like siigo_create_invoice or siigo_get_credit_note. The description doesn't mention prerequisites, typical use cases, or exclusions, leaving the agent without context for 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Create a new customer' implies a write/mutation operation but reveals nothing about permissions required, side effects (e.g., if duplicates are allowed), error handling, or response format. This is inadequate for a tool that likely modifies persistent data.

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, direct sentence ('Create a new customer') with zero wasted words. It's front-loaded and efficiently communicates the core action without unnecessary elaboration, making it easy for an agent 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?

Given the tool's complexity (nested objects, no output schema, and no annotations), the description is insufficient. It lacks details on behavioral traits (e.g., idempotency, error cases), output expectations, or usage context. For a creation tool with significant input structure, more guidance is needed to ensure correct invocation.

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 no parameter-specific information beyond the input schema. However, schema description coverage is 100%, meaning all parameters are documented in the schema itself (e.g., 'customer' object with properties like 'person_type', 'identification'). Thus, the baseline score of 3 is appropriate as the schema handles parameter documentation.

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 'Create a new customer' clearly states the verb ('Create') and resource ('customer'), making the purpose immediately understandable. It distinguishes from sibling tools like 'siigo_update_customer' by specifying creation rather than modification, though it doesn't explicitly contrast with other creation tools (e.g., 'siigo_create_product').

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 alternatives. It doesn't mention prerequisites (e.g., needing customer data), differentiate from similar creation tools, or indicate when not to use it (e.g., for updates). This leaves the agent without contextual usage cues.

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 full burden for behavioral disclosure. 'Create a new invoice' implies a write operation but doesn't specify permissions needed, whether it's idempotent, error handling, or what happens on success/failure. For a mutation tool with complex nested parameters, this is inadequate.

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 extremely concise at just three words with no wasted language. It's front-loaded with the core purpose, though this brevity comes at the cost of completeness for such a complex 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 complex invoice creation tool with nested objects, no annotations, and no output schema, the description is insufficient. It doesn't explain what constitutes valid invoice data, expected responses, error conditions, or how this tool fits within the broader SiiGo accounting system context.

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%, providing good documentation for all parameters. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline for high schema coverage but doesn't enhance understanding of the complex nested structure.

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 'Create a new invoice' clearly states the action (create) and resource (invoice), but it's vague about what constitutes an invoice in this system and doesn't differentiate from sibling tools like siigo_create_credit_note or siigo_create_payment_receipt. It's functional but lacks specificity about the domain context.

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 guidance is provided about when to use this tool versus alternatives like siigo_update_invoice or siigo_create_credit_note. The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent with no context for tool 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 provided, the description carries the full burden of behavioral disclosure. It states 'Create a new accounting journal' which implies a write/mutation operation, but doesn't disclose any behavioral traits such as required authentication, potential side effects, error handling, or what happens on success (e.g., returns the created journal ID). This leaves significant gaps for an agent to understand how to use it safely and effectively.

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, clear sentence with zero wasted words. It's appropriately sized for a simple creation tool and front-loads the essential information ('Create a new accounting journal').

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 (a creation/mutation tool with no annotations and no output schema), the description is incomplete. It doesn't address what the tool returns, error conditions, or behavioral context needed for safe use. While concise, it lacks the depth required for an agent to confidently invoke this tool without additional context.

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 100% description coverage (the single parameter 'journal' is described as 'Journal data'), so the baseline is 3. The tool description adds no additional parameter information beyond what's in the schema—it doesn't explain what 'Journal data' should contain, required fields, or format examples.

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 ('Create') and resource ('accounting journal'), making the purpose immediately understandable. It distinguishes from siblings like 'siigo_get_journal' (read) and 'siigo_get_journals' (list), but doesn't explicitly differentiate from other creation tools like 'siigo_create_invoice' or 'siigo_create_customer' beyond the resource type.

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., required permissions, existing data dependencies), appropriate contexts, or when other tools might be more suitable (e.g., 'siigo_update_customer' for modifications).

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. While 'Create' implies a write operation, it doesn't specify permissions required, whether the action is idempotent, error handling, or what happens on success (e.g., returns an ID). For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.

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, direct sentence with no wasted words, making it easy to parse. It front-loads the key action and resource, though its brevity contributes to gaps in other dimensions like guidelines and transparency.

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 (a creation operation with nested objects), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what data 'paymentReceipt' should contain, what the tool returns, or error conditions. For a mutation tool in a system with many siblings, more context is needed to ensure 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?

The input schema has 100% description coverage, with the single parameter 'paymentReceipt' documented as 'Payment receipt data'. The description adds no additional meaning beyond this, such as required fields or data structure examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

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 ('Create') and the resource ('a new payment receipt'), making the purpose immediately understandable. It distinguishes this tool from read-only siblings like 'siigo_get_payment_receipts' by emphasizing creation. However, it doesn't specify what a 'payment receipt' entails in this context, leaving some ambiguity about the resource's nature.

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 alternatives. It doesn't mention prerequisites, such as needing existing invoice or customer data, or differentiate it from similar creation tools like 'siigo_create_invoice'. Without this context, users must infer usage from the tool name alone.

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 full burden for behavioral disclosure. 'Create a new product' implies a write/mutation operation, but it doesn't disclose any behavioral traits: no information about required permissions, whether the operation is idempotent, what happens on duplicate codes, response format, or error conditions. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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 maximally concise at just three words. It's front-loaded with the core action and resource, with zero wasted words. While it may be too brief for complete understanding, it achieves perfect efficiency within its limited scope.

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 creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after creation (success response, error handling), doesn't mention dependencies on other tools (like needing valid account_group from siigo_get_account_groups), and provides no context about the product lifecycle. Given the complexity implied by 13 nested properties and required fields, this minimal description leaves too much 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?

The description adds no parameter information beyond what's already in the schema. Since schema description coverage is 100% (all parameters have descriptions or enums), the baseline score is 3. The description doesn't explain the significance of required fields like 'account_group', clarify enum meanings, or provide usage examples for nested product properties.

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 ('Create') and resource ('new product'), making the purpose immediately understandable. It distinguishes from sibling tools like siigo_get_product or siigo_update_product by specifying creation rather than retrieval or modification. However, it doesn't explicitly differentiate from other creation tools like siigo_create_customer or siigo_create_invoice, which would require more specific context.

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 alternatives. There's no mention of prerequisites (like needing account groups from siigo_get_account_groups), when to choose this over siigo_update_product, or what distinguishes product creation from other creation operations in the sibling list. The agent must infer usage context from the tool name alone.

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. 'Create a new purchase' implies a write operation, but it does not specify required permissions, whether the action is idempotent, potential side effects (e.g., updating inventory), or error conditions. This leaves significant gaps in understanding how the tool behaves beyond its 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, clear sentence with no wasted words, making it highly concise and front-loaded. It directly communicates the core action without unnecessary elaboration, which is efficient for an AI agent 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 creation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), usage context, and what the tool returns upon success or failure. Given the complexity implied by nested objects in the schema and the absence of structured safety hints, the description does not provide enough context for reliable agent invocation.

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 100% description coverage, with one parameter 'purchase' described as 'Purchase data'. The description does not add any meaning beyond this, as it only repeats the tool's purpose without detailing what 'purchase' should include (e.g., fields, structure, or examples). Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.

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 'Create a new purchase' clearly states the verb ('Create') and resource ('purchase'), making the purpose immediately understandable. It distinguishes from sibling tools like 'siigo_get_purchase' or 'siigo_update_purchase' by specifying creation rather than retrieval or modification. However, it lacks specificity about what a 'purchase' entails in this context (e.g., a transaction, order, or record).

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 guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, such as needing existing customer or product data, or when to choose this over similar tools like 'siigo_create_invoice' or 'siigo_create_voucher'. Without this context, the agent must infer usage from tool names alone.

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. 'Create a new voucher' implies a write operation but doesn't specify permissions required, whether it's idempotent, what happens on failure, or any rate limits. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented, though it doesn't contradict any annotations.

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 extremely concise at three words, which is efficient and front-loaded. However, it's arguably too brief given the lack of context and behavioral details, bordering on under-specification rather than optimal conciseness. It earns a 4 for being direct but loses a point for not including essential clarifying information.

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 of a creation tool with no annotations, no output schema, and nested input objects, the description is incomplete. It doesn't explain what a voucher is, what data it requires, or what the tool returns. With many similar sibling tools, this lack of differentiation and detail makes it inadequate for an agent to use correctly without additional context.

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 100% description coverage, with the single parameter 'voucher' described as 'Voucher data'. The description adds no additional parameter information beyond what the schema provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.

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 'Create a new voucher' clearly states the action (create) and resource (voucher), making the purpose understandable. However, it doesn't differentiate from sibling tools like siigo_create_credit_note or siigo_create_invoice, which follow the same 'Create a new X' pattern, leaving the specific domain of 'voucher' ambiguous without additional context about what a voucher represents in this system.

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 alternatives. With many sibling tools for creating different entities (e.g., siigo_create_credit_note, siigo_create_invoice), there's no indication of what a voucher is used for or when it should be created instead of other document types. The lack of context makes it difficult for an agent to choose appropriately.

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 full burden of behavioral disclosure. 'Delete an invoice' implies a destructive mutation, but it doesn't specify consequences (e.g., irreversible action, impact on accounting records), permissions required, or error handling. This is a significant gap for a destructive 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?

The description is extremely concise with a single sentence, 'Delete an invoice', which is front-loaded and wastes no words. It efficiently communicates the core action 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?

Given the tool's destructive nature, no annotations, and no output schema, the description is incomplete. It lacks critical details like success/error responses, side effects, or usage constraints, making it inadequate for safe and effective use by an AI agent.

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 100% description coverage, with the 'id' parameter documented as 'Invoice ID'. The description adds no additional meaning beyond this, such as format examples or validation rules. Baseline 3 is appropriate since the schema does the heavy lifting.

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 'Delete an invoice' clearly states the action (delete) and resource (invoice), providing a basic purpose. However, it doesn't distinguish this from sibling deletion tools like siigo_delete_payment_receipt or siigo_delete_product, which follow the same pattern, making it vague in differentiation.

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 guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites like needing an existing invoice ID or when deletion is allowed (e.g., before payment). This leaves the agent without context for appropriate invocation.

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 full burden of behavioral disclosure. It states the action is 'Delete,' implying a destructive mutation, but fails to mention critical details like required permissions, whether deletion is permanent or reversible, or any rate limits or side effects. This leaves significant gaps for a destructive 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 a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action 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 destructive tool with no annotations and no output schema, the description is inadequate. It lacks essential context like success/failure behavior, error handling, or system impacts, leaving the agent with insufficient information to use the tool safely and effectively.

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 100% description coverage, with the 'id' parameter clearly documented. The description doesn't add any semantic details beyond the schema, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating value.

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 ('Delete') and the resource ('a payment receipt'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'siigo_delete_invoice' or 'siigo_delete_product' beyond the resource type, missing explicit sibling distinction.

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 guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, consequences, or when to choose deletion over other operations like updating, making it insufficient for informed tool 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 provided, the description carries the full burden of behavioral disclosure but fails completely. 'Delete a product' implies a destructive mutation, but the description doesn't disclose whether deletion is permanent or reversible, what permissions are required, whether there are rate limits, what happens to associated data, or what the response looks like. For a destructive operation with zero annotation coverage, this is dangerously inadequate.

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 maximally concise at just three words. While this represents severe under-specification in terms of content, from a structural perspective it's perfectly front-loaded with zero wasted words. Every word ('Delete', 'a', 'product') contributes directly to the core purpose statement.

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 destructive mutation tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what constitutes successful deletion, what errors might occur, what permissions are needed, or any behavioral nuances. The agent cannot safely or effectively use this tool based on the provided description alone.

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 100% description coverage (the 'id' parameter is fully documented as 'Product ID'), and there's only one parameter. The description adds no parameter information beyond what the schema provides, but with complete schema coverage and minimal parameters, the baseline is appropriately high. The description doesn't need to compensate for any gaps.

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 'Delete a product' is a tautology that merely restates the tool name 'siigo_delete_product'. While it identifies the action (delete) and resource (product), it provides no additional specificity about what constitutes a product in this context or how deletion works. It doesn't distinguish this tool from sibling deletion tools like 'siigo_delete_invoice' or 'siigo_delete_purchase' beyond the resource name.

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 absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites (e.g., product must exist), consequences, or when to choose this over other product-related tools like 'siigo_update_product' or 'siigo_get_product'. The agent receives zero contextual direction about appropriate usage scenarios.

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 must fully disclose behavioral traits. 'Delete a purchase' implies a destructive mutation but offers no details on permissions, reversibility, side effects, or error handling. This is inadequate for a tool that permanently removes data, leaving critical behavioral aspects unspecified.

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 extremely concise with just three words, front-loaded and free of unnecessary elaboration. Every word earns its place by stating the core action, though this brevity comes at the cost of completeness.

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 as a destructive operation with no annotations or output schema, the description is severely incomplete. It lacks essential context such as confirmation requirements, impact on related records, or response format, making it inadequate for safe and effective use.

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%, with the single parameter 'id' documented as 'Purchase ID'. The description adds no additional meaning beyond this, so it meets the baseline score of 3 where the schema handles parameter documentation effectively.

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 'Delete a purchase' is a tautology that merely restates the tool name without adding specificity. It doesn't clarify what constitutes a 'purchase' in this context or how deletion works, though it does include the verb 'delete' and resource 'purchase' which provides minimal clarity.

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 guidance is provided on when to use this tool versus alternatives. With sibling tools like 'siigo_delete_invoice' and 'siigo_delete_payment_receipt', the description fails to differentiate this deletion operation from others or specify prerequisites, making it misleadingly simplistic for a destructive action.

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. 'Get' implies a read operation, but it doesn't disclose behavioral traits like whether it's safe (non-destructive), requires authentication, has rate limits, returns paginated results, or handles errors. For a tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by conveying the essential purpose 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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks context on behavior, usage, or output. For a read operation with no structured data, it should ideally add more about return values or constraints to be fully helpful.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate. Baseline is 4 for 0 params, as it avoids redundancy. No compensation is required since there are no parameters to explain.

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 'Get account groups catalog' clearly states the verb ('Get') and resource ('account groups catalog'), making the purpose understandable. It distinguishes from siblings by focusing on account groups rather than invoices, customers, products, etc. However, it doesn't specify what 'catalog' entails (e.g., list, details, structure), leaving some ambiguity compared to a perfect 5.

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 alternatives. With siblings like 'siigo_get_accounts_payable' and 'siigo_get_trial_balance', it's unclear if this tool is for general account group listing, specific filtering, or other contexts. No exclusions or prerequisites are mentioned, leaving the agent to infer usage from the name alone.

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. 'Get accounts payable report' implies a read-only operation, but it doesn't specify authentication needs, rate limits, pagination behavior (beyond the schema parameters), or what the report contains (e.g., format, data fields). For a tool with zero annotation coverage, this lacks critical context about how it behaves.

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, efficient phrase with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying the essential purpose without redundancy.

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 of a financial reporting tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the report returns (e.g., list of payable items, summary totals), potential side effects, or error conditions. For a tool that likely involves sensitive data and pagination, more context is needed to guide effective use.

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 100% description coverage, with clear documentation for 'page' and 'page_size'. The description adds no additional meaning beyond implying pagination through the term 'report', which is already covered by the schema. According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.

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 'Get accounts payable report' states the basic action (get) and resource (accounts payable report), which is clear but vague. It doesn't specify what constitutes the report (e.g., list of payable items, summary data) or differentiate it from similar tools like siigo_get_purchases or siigo_get_trial_balance, which might involve financial data. This provides a minimal viable purpose without sibling distinction.

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 offers no guidance on when to use this tool versus alternatives. With siblings like siigo_get_purchases (which might relate to payable transactions) and siigo_get_trial_balance (which could include payable balances), there's no indication of context, prerequisites, or exclusions. This leaves the agent to infer usage from the name alone.

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. 'Get cities catalog' implies a read-only operation, but it does not specify any behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or includes metadata. For a tool with zero annotation coverage, this is a significant gap in 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 'Get cities catalog' is extremely concise with no wasted words, making it easy to parse. It is front-loaded with the core action and resource, though it could benefit from more detail. Every word earns its place, and there is no unnecessary verbosity.

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 has no parameters, no annotations, and no output schema, the description 'Get cities catalog' is incomplete. It does not explain what the tool returns (e.g., a list of cities, their IDs, or other attributes), any usage constraints, or how it fits into broader workflows. For a tool in a complex server with many siblings, this minimal description leaves critical context gaps.

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 0 parameters, and the schema description coverage is 100%, meaning there are no parameters to document. The description does not need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as the description is not required to compensate for any parameter gaps.

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 'Get cities catalog' clearly states the verb 'Get' and resource 'cities catalog', making the purpose understandable. However, it lacks specificity about what 'cities catalog' entails (e.g., a list of cities with details) and does not distinguish it from sibling tools like 'siigo_get_customers' or 'siigo_get_products', which follow a similar 'Get [resource]' pattern. This makes it vague in differentiation.

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 alternatives. It does not mention any context, prerequisites, or exclusions, such as whether it's for reference data, filtering options, or integration with other tools. With many sibling tools available, this lack of usage guidelines leaves the agent without clear direction.

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 full burden. It implies a read operation ('Get'), but doesn't disclose behavioral traits such as authentication needs, rate limits, pagination, or error handling. For a tool with zero annotation coverage, this is a significant gap in 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, efficient sentence ('Get cost centers catalog') with no wasted words. It's front-loaded and appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.

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 no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It lacks context on what 'catalog' entails (e.g., list format, fields returned) and behavioral aspects, making it inadequate for an AI agent to fully understand the tool's 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 tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param details, but this is acceptable given the lack of parameters, warranting a baseline score of 4 as it doesn't need to compensate for any gaps.

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 'Get cost centers catalog' states the verb ('Get') and resource ('cost centers catalog'), but it's vague about scope—does it list all cost centers, filter them, or retrieve a specific one? It distinguishes from siblings by focusing on cost centers, but lacks specificity compared to more detailed sibling descriptions like 'siigo_get_invoice_pdf'.

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, and it fails to differentiate from similar 'get' tools like 'siigo_get_accounts_payable' or 'siigo_get_trial_balance' beyond the resource name.

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 full burden but offers minimal behavioral insight. It implies a read-only operation ('Get'), but doesn't disclose authentication requirements, rate limits, error responses, or data format (e.g., JSON structure). For a tool with zero annotation coverage, this is inadequate for safe and effective use.

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, direct sentence with zero wasted words. It front-loads the core purpose ('Get a specific credit note') and efficiently specifies the key constraint ('by ID'). Every word earns its place, 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 tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what data is returned (e.g., credit note fields), error handling, or operational constraints. Given the complexity of financial data retrieval, more context is needed for reliable agent use.

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%, with the single parameter 'id' documented as 'Credit note ID'. The description adds no additional meaning beyond this, such as ID format examples or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the heavy lifting.

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 ('Get') and resource ('a specific credit note by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'siigo_get_credit_notes' (plural) by specifying retrieval of a single entity. However, it doesn't explicitly contrast with other get operations (e.g., 'siigo_get_invoice'), leaving some ambiguity in sibling differentiation.

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a valid credit note ID), compare it to 'siigo_get_credit_notes' for listing multiple notes, or specify error conditions (e.g., handling invalid IDs). This leaves the agent without contextual usage 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?

With no annotations provided, the description carries full burden but only states it 'gets list' without disclosing behavioral traits like pagination behavior (implied by parameters but not explained), authentication needs, rate limits, error handling, or what 'list' entails (e.g., format, fields). This leaves significant gaps for a tool with parameters.

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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, 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 tool with 2 parameters and no annotations or output schema, the description is incomplete. It lacks details on return values (e.g., structure of credit notes), pagination behavior, error cases, or how it differs from similar tools, leaving the agent with insufficient context for effective use.

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 parameters are documented in the schema. The description doesn't add meaning beyond implying list retrieval, which aligns with the schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 verb ('Get') and resource ('list of credit notes from Siigo'), making the purpose understandable. However, it doesn't differentiate from the sibling tool 'siigo_get_credit_note' (singular vs. plural), leaving some ambiguity about when to use each.

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 guidance is provided on when to use this tool versus alternatives like 'siigo_get_credit_note' or other list tools (e.g., 'siigo_get_invoices'). The description lacks context about prerequisites, filtering options, or comparison with 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' suggests a read-only operation, but the description doesn't confirm this or provide details on permissions, error handling, or response format. It lacks critical behavioral context for a tool with no annotation coverage.

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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.

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 low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. However, it lacks details on what the tool returns (e.g., customer object structure) and behavioral aspects, leaving gaps that could hinder an agent's understanding in a no-annotation context.

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 100% description coverage, with the 'id' parameter clearly documented as 'Customer ID'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high 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 clearly states the action ('Get') and resource ('a specific customer by ID'), which distinguishes it from sibling tools like 'siigo_get_customers' (plural) that likely retrieve multiple customers. However, it doesn't explicitly mention what 'Get' entails (e.g., retrieving customer details), making it slightly less specific than a perfect 5.

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 alternatives. It doesn't mention when to choose this over 'siigo_get_customers' for multiple customers, or how it relates to other customer-related tools like 'siigo_create_customer' or 'siigo_update_customer'. Usage context is implied but 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 full burden. It states 'Get list' but doesn't disclose behavioral traits like pagination behavior (implied by parameters but not explained), rate limits, authentication needs, or what data is returned. This is a significant gap for a tool with parameters and no output schema.

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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, 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?

Given no annotations, no output schema, and 3 parameters, the description is incomplete. It doesn't address behavioral aspects like pagination, return format, or error handling, which are crucial for a list-retrieval tool. This leaves the agent with insufficient context to use it effectively.

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 documents all parameters (page, page_size, type). The description adds no meaning beyond the schema, as it doesn't explain parameter interactions, default values, or usage examples. Baseline 3 is appropriate since the schema does the heavy lifting.

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 'Get list of customers from Siigo' clearly states the action (get) and resource (customers), but it's generic and doesn't differentiate from sibling tools like siigo_get_customer (singular) or other list tools. It's functional but lacks specificity about scope or format.

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 guidance is provided on when to use this tool versus alternatives. With siblings like siigo_get_customer (singular) and siigo_update_customer, the description doesn't indicate if this is for bulk retrieval, filtering, or initial exploration, leaving usage ambiguous.

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 full burden for behavioral disclosure. It only states the action ('Get') without details on permissions, rate limits, response format, or side effects. For a read operation, this is minimal but not misleading, though it lacks necessary context for safe invocation.

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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse 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?

Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks details on behavior and usage, making it adequate but with clear gaps in guidance and transparency.

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%, with the parameter 'type' documented as 'Document type filter (FV, RC, NC, FC, CC)'. The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema handles parameter documentation adequately.

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 'Get document types catalog' clearly states the action (Get) and resource (document types catalog), making the purpose understandable. However, it doesn't differentiate from sibling tools like siigo_get_invoices or siigo_get_products, which follow similar 'Get X' patterns, so it lacks specific distinction.

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone without explicit direction.

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 action ('Get') without detailing aspects like whether this is a read-only operation, if it requires authentication, potential rate limits, or the format of the returned catalog. For a tool with zero annotation coverage, this minimal description fails to provide necessary behavioral context, though it does not contradict any annotations.

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, efficient sentence ('Get fiscal responsibilities catalog') that is front-loaded with the core action and resource. There is no wasted verbiage or unnecessary elaboration, making it highly concise and well-structured for quick comprehension.

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 of a catalog retrieval tool with no annotations and no output schema, the description is incomplete. It does not explain what 'fiscal responsibilities' includes, the format of the returned data (e.g., list, object), or any behavioral traits like safety or performance. This leaves significant gaps for an agent to understand the tool's full context and 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 tool has 0 parameters, and the schema description coverage is 100%, meaning there are no parameters to document. The description does not need to add parameter semantics, so it meets the baseline expectation for such cases. No additional value is required, and the description does not introduce any parameter-related confusion.

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 'Get fiscal responsibilities catalog' states a clear verb ('Get') and resource ('fiscal responsibilities catalog'), which provides a basic understanding of the tool's function. However, it lacks specificity about what 'fiscal responsibilities' entails (e.g., tax obligations, regulatory duties) and does not differentiate from sibling tools like 'siigo_get_taxes' or 'siigo_get_document_types', leaving room for ambiguity in a crowded namespace of catalog retrieval 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?

No guidance is provided on when to use this tool versus alternatives. With many sibling tools for retrieving various catalogs (e.g., taxes, document types, payment types), the description does not specify the context or prerequisites for accessing fiscal responsibilities, nor does it indicate any exclusions or recommend other tools for related data, leaving the agent without usage direction.

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 full burden but offers minimal behavioral insight. It implies a read operation ('Get'), but doesn't disclose details like authentication needs, rate limits, response format, or whether it's idempotent. This is inadequate for a tool with zero annotation coverage.

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, efficient phrase ('Get ID types catalog') with zero wasted words. It's front-loaded and appropriately sized for a simple catalog retrieval 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 tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'ID types' entail, the return format, or any behavioral constraints, leaving significant gaps in understanding for the agent.

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 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add param info, but this is appropriate given the empty schema, warranting a baseline score of 4.

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 'Get ID types catalog' clearly states the verb 'Get' and resource 'ID types catalog', making the purpose understandable. It distinguishes from siblings by focusing on ID types rather than other entities like customers or invoices, though it doesn't explicitly contrast with similar 'get' tools like 'siigo_get_document_types'.

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 guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, typical use cases, or comparisons to sibling tools, leaving the agent to infer usage based on naming alone.

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 full burden but only states the action without behavioral details. It doesn't disclose whether this is a read-only operation, requires authentication, has rate limits, returns structured data or errors, or what happens if the invoice doesn't exist—critical for a retrieval 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?

The description is a single, direct sentence with no wasted words, front-loading the core action. It efficiently communicates the tool's purpose without redundancy 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 retrieval tool with no annotations and no output schema, the description is incomplete. It lacks information on return values (e.g., invoice details, error responses), behavioral context (e.g., read-only nature, potential failures), and usage guidelines, leaving gaps for an AI agent to operate effectively.

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%, with the parameter 'id' documented as 'Invoice ID'. The description adds minimal value beyond the schema by implying the ID is used to fetch a specific invoice, but doesn't elaborate on format, validation, or examples. Baseline 3 is appropriate given high 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 clearly states the verb ('Get') and resource ('a specific invoice'), specifying it's by ID. It distinguishes from sibling tools like 'siigo_get_invoices' (plural) by indicating retrieval of a single invoice, but doesn't explicitly contrast with other get operations for different resources.

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 guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid invoice ID), compare with 'siigo_get_invoices' for listing multiple invoices, or specify error conditions (e.g., invalid ID).

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 must fully disclose behavioral traits, but it offers none. It does not indicate whether this is a read-only operation, if it requires authentication, potential rate limits, error conditions (e.g., invalid ID handling), or the format of the PDF output (e.g., binary data, download link). The description fails to add any context beyond the basic action, leaving the agent unaware of how the tool behaves.

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 extremely concise with just three words, making it front-loaded and free of unnecessary details. Every word ('Get', 'invoice', 'PDF') contributes directly to the tool's core function, though it lacks depth. This brevity is efficient, but it borders on under-specification rather than optimal clarity.

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 (a single-parameter retrieval operation), no annotations, and no output schema, the description is incomplete. It does not explain what the tool returns (e.g., a PDF file, error messages), behavioral aspects, or how it fits among siblings. For a tool that likely involves data retrieval and formatting, more context is needed to guide effective use, making this description insufficient.

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 100% description coverage, with the 'id' parameter documented as 'Invoice ID'. The description does not add any semantic details beyond this, such as ID format examples or validation rules. Since the schema already provides adequate parameter information, the baseline score of 3 is appropriate, as the description neither compensates for gaps nor enhances understanding.

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 'Get invoice PDF' is a tautology that restates the tool name 'siigo_get_invoice_pdf' without adding meaningful specificity. It identifies the resource (invoice PDF) but lacks details about what 'get' entails (e.g., download, retrieve, generate) or how it differs from sibling tools like 'siigo_get_invoice' or 'siigo_get_invoices', which may handle non-PDF data. This minimal phrasing fails to clarify the tool's distinct purpose beyond its name.

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 alternatives. It does not mention prerequisites (e.g., needing an existing invoice ID), exclusions, or comparisons to siblings like 'siigo_get_invoice' (which might return structured data) or 'siigo_send_invoice_email' (which involves email delivery). Without any usage context, an agent cannot make informed decisions about tool 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 provided, the description carries full burden but offers minimal behavioral information. It doesn't disclose whether this is a read-only operation, what authentication is needed, whether there are rate limits, what the return format looks like, or how pagination works. The description only states what the tool does at a high level without behavioral details.

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 extremely concise at just 5 words, front-loading the essential purpose with zero wasted words. Every word earns its place, making it easy to parse quickly while still communicating the core function.

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 list retrieval tool with 4 parameters and no output schema, the description is insufficient. It doesn't explain what data is returned, how results are structured, whether there are default behaviors for missing parameters, or how to interpret the pagination parameters. With no annotations and no output schema, users need more context about what to expect from this 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 fully documents all 4 parameters. The description adds no additional parameter information beyond what's in the schema - it doesn't explain how parameters interact, provide examples, or clarify semantics. This meets the baseline for high 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 clearly states the action ('Get list') and resource ('invoices from Siigo'), making the purpose immediately understandable. It distinguishes from siblings like siigo_get_invoice (singular) by indicating it retrieves multiple invoices, but doesn't explicitly differentiate from other list tools like siigo_get_credit_notes or siigo_get_payment_receipts beyond the resource type.

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention when this list tool should be used instead of siigo_get_invoice (for a single invoice) or how it differs from other list tools like siigo_get_credit_notes. There's no context about prerequisites, filtering capabilities, or typical use cases.

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 full burden. It states 'get' which implies a read operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what data is returned. This is a significant gap for a tool with no annotation coverage.

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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient 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?

Given no annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't explain what 'get' returns (e.g., journal details), potential errors, or usage context. For a tool in a system with many siblings, more guidance is needed to be fully helpful.

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 'by ID', which aligns with the single parameter 'id' in the input schema. Schema description coverage is 100%, so the schema already documents the parameter fully. The description adds minimal value beyond what the schema provides, meeting the baseline for high 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 'Get a specific journal by ID' clearly states the action (get) and resource (journal), but it's vague about what 'get' entails (e.g., retrieve details) and doesn't distinguish it from sibling tools like 'siigo_get_journals' (plural) beyond the singular vs. plural naming. It's functional but lacks specificity.

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 guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this is for fetching a single journal's details after listing with 'siigo_get_journals' or for direct access by known ID. The description implies usage by ID but offers no context on prerequisites or alternatives.

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 full burden of behavioral disclosure. It states it 'Get list' but doesn't clarify if this is a read-only operation, whether it requires specific permissions, if there are rate limits, or what the return format looks like (e.g., pagination details beyond the parameters). This leaves significant gaps for a tool with parameters.

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, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, 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?

Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety, permissions, or response format, which are crucial for a tool with parameters. While concise, it fails to provide sufficient context for effective use by an AI agent.

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 100% description coverage, with clear documentation for 'page' and 'page_size'. The description adds no additional parameter semantics beyond implying a list retrieval, which is already evident from the tool name and schema. This meets the baseline of 3 for high 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 clearly states the verb ('Get') and resource ('list of accounting journals from Siigo'), making the purpose immediately understandable. It distinguishes from sibling tools like 'siigo_get_journal' (singular) by specifying it retrieves a list, though it doesn't explicitly contrast with other list tools like 'siigo_get_customers' or 'siigo_get_products'.

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 alternatives. It doesn't mention prerequisites, such as authentication or access rights, or differentiate it from similar list-retrieval tools in the sibling set, like 'siigo_get_journal' for a single journal or other 'get_' tools for different resources.

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 full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation, authentication requirements, error handling, rate limits, or response format, which are critical for a retrieval 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?

The description is a single, efficient sentence that directly states the tool's function with zero wasted words. It's appropriately sized and front-loaded, 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?

Given no annotations and no output schema, the description is incomplete for a retrieval tool. It lacks details on return values, error conditions, or behavioral context, leaving significant gaps for an agent to understand how to use it effectively.

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 100% description coverage, clearly documenting the 'id' parameter. The description adds no additional meaning beyond the schema, such as ID format or examples, so it meets the baseline for high schema coverage without compensating value.

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 verb ('Get') and resource ('a specific payment receipt by ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'siigo_get_payment_receipts' (plural), which likely retrieves multiple receipts, so it misses full sibling distinction.

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 alternatives. It doesn't mention the sibling 'siigo_get_payment_receipts' for listing multiple receipts or other retrieval tools, leaving the agent without context for tool 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 provided, the description carries full burden for behavioral disclosure. While 'Get list' implies a read operation, the description doesn't mention authentication requirements, rate limits, error conditions, or what format the returned data will have. It also doesn't explain that this is a paginated endpoint (implied by the parameters but not 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, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple list retrieval tool and is front-loaded with the essential information.

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 read operation with good schema coverage but no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks important context about authentication, error handling, return format, and differentiation from similar tools. The absence of an output schema means the description should ideally provide more information about what data is returned.

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 100% description coverage with clear parameter documentation, so the baseline is 3. The tool description adds no additional parameter information beyond what's already in the schema, but doesn't need to compensate for any gaps since schema coverage is complete.

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 verb ('Get') and resource ('list of payment receipts from Siigo'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'siigo_get_payment_receipt' (singular), which appears to retrieve a single receipt versus this tool's list 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?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention the pagination parameters or explain when this list retrieval is appropriate compared to the singular 'siigo_get_payment_receipt' tool or other data retrieval tools in the system.

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 full burden for behavioral disclosure. It states 'Get' which implies a read operation, but doesn't clarify if this requires authentication, has rate limits, returns paginated results, or what format the catalog takes. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and doesn't include unnecessary elaboration. 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?

Given the tool's simple purpose (retrieving a catalog), one parameter with full schema coverage, and no output schema, the description is minimally adequate. However, it lacks context about authentication requirements, return format, or error conditions that would be helpful for a tool without annotations.

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 100% description coverage for its single parameter 'document_type', which is documented as a filter. The description doesn't add any parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 verb 'Get' and the resource 'payment types catalog', making the purpose immediately understandable. It distinguishes itself from siblings by focusing on payment types rather than other entities like invoices or customers. However, it doesn't specify whether this retrieves all payment types or a subset, which prevents a perfect score.

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 alternatives. It doesn't mention prerequisites, context for usage, or differentiate from similar tools like siigo_get_document_types or siigo_get_taxes. The agent must infer usage from the name alone.

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 full burden of behavioral disclosure. It states 'Get' which implies a read operation, but it doesn't specify if it's safe, requires authentication, has rate limits, or what the output looks like. This is a significant gap for a tool with no annotation coverage.

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, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, 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?

Given the tool has 0 parameters, no annotations, and no output schema, the description is minimal but adequate for a simple read operation. However, it lacks details on output format, error handling, or behavioral traits, which could be important for an AI agent to use it 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 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add parameter details, which is acceptable, but it also doesn't clarify if there are implicit parameters or constraints, so it's not a perfect score.

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 'Get price lists catalog' clearly states the verb ('Get') and resource ('price lists catalog'), making the purpose understandable. It distinguishes from sibling tools that create, delete, or update resources, but it doesn't specify what 'price lists' entail or how it differs from similar 'get' tools like 'siigo_get_products'.

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 guidance is provided on when to use this tool versus alternatives. The description lacks context such as prerequisites, timing, or comparisons with other 'get' tools in the sibling list, leaving the agent to infer usage based on the name alone.

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 full burden. It mentions 'Get' which implies a read operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or response format. This leaves significant gaps for an agent to understand how to use it effectively.

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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, 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?

Given no annotations, no output schema, and a simple input schema, the description is minimal. It covers the basic purpose but lacks context on usage, behavior, or output, making it incomplete for effective tool selection and invocation by an agent.

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 the 'id' parameter fully. The description adds no additional meaning beyond implying the parameter is used to identify a product, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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 verb ('Get') and resource ('a specific product'), making the purpose evident. It distinguishes from the sibling 'siigo_get_products' by specifying retrieval of a single item by ID, though it doesn't explicitly mention this distinction.

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 guidance is provided on when to use this tool versus alternatives like 'siigo_get_products' for listing multiple products or other get_* tools for different resources. The description only states what it does, not when it's appropriate.

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 full burden of behavioral disclosure. It states this is a 'Get list' operation, implying it's read-only, but doesn't mention any behavioral traits like pagination behavior (though parameters suggest it), rate limits, authentication requirements, or what format the list returns. The description is minimal and lacks important operational context.

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 extremely concise at just 5 words, front-loaded with the core purpose. There's zero wasted language or unnecessary elaboration, making it efficient for quick 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 list retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information the product list contains, how results are structured, whether there are filtering options beyond pagination, or any error conditions. The minimal description leaves too many operational questions unanswered.

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%, with both parameters (page and page_size) clearly documented in the schema. The description doesn't add any parameter semantics beyond what the schema provides, but with complete schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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 ('Get list') and resource ('products from Siigo'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'siigo_get_product' (singular), which presumably retrieves a single product rather than a list.

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 alternatives. There are multiple sibling tools for retrieving different resources (e.g., siigo_get_customers, siigo_get_invoices), but no indication of when this specific product listing tool is appropriate versus other get operations.

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 full burden but only states the basic operation. It doesn't disclose behavioral traits such as whether this is a read-only operation, error handling for invalid IDs, authentication requirements, rate limits, or response format. For a tool with zero annotation coverage, this leaves significant gaps.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

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 moderate complexity (retrieving a specific entity by ID), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned, error conditions, or how it differs from sibling tools, leaving the agent with insufficient context for optimal use.

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 100% description coverage (parameter 'id' is documented as 'Purchase ID'), so the description adds no additional parameter information beyond what's already in the schema. According to guidelines, this results in a baseline score of 3, as the schema adequately covers 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?

The description clearly states the action ('Get') and resource ('a specific purchase by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'siigo_get_purchases' (plural) which likely retrieves multiple purchases, leaving some ambiguity about when to use each.

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 guidance is provided on when to use this tool versus alternatives like 'siigo_get_purchases' for listing multiple purchases or 'siigo_update_purchase' for modifications. The description assumes context but offers no explicit usage rules or prerequisites.

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 full burden. It states 'Get list' which implies a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or whether it returns all purchases or requires pagination. The description is minimal and lacks context about what 'purchases' includes or how results are structured.

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, efficient sentence with zero waste. It's front-loaded with the core action and resource. However, it's arguably too concise given the lack of annotations and sibling tools, leaving gaps in usage context that could be addressed with slightly more 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?

Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what a 'purchase' entails in this system, how results are returned, or any limitations. For a tool with multiple siblings and potential complexity in financial data, more context is needed to guide effective use.

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%, with both parameters ('page' and 'page_size') clearly documented in the schema. The description adds no additional parameter semantics beyond implying list retrieval. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description doesn't compensate or enhance parameter understanding.

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 'Get list of purchases from Siigo' clearly states the verb ('Get') and resource ('purchases'), but it's vague about scope and doesn't differentiate from sibling tools like 'siigo_get_purchase' (singular) or 'siigo_get_invoices'. It specifies 'list' which helps distinguish from single-item retrieval, but lacks detail on what constitutes a purchase in this context.

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 guidance is provided on when to use this tool versus alternatives. With siblings like 'siigo_get_purchase' (singular) and 'siigo_get_invoices', the description doesn't indicate whether this is for bulk retrieval, filtered queries, or general listing. There's no mention of prerequisites, constraints, or typical use cases.

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 full burden. It implies a read-only operation ('Get'), but doesn't disclose behavioral traits like authentication needs, rate limits, response format, or error handling. This is inadequate for a tool with zero annotation coverage.

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, efficient phrase ('Get taxes catalog') with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to scan and understand 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?

Given no annotations, no output schema, and low complexity (0 parameters), the description is incomplete. It lacks context on what 'taxes catalog' includes (e.g., tax rates, types, jurisdictions), how results are structured, or any operational constraints, making it insufficient for reliable agent use.

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 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add param details, which is appropriate, but it could hint at implicit filters or options (e.g., by region), though not required. Baseline is 4 for zero 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 'Get taxes catalog' clearly states the action (get) and resource (taxes catalog), but it's vague about scope and format. It doesn't differentiate from sibling 'get' tools (e.g., siigo_get_customers, siigo_get_products) beyond the resource name, lacking specificity about what 'catalog' entails.

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., for invoicing or reporting), or exclusions, leaving the agent to infer usage from the name alone among many similar 'get' 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 full burden. It states 'Get trial balance report', implying a read-only operation, but does not disclose behavioral traits such as authentication requirements, rate limits, data format, or whether it's a safe operation. This leaves significant gaps in understanding how the tool behaves.

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 extremely concise with a single phrase, 'Get trial balance report', which is front-loaded and wastes no words. It efficiently communicates the core purpose without unnecessary elaboration, making it highly structured for quick comprehension.

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 (6 parameters, no output schema, and no annotations), the description is insufficient. It lacks details on return values, error handling, or operational context, leaving the agent with incomplete information to effectively use the tool beyond basic parameter input.

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%, with all parameters well-documented in the input schema. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or usage examples. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 'Get trial balance report' clearly indicates a retrieval action ('Get') and specifies the resource ('trial balance report'), which distinguishes it from siblings like 'siigo_get_trial_balance_by_third'. However, it lacks specificity about what a trial balance entails (e.g., financial summary of accounts), making it somewhat vague but still functional.

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 guidance is provided on when to use this tool versus alternatives. While siblings include 'siigo_get_trial_balance_by_third', the description does not mention this or any other context for selection, leaving usage entirely implicit based on the tool name alone.

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 full burden but only states it 'gets' a report without disclosing behavioral traits like whether it's read-only, requires authentication, has rate limits, or what the output format is. It lacks details on data retrieval, permissions, or system impact, making it insufficient for a tool with complex parameters.

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, efficient sentence with no wasted words, making it front-loaded and easy to parse. However, it's overly concise to the point of under-specification, slightly reducing its effectiveness despite good structure.

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 (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the report's output, usage context, or behavioral aspects, leaving significant gaps for an AI agent to understand and invoke the tool correctly in a system with many siblings.

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 parameters like 'account_start', 'year', and 'includes_tax_difference' are documented in the schema. The description adds no additional meaning beyond implying a third-party focus, which doesn't clarify parameters. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 'Get trial balance by third party report' states the action (get) and resource (trial balance report), but it's vague about what 'by third party' means and doesn't differentiate from sibling 'siigo_get_trial_balance'. It provides a basic purpose but lacks specificity about the report's nature or scope.

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 guidance is provided on when to use this tool versus alternatives like 'siigo_get_trial_balance' or other financial reporting tools. The description implies a third-party focus but doesn't specify use cases, prerequisites, or exclusions, leaving the agent without contextual direction.

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. 'Get users catalog' implies a read-only operation, but it lacks details on permissions, rate limits, pagination, or response format. This is inadequate for a tool with zero annotation coverage, leaving significant gaps in understanding its behavior.

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 extremely concise ('Get users catalog') and front-loaded with the core action. There's no wasted language, making it efficient for quick comprehension, though this brevity contributes to gaps in other dimensions.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'users catalog' entails, the return format, or any behavioral aspects like error handling. For a tool in a complex system with many siblings, more context is needed to ensure proper 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 input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline score of 4 is given as it aligns with the schema's completeness, though it doesn't provide extra value beyond confirming the lack of 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 'Get users catalog' clearly states the verb ('Get') and resource ('users catalog'), making the tool's purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'siigo_get_customer' or 'siigo_get_customers', which follow a similar pattern but target different resources.

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 alternatives. With many sibling tools for retrieving different catalogs (e.g., 'siigo_get_customers', 'siigo_get_products'), there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.

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 full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens if the ID doesn't exist. For a retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval operation and front-loads the essential information.

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 read operation with one well-documented parameter and no output schema, the description is minimally adequate. However, without annotations or output schema, it doesn't address what the tool returns (voucher details, format, structure) or error handling, leaving some contextual gaps for the agent.

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 100% description coverage, with the single parameter 'id' clearly documented as 'Voucher ID.' The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 ('Get') and resource ('a specific voucher by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'siigo_get_vouchers' (plural) which likely retrieves multiple vouchers, leaving some ambiguity about when to use this specific retrieval method.

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 alternatives. With siblings like 'siigo_get_vouchers' (likely for listing multiple vouchers) and 'siigo_get_invoice' (for similar single-resource retrieval), there's no indication of context, prerequisites, or exclusion criteria for this specific voucher retrieval.

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 full burden but offers minimal behavioral insight. It implies a read-only operation ('Get list') but doesn't disclose critical traits like pagination behavior (implied by parameters but not explained), rate limits, authentication needs, or error handling. This is inadequate for a tool with parameters.

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, efficient sentence with zero wasted words. It's front-loaded with the core action ('Get list of vouchers') and includes clarifying parenthetical information ('cash receipts'), making it highly concise and well-structured.

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 no annotations, no output schema, and a read operation with parameters, the description is incomplete. It fails to explain behavioral aspects like pagination, return format, or error conditions, leaving significant gaps for an AI agent to understand tool usage effectively.

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 parameters 'page' and 'page_size' are documented in the schema. The description adds no additional meaning beyond implying list retrieval, which the schema already supports. Baseline 3 is appropriate as the schema handles parameter documentation.

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 verb ('Get') and resource ('list of vouchers (cash receipts) from Siigo'), making the purpose unambiguous. However, it doesn't differentiate from its sibling 'siigo_get_voucher' (singular), which likely retrieves a single voucher, leaving some ambiguity about scope.

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 guidance is provided on when to use this tool versus alternatives like 'siigo_get_voucher' or other list-retrieval tools (e.g., 'siigo_get_invoices'). The description lacks context about prerequisites, such as authentication or data availability, leaving usage unclear.

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. 'Get' implies a read-only operation, but it doesn't disclose behavioral traits such as authentication requirements, rate limits, pagination, error handling, or what the output looks like (e.g., list format, fields). This leaves significant gaps for an agent to understand how to use it effectively.

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, efficient phrase ('Get warehouses catalog') that is front-loaded and wastes no words. However, it could be slightly more informative without losing conciseness, such as by specifying the scope (e.g., 'Retrieve all warehouses').

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 no annotations, no output schema, and 0 parameters, the description is minimal. It states the purpose but lacks completeness for a retrieval tool: it doesn't explain the return values (e.g., list of warehouses with IDs and names), behavioral context, or usage compared to siblings. This makes it inadequate for an agent to fully understand the tool's 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 has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, but since there are no parameters, this is acceptable. A baseline of 4 is appropriate as the description doesn't need to compensate for missing param info.

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 'Get warehouses catalog' clearly indicates a retrieval operation ('Get') on a specific resource ('warehouses catalog'), which is better than a tautology. However, it lacks specificity about what 'warehouses catalog' entails (e.g., list of warehouses, their details) and doesn't distinguish from siblings like 'siigo_get_products' beyond the resource name.

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 guidance is provided on when to use this tool versus alternatives. While siblings include other 'get' tools for different resources (e.g., 'siigo_get_products'), the description doesn't mention any context, prerequisites, or exclusions for selecting this tool over others.

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 full burden. 'Send invoice by email' implies a write operation that transmits data externally, but it doesn't disclose behavioral traits like whether this action is reversible, what permissions are required, how email delivery is confirmed, or potential side effects (e.g., updating invoice status). This leaves significant gaps for an agent to understand the tool's behavior.

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 extremely concise at three words, front-loaded with the core action, and contains no wasted words. Every element ('Send', 'invoice', 'by email') contributes directly to understanding the tool's function.

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 of an email-sending operation with no annotations and no output schema, the description is incomplete. It doesn't address what happens after sending (e.g., success/failure indicators, return values, or side effects), which is critical for an agent to use this tool effectively in a workflow.

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 (id, mail_to, copy_to) with clear descriptions. The description adds no additional meaning beyond what's in the schema, such as explaining the relationship between parameters or usage examples. This meets the baseline of 3 when schema coverage is high.

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 'Send invoice by email' clearly states the action (send) and resource (invoice) with the delivery method (by email), which is specific enough to understand the basic function. However, it doesn't differentiate this tool from potential alternatives like 'siigo_get_invoice_pdf' or explain what 'send' entails beyond the obvious email transmission.

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 alternatives. With siblings like 'siigo_get_invoice_pdf' (which might retrieve an invoice for manual sending) and 'siigo_update_invoice' (which might modify invoice status), there's no indication of prerequisites, timing, or distinctions between these operations.

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 full burden for behavioral disclosure. 'Update an existing customer' implies a mutation operation, but it doesn't disclose any behavioral traits: no information about required permissions, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. This leaves significant gaps for a mutation 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?

The description is perfectly concise at just three words. It's front-loaded with the essential information (update operation on customer resource) with zero wasted words. Every word earns its place in this minimal but complete statement of purpose.

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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what the update operation returns, what validation occurs, error handling, or system behavior. The agent lacks crucial context needed to use this tool effectively despite the clear schema documentation.

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 description coverage is 100%, with both parameters clearly documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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 ('Update') and resource ('an existing customer'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'siigo_create_customer' by specifying it's for updates rather than creation. However, it doesn't specify what aspects of the customer can be updated, which prevents a perfect score.

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 alternatives. It doesn't mention prerequisites (like needing an existing customer ID), doesn't differentiate from other update tools (like siigo_update_invoice), and doesn't indicate when not to use it. The agent must infer usage from the tool name alone.

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 tool updates an invoice, implying a mutation, but fails to describe critical behaviors such as required permissions, whether updates are partial or full, validation rules, error handling, or side effects. This leaves significant gaps for an agent to understand how to use it safely and effectively.

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, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse. Every word contributes directly to stating the tool's purpose without redundancy or 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?

Given the complexity of updating an invoice (a mutation operation with nested objects) and the absence of annotations and output schema, the description is insufficient. It lacks details on behavioral traits, error conditions, response format, and how it integrates with sibling tools. For a tool with potential side effects and no structured safety hints, more context is needed to ensure reliable agent use.

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 100% description coverage, with clear documentation for both parameters ('id' and 'invoice'). The description does not add any semantic details beyond what the schema provides, such as examples of invoice data or format constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.

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 ('Update') and the resource ('an existing invoice'), providing a specific verb+resource combination. It distinguishes itself from sibling tools like siigo_create_invoice (creation) and siigo_delete_invoice (deletion), but does not specify what aspects of the invoice can be updated or how it differs from other update tools like siigo_update_customer.

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 alternatives. It does not mention prerequisites (e.g., needing an existing invoice ID), exclusions, or comparisons to other update tools (e.g., siigo_update_payment_receipt). Usage is implied by the name and context, but no explicit instructions are given.

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 full burden for behavioral disclosure. While 'Update' implies a mutation operation, it doesn't specify required permissions, whether the update is partial or full, what happens to unchanged fields, error conditions, or response format. This leaves significant gaps for a mutation 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?

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and understandable.

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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't address behavioral aspects like permissions, error handling, or response format, nor does it provide usage guidance. The 100% schema coverage helps with parameters but doesn't compensate for other critical gaps.

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 both parameters (id and paymentReceipt). The description adds no additional semantic context about parameter usage, constraints, or examples beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('Update') and resource ('an existing payment receipt'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling update tools like siigo_update_customer or siigo_update_invoice, which follow the same pattern.

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 alternatives. It doesn't mention prerequisites (e.g., needing an existing payment receipt ID), nor does it differentiate from other update operations or indicate when not to use it (e.g., for creating new receipts).

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. 'Update an existing product' implies a mutation operation, but it doesn't specify required permissions, whether changes are reversible, potential side effects (e.g., on related records), or error conditions. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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, efficient sentence with zero waste—'Update an existing product' is front-loaded and directly conveys the core action. Every word earns its place, making it easy to parse quickly 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?

Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), parameter usage beyond the schema, and expected outcomes. For a tool that modifies data, this minimal description leaves too many open questions for effective agent use.

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%, with both parameters ('id' and 'product') documented in the schema. The description doesn't add any meaning beyond what the schema provides—it doesn't clarify the format of 'id', the structure of 'product', or examples of updatable fields. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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 'Update an existing product' clearly states the verb ('update') and resource ('product'), making the purpose immediately understandable. It distinguishes this from sibling tools like siigo_create_product (creation) and siigo_delete_product (deletion), though it doesn't specify what aspects of a product can be updated beyond the generic term.

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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing product ID), compare it to similar update tools (e.g., siigo_update_customer), or indicate scenarios where it's appropriate versus not. Usage is implied by the name but not explicitly 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Update an existing purchase,' implying a mutation operation, but fails to specify required permissions, whether changes are reversible, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.

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, efficient sentence with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, 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 mutation tool with no annotations, no output schema, and two parameters (including a nested object), the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or return values, leaving significant gaps for an AI agent to understand the tool's full context.

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 both parameters (id and purchase). The description adds no additional meaning beyond implying that 'purchase' contains update data, which is already clear from the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('Update') and target resource ('an existing purchase'), making the purpose immediately understandable. However, it doesn't differentiate from sibling update tools like siigo_update_customer or siigo_update_invoice, which follow the same pattern, so it lacks sibling differentiation.

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 alternatives. It doesn't mention prerequisites (e.g., needing an existing purchase ID), exclusions, or comparisons to sibling tools like siigo_create_purchase or siigo_delete_purchase, leaving usage context unclear.

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