LatAm Business Tools

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, non-destructive behavior. The description adds the return object fields but no additional behavioral traits beyond what annotations provide. It is consistent with 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 very concise, consisting of two sentences. It front-loads the main action and includes the return object. Every sentence adds value with no waste.

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

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

The tool has an output schema, so the description does not need to explain return values fully. It covers the purpose, usage context, and basic behavior. For a calculation tool with rich schema coverage and annotations, it is complete enough, though hints about error handling or edge cases could be added.

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 input schema already documents all parameters thoroughly. The description does not add significant meaning beyond the schema; it gives an example for tax_rate and mentions country context. Baseline 3 is appropriate.

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

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

The description clearly states the tool calculates tax amounts from net or gross amounts for a given tax rate with country context. It mentions the return object, providing a specific verb and resource. However, it does not explicitly differentiate from the sibling tool calculate_vat_breakdown_latam, which may have a similar purpose.

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 explicit usage context: 'Use when building pricing tools, invoice calculators, or checkout flows across LatAm markets...' It does not mention when not to use it or alternatives, but the context is clear enough.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not required to restate those. The description adds behavioral context by specifying the return object structure (country, lines_summary, tax_breakdown, etc.) and the required input fields, which is valuable beyond the 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 paragraph that efficiently conveys purpose, input requirements, and output structure. It is front-loaded with the main action. However, it could be slightly more structured (e.g., bullet points) to improve scannability, earning a 4 rather than 5.

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 (multiple countries, tax types) and the presence of an output schema, the description adequately covers what the tool does, required inputs, and general output format. It does not detail every possible scenario but is sufficient for an agent to invoke 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the line item structure in detail, providing tax rate examples (e.g., 16 for Mexico IVA), and clarifying the country-specific tax breakdowns, which the schema does not convey.

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

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

The description clearly states the tool calculates VAT/IVA breakdown for invoice line items in Latin American countries, grouping by tax rate and computing totals. It specifies country-specific tax types (ICMS, PIS, COFINS for Brazil, IVA for others) and the exact return structure. This distinguishes it from the sibling 'calculate_vat_amount_latam', which likely computes a single amount.

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?

While the description explains what the tool does, it lacks explicit guidance on when to use this tool versus alternatives like 'calculate_vat_amount_latam'. The usage context is implied by the breakdown focus, but no direct 'when-to-use' or 'when-not-to-use' is provided.

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

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

The description discloses key behavioral traits beyond annotations: it excludes weekends and national public holidays (including moveable Easter-based holidays). Annotations already indicate readOnlyHint and idempotentHint, and the description adds specific detail on what is excluded.

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

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

The description is concise with three sentences, front-loaded with the core action. It could be slightly more concise, but it efficiently conveys all necessary information 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 simplicity of the tool (3 required params) and the presence of an output schema, the description is complete. It explains the return shape, supported countries, and use cases, leaving no 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 coverage is 100% with descriptions for each parameter. The description adds value by clarifying that dates are inclusive, country codes are two-letter ISO, and listing supported countries (BR, MX, CL, AR, CO). This goes beyond the schema.

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

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

The description clearly states the tool counts working days between two dates for a LatAm country, excluding weekends and public holidays. It lists supported countries and the return shape. This distinguishes it from sibling tools like get_brazil_holidays or get_next_payment_date_latam, which focus on individual holidays or payment dates.

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?

Explicit use cases are provided: cross-border SLA periods, invoice payment deadlines, project timelines. While it does not explicitly state when not to use, the context is clear. No alternative tools are mentioned, but the tool is unique in its functionality among 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?

Annotations already declare readOnlyHint and idempotentHint. Description adds context about moveable holidays, exact count of 15 holidays, and return structure, which is useful beyond 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?

Three sentences, no fluff, front-loaded with key information. Every sentence serves a 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?

Output schema exists, so return values are covered. Description completely covers purpose, usage, and parameter for a simple one-param tool.

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 a clear example. Description adds minimal extra meaning beyond 'for a given year'.

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

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

Clearly states it returns Argentine national public holidays for a given year, specifies the structure and fields, and differentiates from sibling tools for other countries. Includes example use cases.

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

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

