Velora LATAM Tools

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

Annotations already provide readOnly, idempotent, non-destructive hints. Description adds value by explaining it only constructs the URL (no AFIP contact), and that invalid CAE produces a valid URL that fails scan-time verification. 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?

Multi-sentence description is front-loaded with main purpose, then provides details. No unnecessary information, but could be slightly more concise.

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 12 required parameters and no output schema, description adequately covers the tool's behavior and workflow. It explains the output is a full URL and notes the dependency on emit_invoice. Sufficient for agent understanding.

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% description coverage, so baseline is 3. Description adds that all fields are mandatory per AFIP spec but does not significantly elaborate beyond schema 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 builds the AFIP-compliant QR URL for an electronic invoice per RG 4291/2018, explaining what it encodes and returns. It distinguishes from siblings (none related to QR building) and specifies it does not contact AFIP.

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 'Use after emit_invoice to get the CAE and invoice number needed here' and warns about invalid CAE leading to verification failure. Does not explicitly state when not to use, but sibling tools are unrelated, so 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=true and idempotentHint=true. The description adds behavioral details about the mapping logic and constraints (e.g., RI→RI requires CUIT, CF cannot emit), which are beyond the annotations. It doesn't contradict any annotation.

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 compact: one sentence plus abbreviations and a compact rule string. Every word adds value. The main function is front-loaded, and the rules are efficiently encoded.

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?

Despite no output schema, the description sufficiently specifies the return value (A/B/C) and covers all input combinations. Sibling tools are unrelated, so no confusion. The tool is a deterministic lookup, and the description fully defines it.

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

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

Schema coverage is 100% with enum descriptions. The description adds significant value by explaining the abbreviations (RI=Responsable Inscripto, etc.) and providing a concise rule table for each combination, which is not present in 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 A/B/C invoice type based on emisor and receptor condicion_iva. The verb 'Returns' and specific resource 'invoice type' make the purpose unambiguous and distinct from siblings which are unrelated AFIP/formatting tools.

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

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

The description provides explicit mapping rules and conditions (e.g., 'CF cannot emit'), which helps the agent decide when to call it. However, it doesn't explicitly state when not to use it or compare to alternatives, though the context is clear given the tool's specificity.

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 safe, idempotent, non-destructive behavior. The description adds value by detailing the output format (2 decimals, Argentine locale) with an example, confirming no destructive side effects.

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

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

The description is concise: two sentences covering purpose, example, and use case. No unnecessary words, 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?

For a simple single-parameter tool with annotations, the description is complete. It covers purpose, format, and usage context. Could mention locale specifics but the example suffices.

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 parameter description. The description adds an example and usage context but does not enhance 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?

The description clearly states the specific action: formatting a numeric amount as an Argentine peso string with 2 decimal places. The example further clarifies the output format, and the tool's purpose is distinct from siblings like parse_ar_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?

The description explicitly recommends using the tool 'whenever showing money to an Argentine user.' While it doesn't list exclusions, the context is clear and appropriate, and sibling tool names provide implicit 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint false), the description adds behavioral details: handling Argentine conventions (thousands/comma separators), k/K suffixes, return values (parsed number, display string, or error for null, no number, or zero). It supplements but does not contradict 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 appropriately concise, with the most critical guidance front-loaded. Every sentence serves a purpose: usage context, parsing details, error conditions. No redundant or unnecessary text.

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, no output schema), the description provides complete context: what the tool does, how it handles locale-specific formats, what it returns, and when errors occur. No gaps are evident.

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 'text', but the description adds meaningful context: what the input may include ('$', spaces, surrounding text) and that it extracts the first numeric token. This enriches the schema 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's purpose: parsing Argentine peso amount strings into plain numbers, with specific examples. It effectively distinguishes itself from sibling tools (build_afip_qr, split_iva, validate_cuit), which handle entirely different domains.

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 directs when to use the tool: 'Use this before doing arithmetic on any amount typed by an Argentine user' and 'Always call this before operating on amounts received as text from chat or forms.' This provides clear, actionable 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?

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds important behavioral context: it uses integer-cent arithmetic to guarantee neto + iva equals the total exactly, avoiding AFIP error 10016. This provides transparency beyond the 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 front-loaded with the primary purpose, followed by a clear list of alícuotas, then technical details and a special case. While it is comprehensive, it could be slightly more concise without losing information. Overall 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 complexity of Argentine tax rules and the complete schema coverage, the description is fairly complete. It covers the alícuotas, the arithmetic guarantee, and a special case. However, it does not specify the exact output format (e.g., object with neto and iva fields), leaving a minor gap for agents expecting precise return structure.

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 the description adds meaning by listing each alícuota with its percentage and usage notes (e.g., 'use this for most products'). It also clarifies the isTotal parameter behavior and the Monotributo use case, adding significant 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 uses a specific verb ('decomposes') and identifies the resource ('an Argentine amount into neto (base imponible) and IVA'). It clearly states the tool's purpose for building AFIP invoices and distinguishes itself from siblings by focusing on IVA splitting.

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 tells when to use the tool ('before building an AFIP invoice') and provides special guidance for Monotributistas. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tools are different enough to imply usage boundaries.

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?