Explicitly states when to use (business deadlines, invoice payment dates, scheduling) and implies country-specific use. Does not explicitly state when not to use or alternatives, but country focus is clear.

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?

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: moveable holidays are dynamically calculated using the Easter algorithm, and it returns exactly 12 national holidays defined by federal law. This goes beyond annotations without contradiction.

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

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

The description is two sentences, each earning its place: the first states the core functionality, the second provides usage guidance. No redundant or extraneous 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?

The tool has one required parameter, an output schema (implied by context signals), and the description explains the returned structure and dynamic calculation. For a simple holiday-list tool, this is fully complete and provides all necessary 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 coverage is 100% for the single parameter 'year', with a clear description. The description does not add additional parameter-level information, so the baseline score of 3 is appropriate. The description's mention of '12 national holidays' is a return characteristic, not 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 it returns Brazilian national public holidays for a given year as a structured list, specifying the resource, action, and parameter. It is distinct from sibling tools like get_argentina_holidays or get_chile_holidays because it explicitly focuses on Brazil.

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 explicit use cases: 'Use when calculating business deadlines, invoice payment dates, SLA periods, or scheduling tasks that must avoid non-working days in Brazil.' It does not explicitly state when not to use, but the context is clear and aligns with sibling tools that cover other countries.

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?

Annotations already declare readOnlyHint and idempotentHint, so the tool is safe. Description adds value by disclosing dynamic Easter calculations and the return format, which go beyond 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?

Three sentences: first states main purpose, second details return fields and dynamic behavior, third lists use cases. No redundancy, well front-loaded.

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

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

Given the output schema exists (context signal), the description adequately covers what the tool returns, its dynamic behavior, and its purpose. For a single-parameter tool, it is complete.

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

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

The schema has 100% coverage for the single parameter 'year' with clear description. The description adds an example value but does not add significant semantic value beyond the schema.

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 it returns all Chilean national public holidays for a given year, specifies the return structure ({ date, name, name_en }), mentions dynamic Easter calculations, and notes 16 mandatory holidays. This distinguishes it from siblings like get_argentina_holidays.

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?

Explicit usage scenarios are given: 'calculating Chilean business deadlines, DTE invoice dates, or scheduling tasks that must avoid non-working days in Chile.' It could be improved by noting when not to use (e.g., for ranges).

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?

Discloses key behaviors beyond annotations: returns exactly 18 national holidays, uses Ley de Puentes moving most holidays to Monday, dynamically calculates Easter-dependent holidays. No contradiction with annotations (readOnlyHint, idempotentHint true).

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?

Description is front-loaded with the core action in first sentence, then details fields, legal context, and use cases. Every sentence adds value; no filler.

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 low complexity (1 parameter), full schema coverage, and presence of output schema, the description is complete. It covers purpose, behavior, and use cases adequately.

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

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

Schema description coverage is 100% and the schema already describes the year parameter with example. The tool description does not add additional parameter semantics beyond what the schema provides.

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

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

Description uses specific verb 'Returns' with resource 'all Colombian national public holidays' and clarifies scope ('for a given year', 'structured list'). Differentiates from sibling country-specific holiday tools like get_argentina_holidays.

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

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

Explicitly states use cases: calculating Colombian business deadlines, factura electrónica payment dates, scheduling. Mentions the legal basis (Ley de Puentes) and dynamic calculation of Easter holidays. However, does not explicitly contrast with alternatives among siblings (e.g., get_public_holidays_range_latam) but context makes it clear.

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?

Annotations already provide readOnlyHint=true and idempotentHint=true, so the description does not need to re-state safety. The description adds value by listing the return fields and supported country codes, which are not in annotations. No contradictions.

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

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

The description is three sentences, front-loaded with purpose. Could be slightly more concise by omitting the return shape if an output schema exists, but it remains clear and efficient.

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 is a simple lookup with one parameter, high schema coverage, and annotations present, the description adequately covers supported countries and use cases. It does not explain error handling for unsupported countries, but overall it is complete enough.

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

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

Schema coverage is 100%, and the schema already documents the country_code parameter with an example. The description only implicitly mentions it by referencing 'a given Latin American country' and listing supported codes, but adds little beyond the schema.

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 it returns e-invoicing obligations for a Latin American country, listing specific fields and supported countries (BR, MX, CL, AR, CO). This distinguishes it from sibling tools like get_vat_rules_latam or get_invoice_requirements_latam, which cover different aspects.

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

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