Adds value beyond annotations by disclosing the use of ART (UTC-3) timezone and that it matches Buenos Aires local date. Annotations already indicate readOnlyHint=true and idempotentHint=true, but the description provides the behavioral details of the conversion logic. 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?

Very concise: two sentences that front-load the main purpose and then add essential details (timezone, input, output). Every word adds value; no redundancy or excess.

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

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

For a simple tool with one parameter and no output schema, the description fully covers the required information: input format, accepted values, timezone, output format, and target system. Combined with rich annotations, it provides complete contextual guidance.

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 basic description of the 'date' parameter. The description adds meaningful context: the required format (ISO-8601), the special value 'today', and the output format YYYYMMDD. This goes beyond the schema's description of the parameter type.

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

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

Clearly states the tool converts a date to YYYYMMDD format for WSFE (AFIP/ARCA), specifying the target system and format. The name aligns with the action, and the description distinguishes it from sibling tools which handle different operations (QR, format, 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 describes when to use the tool: for converting dates to AFIP format. Provides input examples ('2026-06-12' or 'today') and output format. Does not explicitly state when not to use, but the context is clear enough for a simple conversion tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds specific validation method (mod-10 per BCRA) and clarifies no account existence check, adding valuable behavioral context 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?

Two sentences, zero wasted words. The description is front-loaded with the core purpose and immediately follows with a critical limitation. 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?

For a single-parameter tool with strong annotations, the description adequately explains behavior and limitations. It omits the return value, but given the tool's simplicity (validation), the output is likely a boolean or error, so this is a minor gap. Still, more detail could be provided.

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 describes the 'cbu' parameter as 'CBU/CVU as 22 digits (spaces or hyphens accepted).' The description reinforces accepted formatting but does not add additional semantic value beyond the schema. With 100% schema coverage, a baseline score of 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 validates an Argentine CBU/CVU (22-digit bank account code) using mod-10 check digits per BCRA standard, and explicitly notes it does not confirm account existence. This distinguishes it from siblings like validate_cuil and validate_cuit.

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 guidance: it is for typo detection only, not for verifying account existence. No alternative tools are named, but the limitation is clearly stated, helping the agent decide when to use it.

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 indicate read-only and idempotent behavior. The description adds transparency by noting it returns parsed components and person type, and advises to check the 'valid' field. It also mentions warning for company prefixes, which is useful context 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 concise sentences with no redundancy. The most important information is front-loaded: validation purpose and key differentiator.

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 validation tool with one parameter, the description adequately covers purpose, behavior, and output hints. No output schema is needed, but the return of parsed components is mentioned. Contextual completeness is good.

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 the single parameter with 100% coverage, so baseline is 3. The description adds minimal extra meaning (format flexibility, algorithm reference), but does not significantly enhance 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 it validates an Argentine CUIL for natural persons, uses mod-11 algorithm like validate_cuit, and flags company prefixes. It distinguishes from the sibling validate_cuit by specifying the distinction between individuals and companies.

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 hints at when to use this tool versus validate_cuit by noting the same algorithm but different document types. However, it does not explicitly state when not to use it or provide alternative usage contexts.

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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context: 'Always returns a result — check the `valid` field' and mentions return components (prefix, body, check digit, person type), which goes beyond what annotations provide.

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 usage guideline, no unnecessary words. Efficient and clear.

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

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

Given the tool's simplicity (single parameter, validation only), the description covers purpose, usage, input format, and return behavior. No output schema, but the description adequately explains return fields.

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 description for the 'cuit' parameter. The description adds detail on accepted formats (digits, hyphens, or spaces) and specifies that it returns parsed components, enriching the parameter semantics 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 Argentine CUIT/CUIL numbers, specifies the context (before using in invoice/fiscal operation), and differentiates from sibling tools (build_afip_qr, parse_ar_amount, split_iva) which have different purposes.

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 ('Use this before using a CUIT in an invoice or fiscal operation'). While it doesn't mention when not to use or alternatives, the sibling tools are unrelated, so no further guidance is necessary.

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