Explicitly advises when to use: 'Use when building invoice generation systems, determining compliance requirements for LatAm customers, or automating invoice submission workflows.' It does not mention when not to use or alternatives, but the context is clear and practical.

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?

Annotations already indicate readOnlyHint and idempotence. Description adds value by specifying the output structure, listing covered countries, and including a disclaimer ('reference only — not legal advice'). No contradictions.

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?

Concise, front-loaded, every sentence serves a purpose: core function, output shape, use cases, disclaimer. No fluff.

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

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

With an output schema present, description still provides complete context: lists output fields, covered countries, and use cases. Adequate for a reference lookup tool.

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 covers 100% of parameter (country_code) with examples. Description reiterates the two-letter ISO code and lists supported countries, but does not add significant extra meaning beyond what the schema already provides.

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

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

Description clearly states it returns mandatory fields for electronic invoices in LatAm countries, listing covered systems and countries. However, it does not explicitly differentiate from sibling tools like get_einvoicing_rules_latam or validate_invoice_schema_latam, which have overlapping 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?

Provides explicit usage scenarios: generating invoices, validating templates, building compliance checks. But lacks when-not-to-use guidance or mention of alternative tools for validation or rules.

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?

Annotations already declare readOnly and idempotent, so description focuses on behavioral details: explains the set of 9 mandatory holidays and moveable holiday rules (Monday observance). Adds value beyond 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?

Four sentences, front-loaded with primary action, no redundancy. Each sentence serves a purpose: output structure, moveable holiday rule, holiday count, use cases.

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

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

For a simple tool with one parameter and an output schema, description covers output format, holiday selection logic, and intended use cases. Complete and sufficient.

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

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

Schema coverage is 100% for the single parameter 'year'. Description adds example and type clarification ('4-digit integer'), but adds minimal extra meaning beyond schema.

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?

Clear verb+resource: 'Returns all Mexican national public holidays for a given year as a structured list.' Explicitly lists output fields and notes moveable holidays, distinguishing from sibling holiday 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?

States specific use cases: 'When calculating Mexican business deadlines, CFDI payment dates, or scheduling tasks...' Could be improved by noting when not to use (e.g., regional holidays not included), but context is clear.

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?

Annotations already declare readOnlyHint and idempotentHint, so safety is clear. Description adds value by detailing holiday handling (fixed and Easter-based) and that it skips weekends. It also specifies the return object structure. This goes beyond annotations without contradiction.

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?

Description is concise with 3-4 sentences. Main action is front-loaded. Every sentence adds value: explains function, lists rules, gives examples, and states use cases. No 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 (multiple rules, holiday logic) and the presence of annotations and output schema, the description is thorough. It covers purpose, rules, usage, and return format. Minor room for improvement: could mention country validation or limitations, but overall very complete.

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

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

Schema coverage is 100%, providing baseline 3. Description enhances understanding by giving examples for each rule (e.g., '5th working day for BR salary') and explaining the 'n' parameter. This adds practical context beyond the schema's enum and type descriptions.

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?

Description clearly states it calculates the next valid payment date for Latin American countries, skipping weekends and holidays. It lists supported rules with examples (e.g., 'last_working_day_of_month' for BR/AR salary). This differentiates it from siblings like calculate_working_days_latam which may compute working days without payment-specific rules.

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

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

Explicitly states use cases: scheduling salary payments, NF-e/CFDI due dates, or any automated payment workflow. While it doesn't mention when not to use or alternatives, the context is clear. A score of 4 reflects good guidance but lacks exclusion criteria.

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?

Annotations mark tool as read-only and idempotent; description reinforces this and adds that info is reference only, not legal advice. No contradictions.

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?

Concise, informative two-sentence description with return fields and supported countries, no redundant 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?

Description lists return fields and an output schema exists, providing full understanding of what the tool returns.

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

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

Schema coverage is 100% and already describes the parameter. The description adds example but does not significantly supplement the schema.

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

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

The description clearly states the tool returns B2B payment terms for a given Latin American country, listing output fields and supported countries. It distinguishes from sibling tools like calculate_vat_amount_latam by focusing on payment terms.

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?

Explicit guidance on when to use: generating invoices, setting due dates, automating AR workflows. No explicit when-not, but siblings handle different tasks.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds return structure details and implicit safety (no mutations). No contradictions. Provides context beyond annotations without overpromising.

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

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

Two sentences: first defines behavior and return structure, second lists use cases and supported countries. Every sentence adds value. No 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 simple 3-parameter schema and presence of output structure in description, the tool is fully specified. Includes supported countries, date format, return shape, and usage scenarios. No missing critical context for a read-only holiday lookup.

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

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

Schema coverage is 100%, so baseline is 3. Description provides example values and format for each parameter, but this closely mirrors schema descriptions. Does not add significant new semantic meaning beyond the schema.

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?

Explicitly states it returns public holidays in a date range for a specified Latin American country, listing supported countries (BR, MX, CL, AR, CO). Clearly differentiates from sibling per-country holiday tools by offering a consolidated range query.

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?

States explicit use cases: 'Use when calculating SLA periods, project timelines, delivery windows, or any workflow that must skip non-working days across LatAm countries.' Does not explicitly exclude alternatives like single-country or single-date queries, but purpose is clear.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by noting the return structure and the disclaimer that information is 'not legal or tax advice,' which exceeds what annotations convey.

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

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

The description is three well-structured sentences: purpose and scope, usage guidance, and disclaimer. Every sentence adds necessary information with no 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 tool's simplicity (one parameter, read-only, idempotent) and the presence of an output schema hinted in the description, this is adequately complete. It covers purpose, inputs, output structure, and a caveat.

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 baseline is 3. The description enhances this by listing the supported country codes explicitly and noting Brazil's special tax structure, providing practical context beyond the schema.

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 explicitly states 'Returns all VAT/IVA rules for a given Latin American country' and lists the specific countries supported (BR, MX, CL, AR, CO). This clearly differentiates it from sibling calculation tools like calculate_vat_amount_latam.

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 concrete usage scenarios: 'Use when calculating LatAm invoice taxes, determining correct rate for e-commerce checkout, or building tax compliance workflows.' It does not explicitly mention alternatives, but the sibling tools imply when to switch.

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

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

The description adds context beyond annotations: it lists return fields, covers various transaction types, and states it's a suggestion (not definitive). Annotations indicate readOnly and idempotent, which are consistent. No contradictions.

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 five sentences, front-loaded with purpose, then coverage, output, use cases, and caution. Every sentence earns its place with no fluff or repetition.

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 schema covers all parameters and output schema exists, the description is mostly complete. It covers scope, use cases, and caveats. It could explicitly differentiate from sibling tools, but overall it's sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description reiterates parameter names and provides some context (e.g., 'seller country, buyer country') but adds little beyond the schema descriptions. Examples of ISO codes are useful but not essential.

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 it suggests VAT/IVA treatment based on specific inputs, using a specific verb 'suggests'. It covers domestic, exports, imports, and cross-border services, but does not explicitly differentiate from sibling tools like 'get_vat_rules_latam' or 'calculate_vat_amount_latam'.

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

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

The description gives explicit use cases: 'When building checkout tax logic, invoice generation, or cross-border LatAm compliance workflows.' It also includes a caution to verify with a tax advisor. No when-not-to-use or alternative tools are mentioned.

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

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

The description discloses the algorithm (weighted modulo-10 checksum in two blocks), the specific return fields, and that it returns a reason on failure. Annotations already indicate read-only and idempotent behavior, so the description adds useful but non-critical behavioral detail.

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

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

The description is three sentences: purpose, algorithm, and use cases. It is well-structured and front-loaded with the primary function. While slightly verbose, each sentence adds value 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 simple validation function with one parameter and an output schema implied by the return values, the description is fairly complete. It covers purpose, algorithm, use cases, and return format. Minor omission of specific error types, but not critical.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context about the validation algorithm and return structure, but does not significantly enhance understanding of the single 'cbu' parameter beyond what the schema example provides.

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

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

The description clearly states the tool validates an Argentine CBU, specifying the 22-digit identifier, the official checksum algorithm, and the return format. It distinguishes itself from siblings by focusing on Argentina-specific banking validation.

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

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

The description explicitly lists use cases: processing Argentine wire transfers, validating supplier bank accounts, building payment flows. While it doesn't name alternatives, the context and sibling tools make it clear this is for Argentine CBU only, providing adequate guidance.

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

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

The description fully discloses the tool's behavior: it validates format (6-10 digits), returns a boolean with the cc string or a reason string on failure, and explicitly notes that checksum validation is not available. Annotations already indicate readOnlyHint=true and idempotentHint=true, and the description adds context about what the tool does not do, enhancing 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 concise with two focused sentences plus a brief note about checksum. Every sentence provides essential information without redundancy. The structure is front-loaded with the core purpose and constraints.

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 format validation tool with one parameter and clear annotations, the description covers all necessary context: what it validates, constraints, return format, limitations, and usage scenarios. The existence of an output schema does not reduce the need for description, but the description still provides sufficient completeness.

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

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

The input schema has 100% description coverage for the single parameter 'cc', including an example. The description adds the critical constraint that the number must be between 6 and 10 digits, which is not in the schema. This provides additional semantic meaning beyond the schema alone, earning a 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 clearly states the tool validates the format of a Colombian Cédula de Ciudadanía, specifying the number must be between 6 and 10 digits. The verb 'Validates' and resource 'Colombian Cédula de Ciudadanía' are specific and distinct from sibling tools (e.g., validate_cpf, validate_rut_cl) which handle different country documents.

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

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

The description explicitly states when to use the tool: 'when processing Colombian individual tax filings, employment contracts, or KYC onboarding flows requiring a verified Colombian citizen ID.' It also notes a limitation (no checksum validation) but does not mention alternatives or when not to use it, which is acceptable given the tool's focused scope.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, reusable operation. Description adds that it applies a specific algorithm (weighted modulo-10 with pattern 3,7,1), providing deeper insight into the validation process.

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?

Concise description spanning three sentences, each adding value: definition, algorithm, return shape, and use cases. No unnecessary words.

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

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

Given the tool has an output schema (likely documenting the return structure), use cases, algorithm, and annotations all present, the description covers everything an agent needs to select and invoke the tool correctly.

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

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

Input schema covers the parameter 'clabe' with a description and example. The description does not add new semantic information beyond the schema, so it achieves 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?

Description clearly states the tool validates a Mexican CLABE, specifies it is 18-digit, and mentions the official checksum algorithm. It distinguishes from sibling tools by being specific to Mexico and provides the exact use cases.

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

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

Explicitly lists when to use: 'processing Mexican wire transfers, validating supplier bank accounts, or building Mexican payment flows.' Lacks explicit when-not-to-use or alternatives, but context from sibling names makes the targeting clear.

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?

Description adds return format details and offline-only note beyond annotations (readOnly, idempotent). No contradiction.

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?

4 sentences, front-loaded with purpose, each sentence adds value. No fluff.

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

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

Output schema exists and description partially covers return values, sufficient for a simple single-parameter validation tool.

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

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

Schema coverage is 100% but description adds context: explains input format (with/without formatting) and purpose of parameter.

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

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

The description clearly states it validates a Brazilian CNPJ using the official checksum algorithm, distinguishing it from sibling validation tools like validate_cpf, validate_rut_cl, etc.

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?

Specifies use cases (Brazilian B2B invoices, supplier onboarding, compliance workflows) and notes offline-only validation, but does not explicitly exclude or mention 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint false. Description adds that it applies official two-pass modulo-11 algorithm, rejects known invalid sequences (all same digits), and returns structured error reasons. No contradictions.

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

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

Two sentences with clear front-loading of purpose, followed by algorithm, return format, and usage. No wasted words.

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

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

With output schema present, description adequately covers return types and failure reasons. Annotations provide safety profile. Complete for a validation tool.

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 has 100% coverage with parameter description including format examples. Description adds marginal value beyond schema (e.g., '11-digit'), but not enough to raise above baseline 3.

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

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

Description clearly states 'Validates a Brazilian CPF' and defines it as the 11-digit individual taxpayer ID. Differentiates from sibling tools like validate_cnpj (company) and validate_cuil (Argentina) by specifying CPF and Brazilian 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?

Explicit use cases provided: 'Brazilian e-commerce orders, fintech onboarding, KYC flows, or any compliance workflow requiring a verified Brazilian individual tax ID.' Also notes offline-only limitation. Does not explicitly name alternatives but context with sibling tools makes distinction clear.

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?

Annotations already provide readOnlyHint=true and idempotentHint=true, indicating safe read-only nature. The description adds value by disclosing the validation algorithm (weighted modulo-11 checksum) and the return structure (valid boolean, cuil string, or reason string). No contradictions with 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 three sentences: first defines purpose and target audience, second describes validation method, third lists output shape and usage context. Every sentence adds value; no redundant or empty phrasing. Well structured for quick agent parsing.

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 (1 parameter, simple return, no nested objects), the description is fully self-contained. It explains input acceptance, algorithm, output structure, and typical usage scenarios. The presence of output schema and annotations adds to completeness.

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

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

Input schema has 1 parameter 'cuil' with example formatting. The description adds meaning by clarifying it accepts both formatted and unformatted strings, and explaining the underlying checksum logic. With 100% schema description coverage, the description goes beyond the schema by providing 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 clearly states the tool validates an Argentine CUIL, explains what CUIL is (labor identification number for individuals, ANSES), mentions the checksum algorithm (modulo-11 same as CUIT), and describes the output format. It distinguishes itself from sibling tools like validate_cuit by specifying 'for individuals' and the social security 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 explicitly states when to use the tool: 'Use when processing Argentine payroll, employment contracts, or any social security compliance workflow.' This provides clear context. It does not include explicit when-not-to-use or alternatives, but the sibling list includes validate_cuit for employer numbers, so a small omission.

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?

Annotations already provide readOnlyHint and idempotentHint. Description adds details about the modulo-11 algorithm and the specific output structure (valid, cuit, type, or reason). No contradictions.

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

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

Two sentences, no fluff. Information is logically ordered: purpose first, then algorithm, then output, then use cases.

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 simple input (one parameter with 100% schema coverage) and output schema described in text, the description fully covers what an agent needs to know. Annotations and output schema (implied) are adequate.

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

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

Schema coverage is 100% with a clear description. Description adds value by explaining the meaning of CUIT prefixes (20/23/24/27 for individuals, etc.), which is beyond the schema's example formats.

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?

Description clearly states it validates Argentine CUIT, a specific tax ID, and explains the algorithm and return format. It distinguishes from siblings by specifying Argentine context and the exact identifier.

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

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

Explicitly states when to use: processing Argentine invoices, supplier registration, or AFIP compliance workflows. However, it does not explicitly mention when not to use or direct alternatives among the many sibling validation 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?

Annotations already indicate readOnlyHint and idempotentHint. The description adds behavioral context: it returns a structured result (valid, country, missing/present fields, warnings) and clarifies it is based on official tax authority requirements. No contradiction with 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?

Two sentences, front-loaded with core function, followed by usage guidance. Every sentence adds value 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 output schema exists (not shown but indicated), the description adequately covers purpose, usage, and return structure. No need for further elaboration for a validation tool.

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

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

Schema coverage is 100% with descriptions for both parameters (country_code as two-letter ISO, invoice as object). The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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 specifies a concrete verb-resource pair: validates invoice JSON for mandatory fields in LatAm countries. It distinguishes from sibling tools by focusing on invoice schema validation rather than entity validation (e.g., validate_cuit, validate_rut_cl).

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

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

Explicitly states use cases: 'building invoice generation pipelines, pre-submission validation, or compliance checks in agent workflows.' It also includes a disclaimer about reference-only nature. No explicit when-not-to-use, but context is clear.

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

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

The description adds valuable details beyond the annotations, such as the algorithm used (DIAN verification digit) and the return shape. The annotations already indicate readOnly and idempotent, so the description complements them well.

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

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

The description is two concise sentences with front-loaded key information (validation purpose and algorithm), followed by usage context. No unnecessary words.

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

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

Given the tool's simplicity (single parameter, annotations, output schema present), the description adequately covers what the tool does, how it works, and when to use it. It is complete for the 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 baseline is 3. The description includes an example similar to the schema and mentions the nit can include or exclude the verification digit, but does not add significant meaning beyond the schema.

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

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

The description clearly states the tool validates a Colombian NIT using a specific algorithm (weighted modulo-11 checksum). It distinguishes itself from sibling validation tools targeting other countries.

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

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

The description explicitly mentions when to use the tool: processing Colombian electronic invoices, supplier registration, or DIAN compliance workflows. It provides clear context but does not explicitly mention when not to use it or list 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?

Annotations include readOnlyHint and idempotentHint. The description adds detail about supported key formats and return structure, which goes beyond the 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 two sentences long, front-loaded with the main purpose, and every part adds value—no wasted words.

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

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

The description covers input, output format, and use cases. It does not explicitly reference the output schema but provides enough detail for an agent to understand the return value.

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

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

Schema coverage is 100% and the description adds value by explaining the PIX key types and providing examples, enhancing the schema's 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 tool validates a Brazilian PIX key and lists the four supported types (CPF, CNPJ, email, phone, EVP), distinguishing it from sibling validation tools like validate_cpf or validate_cnpj.

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 explicit usage scenarios: 'when processing PIX transfers, validating payment recipients, or building Brazilian payment flows.' It does not include when-not or alternatives, but the sibling tools cover other validations implicitly.

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?

Description discloses return format and supported country-specific patterns, adding value beyond annotations (readOnlyHint, idempotentHint). No contradictions; 'Validates' aligns with read-only behavior. The return structure is described in detail.

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

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

Three sentences: purpose, supported countries/formats, use cases. No redundant information. Front-loaded with core action and return type. Every sentence earns its place.

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

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

Given the tool's moderate complexity (multiple country patterns), the description covers purpose, input details, output structure, supported countries, and use cases. Output schema exists (not shown), so return details are fully covered. Complete for an AI agent to select and invoke 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?

Schema coverage is 100% with descriptions and examples for both parameters. Description adds context by listing supported country codes and corresponding format patterns, e.g., 'BR (8-digit CEP), MX (5-digit CP)'. This goes beyond schema to clarify usage.

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?

Description explicitly states the tool validates postal code format for Latin American countries, listing supported countries and their formats. The verb 'validates' and resource 'postal code format' are specific. Sibling tools are different validation types (CPF, CNPJ, RUT, etc.), so no confusion.

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

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

Provides explicit use cases: 'e-commerce checkout validation, address verification, or logistics workflows across LatAm markets.' Does not explicitly state when not to use, but the focus on LatAm implies geographic restriction. No direct alternatives mentioned, but siblings are all different, so guidance is clear enough.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds specific return format and validation logic, which goes beyond the annotations without contradicting them.

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?

Three sentences, structured with purpose first, then details, then usage context. Efficient and well-organized, with no wasted words.

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

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

Given the simple nature of the tool and the presence of an output schema, the description covers all relevant aspects: purpose, parameters, return values, and usage scenario. No 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 has 100% coverage with a description for the rfc parameter. The tool description adds meaning by detailing the expected formats (13 vs 12 characters, alphanumeric homoclave), which enhances understanding beyond the schema.

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

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

The description clearly states the tool validates a Mexican RFC, specifies format for individuals and companies, and includes return structure. It distinguishes from sibling tools by focusing on RFC validation.

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

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

Explicitly says when to use: processing CFDI invoices, supplier registration, tax compliance. Provides clear context, though it doesn't state when not to use, which is acceptable given the narrow scope.

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

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

The description discloses the modulo-11 algorithm, check digit 'K' support, and the exact return format (valid, rut, check_digit or valid: false, reason). Annotations already indicate readOnly and idempotent, so description adds further detail without contradiction.

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

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

Two sentences, each serving a distinct purpose: first explains what and how, second explains when and formatting. No redundant or vague statements.

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 single-parameter validation tool with an output schema, the description covers purpose, algorithm, use cases, and formatting. It could mention potential error cases but is largely complete.

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

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

Schema has 100% coverage with one parameter described. The description adds value by explaining acceptable formats (with/without dots and dash) and providing examples, beyond the schema's basic 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 explicitly states the tool validates a Chilean RUT, specifies the algorithm and return format. It clearly distinguishes from sibling validation tools (e.g., validate_cpf, validate_cuit) by naming the country and identifier.

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

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

The description provides clear use cases: 'processing Chilean DTE electronic invoices, supplier registration, or any Chilean tax compliance workflow.' It does not explicitly mention when not to use, but the context is sufficient.

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