Enables validation of Brazilian Pix keys for banking compliance.
Latin American business compliance suite for AI agents — 28 tools covering tax ID validation, banking validation, e-invoicing rules, VAT calculations, and labor calendar helpers for Brazil, Mexico, Chile, Argentina, and Colombia.
Part of MCPize — regional MCP servers for AI agents.
Country | Tax IDs | Banking | Holidays | E-Invoicing |
🇧🇷 Brazil | CPF, CNPJ | PIX | ✓ | NF-e / NF-C / NFS-e |
🇲🇽 Mexico | RFC | CLABE | ✓ | CFDI 4.0 |
🇨🇱 Chile | RUT | — | ✓ | DTE |
🇦🇷 Argentina | CUIT, CUIL | CBU | ✓ | Factura Electrónica |
🇨🇴 Colombia | NIT, CC | — | ✓ | Factura Electrónica |
Related MCP server: mcp-fiscal-brasil
Validation (17): validate_cpf, validate_cnpj, validate_pix_key, validate_rfc_mx, validate_rut_cl, validate_cuit, validate_cuil, validate_nit_co, validate_cc_co, validate_clabe_mx, validate_cbu_ar, validate_postal_code_latam, get_brazil_holidays, get_mexico_holidays, get_chile_holidays, get_argentina_holidays, get_colombia_holidays
Business Rules (4): get_payment_terms_latam, get_invoice_requirements_latam, get_vat_rules_latam, get_einvoicing_rules_latam
Labor Helpers (3): get_public_holidays_range_latam, calculate_working_days_latam, get_next_payment_date_latam
Invoice & VAT (4): validate_invoice_schema_latam, calculate_vat_breakdown_latam, suggest_vat_treatment_latam, calculate_vat_amount_latam
npm install
npm start # stdio transport (for Glama / Claude Desktop)
npm run start:http # HTTP transport on port 8080 (for Railway / hosted use)GET / — server metadata and tool list
GET /health — health check (returns {"status":"ok"})
POST /mcp — MCP Streamable HTTP endpoint
Push this repo to GitHub
Create new Railway project → Deploy from GitHub repo
Railway auto-detects the Dockerfile and railway.json
MCP_HTTP=true is set by the Dockerfile; no env vars needed
Public URL becomes the MCP HTTP endpoint at /mcp
Add to your MCP client config:
{
"mcpServers": {
"latam-business": {
"command": "npx",
"args": ["-y", "mcp-latam-business"]
}
}
}All compliance, tax, and legal information returned by these tools is reference only — not legal or tax advice. Tax rates, e-invoicing rules, and holiday calendars change frequently. Always verify with the relevant tax authority and a qualified professional before use in production.
MIT
Calculates tax amounts from either a net (excluding tax) or gross (including tax) amount for a given tax rate, with country context for currency and tax label. Returns { country, net_amount, tax_amount, gross_amount, tax_rate, tax_label, currency }. Use when building pricing tools, invoice calculators, or checkout flows across LatAm markets that need to split gross prices into net + tax components.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code for currency and context. Example: 'BR', 'MX', 'CL' | |
| amount | Yes | The amount to calculate tax for | |
| tax_rate | Yes | Tax rate as a percentage. Example: 16 for 16% IVA (Mexico) or 19 for 19% IVA (Chile) | |
| amount_type | Yes | Whether the input amount is net (excluding tax) or gross (including tax) | |
| currency | No | Override currency. Defaults to country currency. |
| Name | Required | Description |
|---|---|---|
| country | Yes | |
| net_amount | Yes | |
| tax_amount | Yes | |
| gross_amount | Yes | |
| tax_rate | Yes | |
| tax_label | Yes | |
| currency | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return object shape; idempotent and read-only nature already in annotations. Adds value with country context for currency/tax label.
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 redundancy, front-loaded with action and output, followed by appropriate 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?
Provides return format, use context, and input semantics; no edge cases or error handling mentioned, but sufficient for a calculation tool with clear schema.
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 all parameters with descriptions; description adds general context but no new detail beyond schema (e.g., example values or validation rules).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'calculates' on tax amounts, specifies net/gross input and output structure. Distinguishes from sibling tools like calculate_vat_breakdown_latam by focusing on net-to-gross split with country 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?
Explicitly states use cases (pricing tools, invoice calculators, checkout flows) but does not mention when not to use or list alternatives like calculate_vat_breakdown_latam.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates a VAT/IVA breakdown for invoice line items in a given Latin American country, grouping amounts by tax rate and computing totals. For Brazil, returns ICMS, PIS, COFINS breakdown. For Mexico, returns IVA breakdown. For Chile/Argentina/Colombia, returns IVA breakdown. Returns { country, lines_summary, tax_breakdown, subtotal, total_tax, total }. Each line item requires { description, quantity, unit_price, tax_rate }.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CL' | |
| lines | Yes | Array of invoice line items | |
| currency | No | Currency code. Example: 'BRL', 'MXN', 'CLP'. Defaults to country currency. |
| Name | Required | Description |
|---|---|---|
| country | Yes | |
| currency | Yes | |
| lines_summary | Yes | |
| tax_breakdown | Yes | |
| subtotal | Yes | |
| total_tax | Yes | |
| total | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm read-only and idempotent behavior. The description adds value by detailing the return fields and country-specific tax components, exceeding annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact paragraph that front-loads the purpose and includes key details. It is slightly dense but not overly long, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully defines the output structure and country-specific breakdowns, compensating for the absence of an output schema in the provided context. It is complete for the tool's complexity.
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 required line item fields and provides tax rate examples, but adds minimal new meaning beyond the 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?
The description clearly states the tool calculates a VAT/IVA breakdown for Latin American countries, listing specific breakdowns per country and contrasting with sibling tools by detailing the output structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a full tax breakdown rather than a simple amount, and the output specification guides the agent. However, it lacks explicit when-to-use or when-not-to-use compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts the number of working days between two dates (inclusive) for a given Latin American country, excluding weekends and that country's national public holidays (including moveable Easter-based holidays). Returns { country, start_date, end_date, working_days, holidays_excluded }. Supports BR, MX, CL, AR, CO. Use when calculating cross-border SLA periods, invoice payment deadlines, or project timelines that must account for different national holiday calendars across LatAm.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CO' | |
| start_date | Yes | Start date in YYYY-MM-DD format, inclusive. Example: '2026-01-01' | |
| end_date | Yes | End date in YYYY-MM-DD format, inclusive. Example: '2026-01-31' |
| Name | Required | Description |
|---|---|---|
| country | No | |
| start_date | No | |
| end_date | No | |
| working_days | No | |
| holidays_excluded | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral context: inclusive dates, exclusion of weekends and national holidays including moveable Easter-based ones, and the returned fields (country, dates, working_days, holidays_excluded). It also lists supported countries. 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?
Three sentences, front-loaded with core functionality, followed by return fields and use cases. No redundant words or filler. Extremely 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 has an output schema (context signal), the description covers essential behavioral details: inclusive dates, supported countries, exclusion logic, and return fields. Minor omissions like max date range or error handling are acceptable for a counting function.
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 each parameter having a description (country_code, start_date, end_date). The description does not add new meaning beyond the schema; it only mentions the return structure. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts working days between two dates inclusive for a Latin American country, excluding weekends and national holidays. It lists supported countries (BR, MX, CL, AR, CO) and differentiates from siblings like get_public_holidays_range_latam by focusing on counting rather than listing 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?
The description provides explicit use cases: cross-border SLA periods, invoice payment deadlines, and project timelines. It does not explicitly name alternative tools or state when not to use, but the context of siblings suggests appropriate usage. This is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all Argentine national public holidays for a given year as a structured list. Each holiday includes { date: 'YYYY-MM-DD', name: string, name_en: string }. Moveable holidays (Carnival, Good Friday) are dynamically calculated. Returns 15 national holidays defined by Argentine law. Use when calculating Argentine business deadlines, invoice payment dates, or scheduling tasks that must avoid non-working days in Argentina.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year as a 4-digit integer. Example: 2026 |
| Name | Required | Description |
|---|---|---|
| year | Yes | |
| country | Yes | |
| total_holidays | Yes | |
| holidays | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral details: moveable holidays like Carnival and Good Friday are dynamically calculated, and exactly 15 national holidays defined by law are returned. It also describes the output field format, which is not in 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 concise with 4 sentences. It front-loads the purpose, then details output structure, dynamic behavior, count, and use cases. Every sentence 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?
Given the tool's simplicity (single parameter, output schema provided), the description fully covers purpose, output format, behavioral details (dynamic holidays), and usage context. It is complete and leaves no ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'year' with a clear description and example. The description does not add additional semantics beyond the schema, but since coverage is high, a baseline 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 uses a specific verb 'Returns' and clearly identifies the resource 'Argentine national public holidays for a given year' as a structured list. It distinguishes from sibling country-specific holiday tools by specifying Argentina and mentioning national holidays by law.
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 calculating Argentine business deadlines, invoice payment dates, or scheduling tasks that must avoid non-working days in Argentina.' While it does not explicitly state when not to use it or mention alternatives, the sibling tools (e.g., get_brazil_holidays) imply that this tool is specific to Argentina, and the guidance is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all Brazilian national public holidays for a given year as a structured list. Each holiday includes { date: 'YYYY-MM-DD', name: string, name_en: string }. Moveable holidays (Carnival, Good Friday, Corpus Christi) are dynamically calculated using the Easter algorithm. Returns 12 national holidays defined by Brazilian federal law. Use when calculating business deadlines, invoice payment dates, SLA periods, or scheduling tasks that must avoid non-working days in Brazil.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year as a 4-digit integer. Example: 2026 |
| Name | Required | Description |
|---|---|---|
| year | Yes | |
| country | Yes | |
| total_holidays | Yes | |
| holidays | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by mentioning dynamic calculation of moveable holidays and fixed count of 12, providing extra safety 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 covering purpose, data format, and use cases without waste. Information is front-loaded with the main action in the first sentence.
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 parameter set, existing output schema, and thorough annotations, the description covers all necessary information: holiday details, dynamic calculation, and use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear description for 'year'. The description does not add additional semantics beyond the schema, so 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 explicitly states it returns Brazilian national public holidays for a given year, clearly specifying the resource and action. It distinguishes from siblings (e.g., get_argentina_holidays) by focusing 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?
Provides clear use cases (business deadlines, invoice payments) but does not explicitly exclude alternative tools when not appropriate. However, given sibling tools are for other countries, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all Chilean national public holidays for a given year as a structured list. Each holiday includes { date: 'YYYY-MM-DD', name: string, name_en: string }. Easter-dependent holidays (Good Friday, Holy Saturday) are dynamically calculated. Returns 16 mandatory national holidays defined by Chilean law. Use when calculating Chilean business deadlines, DTE invoice dates, or scheduling tasks that must avoid non-working days in Chile.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year as a 4-digit integer. Example: 2026 |
| Name | Required | Description |
|---|---|---|
| year | Yes | |
| country | Yes | |
| total_holidays | Yes | |
| holidays | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, indicating safe read operation. Description adds context about dynamic calculation of Easter-dependent holidays and return format, which goes 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 wasted words. Front-loaded with main action, includes output format and use cases. Highly 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?
For a read-only tool with one parameter fully described in schema, output schema exists, and annotations cover safety. Description covers return format, dynamic calculation, and use cases, making it 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 for the only parameter (year). Description does not add extra meaning beyond what the schema already provides, so baseline 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?
Description clearly states it returns Chilean national public holidays for a given year. It specifies the resource (Chilean holidays) and verb (returns), and distinguishes from sibling tools like get_argentina_holidays and get_brazil_holidays by country.
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?
Description explicitly states use cases: calculating business deadlines, DTE invoice dates, or scheduling tasks avoiding non-working days in Chile. It does not mention exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all Colombian national public holidays for a given year as a structured list. Each holiday includes { date: 'YYYY-MM-DD', name: string, name_en: string }. Colombia uses the 'Ley de Puentes' (Law 51/1983) which moves most holidays to the following Monday. Easter-dependent holidays are dynamically calculated. Returns 18 national holidays defined by Colombian law. Use when calculating Colombian business deadlines, factura electrónica payment dates, or scheduling tasks avoiding non-working days in Colombia.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year as a 4-digit integer. Example: 2026 |
| Name | Required | Description |
|---|---|---|
| year | Yes | |
| country | Yes | |
| total_holidays | Yes | |
| holidays | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is clear. The description adds valuable behavioral details: the 'Ley de Puentes' rule that most holidays move to Monday, dynamic calculation of Easter-dependent holidays, and that it returns exactly 18 holidays. 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 concise with 4 sentences, each adding value. It front-loads the purpose and then provides context on law, output structure, and use cases. 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 presence of an output schema, the description does not need to explain return values. It adequately covers usage, legal context, count, and output structure, making it fully informative for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'year' with full schema description. The description does not add additional meaning beyond the schema, but the schema is already clear and covers 100%. 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 returns all Colombian national public holidays for a given year as a structured list with specific fields (date, name, name_en). It distinguishes itself from sibling tools by specifying Colombia, and the sibling list includes other country holidays, making the purpose unique.
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 advises when to use this tool: for calculating Colombian business deadlines, factura electrónica payment dates, or scheduling tasks. It does not state when not to use or explicitly name alternatives, but the sibling tools for other countries imply those are alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current e-invoicing (electronic invoicing) obligations for a given Latin American country — whether mandatory for B2B/B2G/B2C, the electronic system used, required formats, and key compliance notes. Returns { country, b2b_mandatory, b2g_mandatory, b2c_mandatory, system, formats, mandatory_since, notes }. Supports BR, MX, CL, AR, CO. Use when building invoice generation systems, determining compliance requirements for LatAm customers, or automating invoice submission workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CL', 'AR', 'CO' |
| Name | Required | Description |
|---|---|---|
| country | No | |
| b2b_mandatory | No | |
| b2g_mandatory | No | |
| b2c_mandatory | No | |
| system | No | |
| formats | No | |
| mandatory_since | No | |
| notes | No | |
| disclaimer | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) already indicate safety. Description adds return fields and supported countries, providing useful behavioral context without 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 concise sentences: first defines output and supported countries, second lists use cases. No unnecessary words, front-loaded with key 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?
Covers purpose, output fields, supported countries, and use cases. With output schema present, return values are detailed. Could mention error behavior for unsupported countries, but overall complete for a 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?
The sole parameter 'country_code' has identical description in both the tool description and schema (100% coverage). The description adds no new meaning; 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 returns e-invoicing obligations for Latin American countries, lists specific fields, and distinguishes from sibling tools like get_vat_rules_latam or validate_invoice_schema_latam by focusing on electronic invoicing 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?
Explicit use cases are provided (building invoice generation systems, compliance determination, automation). While alternatives are not explicitly ruled out, the context makes it clear when this tool is appropriate, and it avoids mention of when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the mandatory fields required on a valid electronic invoice for a given Latin American country, based on official tax authority requirements. Returns { country, invoice_type, mandatory_fields: [], electronic_system, notes }. Covers NF-e/NF-C (Brazil), CFDI 4.0 (Mexico), DTE (Chile), Factura Electrónica (Argentina/Colombia). Use when generating invoices for LatAm customers, validating invoice templates, or building invoice compliance checks in agent workflows. Information provided as reference only — not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CL', 'AR', 'CO' |
| Name | Required | Description |
|---|---|---|
| country | No | |
| invoice_type | No | |
| mandatory_fields | No | |
| electronic_system | No | |
| notes | No | |
| disclaimer | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds useful context: the information is based on official tax authority requirements, is for reference only, and not legal advice. 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 concise with four sentences, front-loaded with the primary purpose. Every sentence adds value, with 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?
Given the output schema exists, the description adequately covers the tool's purpose, usage context, limitations, and behavioral notes. It is complete for the tool's complexity.
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 'country_code'. The description adds examples and the list of covered countries (BR, MX, CL, AR, CO), adding 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 the tool returns mandatory fields for electronic invoices in specific Latin American countries, with a specific verb 'Returns' and resource 'mandatory fields'. It differentiates from sibling tools by listing covered countries and 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?
The description provides explicit use cases: generating invoices, validating templates, and compliance checks. It also includes a disclaimer about not being legal advice. However, it does not explicitly state when not to use the tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all Mexican national public holidays for a given year as a structured list. Each holiday includes { date: 'YYYY-MM-DD', name: string, name_en: string }. Moveable holidays (Constitution Day, President's Day, Revolution Day) follow the Mexican Monday rule (primer lunes de febrero/tercer lunes de noviembre). Returns 9 mandatory national holidays defined by Mexican law. Use when calculating Mexican business deadlines, CFDI payment dates, or scheduling tasks that must avoid non-working days in Mexico.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Calendar year as a 4-digit integer. Example: 2026 |
| Name | Required | Description |
|---|---|---|
| year | Yes | |
| country | Yes | |
| total_holidays | Yes | |
| holidays | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true and idempotentHint=true, so the description adds value by detailing the moveable holiday rule, the exact number of holidays (9), and output structure. 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 a single paragraph that is informative but not overly long. It front-loads the purpose and includes useful details. Minor improvement could be better structure, but it's concise 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 presence of an output schema, the description adequately covers purpose, usage, and behavioral nuances (moveable holidays). It is complete for a simple read-only tool with one parameter.
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 year parameter description is already clear. The description does not add extra semantic 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 clearly states it returns Mexican national public holidays for a given year, including specifics like 9 mandatory holidays and moveable holiday rules. It distinguishes from sibling tools like get_argentina_holidays by being country-specific.
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 mentions use cases: Mexican business deadlines, CFDI payment dates, scheduling tasks. Does not explicitly list alternatives but the sibling set implies country-specific usage. Could mention not to use for other countries or multiple years.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates the next valid payment date for a given Latin American country, skipping weekends and national public holidays (fixed and moveable Easter-based). Supports rules: 'last_working_day_of_month' (salary payment in BR/AR), 'first_working_day_of_month', 'nth_working_day' (e.g. 5th working day for BR salary), 'next_working_day'. Returns { country, reference_date, rule, result_date }. Use when scheduling salary payments, NF-e/CFDI payment due dates, or any automated payment workflow that must avoid non-working days in LatAm.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CO' | |
| reference_date | Yes | Reference date in YYYY-MM-DD format. Example: '2026-01-31' | |
| rule | Yes | Payment rule to apply. | |
| n | No | For nth_working_day rule: which working day of the month. Example: 5 for 5th working day. |
| Name | Required | Description |
|---|---|---|
| country | No | |
| reference_date | No | |
| rule | No | |
| n | No | |
| result_date | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond the readOnlyHint and idempotentHint annotations: it skips weekends, holidays (fixed and Easter-based), and explains the supported rules. 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 concise (two sentences), front-loaded with the core function, and every sentence adds value. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete given the output schema: it explains purpose, rules, return output, and use cases. It covers all necessary contextual information for an agent to select and invoke the 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%, so baseline is 3. The description adds context for the rule parameter and provides examples but does not significantly enhance 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 calculates the next valid payment date for Latin American countries, avoiding holidays and weekends. It lists supported rules and return format, distinguishing it from sibling tools like holiday listers or working day calculators.
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 use cases like scheduling salary payments and avoiding non-working days in LatAm. It guides when to use but lacks explicit alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the typical and legal B2B payment terms for a given Latin American country — default payment period, common commercial practices, and late payment rules where defined by law. Returns { country, default_days, common_terms, late_payment_notes, currency, notes }. Supports BR, MX, CL, AR, CO. Use when generating invoices, setting payment due dates, or automating accounts receivable workflows in LatAm markets. Information provided as reference only — not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CL' |
| Name | Required | Description |
|---|---|---|
| country | No | |
| default_days | No | |
| common_terms | No | |
| late_payment_notes | No | |
| currency | No | |
| notes | No | |
| disclaimer | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the read-only nature is clear. The description adds behavioral constraints (only supports BR, MX, CL, AR, CO) and a disclaimer about not being legal advice, enhancing transparency 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?
The description is concise (4 sentences) and well-structured: first sentence states purpose, second lists return fields, third notes supported countries, fourth gives usage context, and fifth includes a disclaimer. 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 output schema exists, the description complements it by explaining the tool's purpose, supported inputs, and use cases. It provides a complete picture for an agent to understand when and how to use the 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 a clear description and examples for the single parameter. The description adds a list of supported countries, but this is largely redundant with the schema examples. Baseline 3 is appropriate as the description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and resource ('B2B payment terms for a given Latin American country'), clearly differentiating it from sibling tools like tax or holiday calculators. It explicitly lists supported countries and the return structure.
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 (generating invoices, setting payment due dates, automating AR workflows) but does not mention when not to use it or directly compare with siblings. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all public holidays that fall within a given date range for a specified Latin American country. Returns { country, start_date, end_date, total_holidays, holidays: [{date, name, name_en}] }. Supports BR, MX, CL, AR, CO. Use when calculating SLA periods, project timelines, delivery windows, or any workflow that must skip non-working days across LatAm countries.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CL' | |
| start_date | Yes | Start date in YYYY-MM-DD format. Example: '2026-01-01' | |
| end_date | Yes | End date in YYYY-MM-DD format. Example: '2026-12-31' |
| Name | Required | Description |
|---|---|---|
| country | No | |
| start_date | No | |
| end_date | No | |
| total_holidays | No | |
| holidays | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds return format details but does not disclose additional behavioral traits like rate limits or data freshness.
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 plus use-case list, front-loaded, no wasted words. Every sentence adds value.
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 annotations and output schema implied, the description covers key aspects. Lacks differentiation from country-specific holiday tools but it mentions supported countries.
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 description adds only marginal value (supported countries list). The output structure in description aids understanding but does not significantly enhance 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 public holidays for a Latin American country within a date range, with a specific verb and resource. It lists supported countries and distinguishes from sibling tools like get_brazil_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?
The description provides explicit use cases (SLA periods, project timelines) but does not mention when not to use or alternatives like country-specific holiday tools. Still, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all VAT/IVA rules for a given Latin American country — standard rate, reduced rates, exempt categories, withholding rules, and special regimes. Returns { country, standard_rate, reduced_rates, exempt_categories, withholding, special_regimes, currency, notes }. Supports BR, MX, CL, AR, CO. Brazil returns ICMS/ISS/PIS/COFINS structure. Use when calculating LatAm invoice taxes, determining correct rate for e-commerce checkout, or building tax compliance workflows. Information provided as reference only — not legal or tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CL', 'AR', 'CO' |
| Name | Required | Description |
|---|---|---|
| country | No | |
| standard_rate | No | |
| reduced_rates | No | |
| exempt_categories | No | |
| withholding | No | |
| special_regimes | No | |
| currency | No | |
| notes | No | |
| disclaimer | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds context: reference-only disclaimer, and special structure for Brazil (ICMS/ISS/PIS/COFINS). 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?
Concise paragraph front-loaded with main purpose. Every sentence adds value: purpose, output, supported countries, use cases, disclaimer. 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?
Description fully covers what the tool does, what it returns, when to use it, and caveats. Parameter count is low, annotations present, and output schema is referenced but not necessary to explain further.
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 one parameter with good description. The description adds meaning by listing return fields and special handling per country, which helps understand how the parameter affects output.
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 VAT/IVA rules for a given Latin American country, specifies the output structure, supported countries, and distinguishes from sibling calculate/suggest 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?
Explicit use cases are given (calculating LatAm invoice taxes, e-commerce checkout, tax compliance workflows). It also includes a disclaimer about not being legal/tax advice, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggests the likely VAT/IVA treatment for a transaction in Latin American markets based on seller country, buyer country, buyer tax registration status, and operation type. Covers domestic transactions, exports (zero-rated), imports, and cross-border services. Returns { treatment, description, seller_charges_tax, applicable_rate, notes, disclaimer }. Use when building checkout tax logic, invoice generation, or cross-border LatAm compliance workflows. Always verify with a tax advisor for real transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| seller_country | Yes | Seller's country ISO code. Example: 'BR', 'MX' | |
| buyer_country | Yes | Buyer's country ISO code. Example: 'CL', 'CO' | |
| buyer_is_tax_registered | Yes | Whether the buyer is tax registered (B2B) or not (B2C) | |
| operation_type | Yes | Type of supply |
| Name | Required | Description |
|---|---|---|
| treatment | Yes | |
| description | Yes | |
| seller_charges_tax | Yes | |
| applicable_rate | Yes | |
| seller_country | Yes | |
| buyer_country | Yes | |
| buyer_is_tax_registered | Yes | |
| operation_type | Yes | |
| notes | Yes | |
| disclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating no mutations. Description adds that the tool 'suggests' likely treatment and advises verification with a tax advisor, which aligns and provides extra caution. No behavioral 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?
Three sentences plus a disclaimer; each sentence adds value. Information is front-loaded: purpose, inputs, coverage, return structure, use cases, and caveat. 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 tool's complexity (4 parameters, output schema exists), the description covers input, output structure (referenced as 'Returns {...}'), use cases, and a necessary disclaimer. The output schema obviates the need to detail return fields. All essential information for correct invocation is present.
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 all four parameters. The description goes beyond by explaining that the tool 'Covers domestic transactions, exports (zero-rated), imports, and cross-border services,' adding context to the operation_type enum values (goods, services, digital_services). This adds 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?
Description clearly states the tool 'suggests the likely VAT/IVA treatment' and lists all input dimensions (seller_country, buyer_country, etc.). The verb 'suggests' is specific, and the resource 'VAT/IVA treatment' is distinct from sibling tools that calculate amounts or retrieve 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?
Description explicitly says 'Use when building checkout tax logic, invoice generation, or cross-border LatAm compliance workflows.' This provides clear context for usage. However, it does not exclude alternatives (e.g., calculate_vat_amount_latam for amounts), so it misses explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates an Argentine CBU (Clave Bancaria Uniforme) — the 22-digit standardized bank account identifier used for electronic transfers in Argentina, as defined by BCRA (Banco Central de la República Argentina). Applies the official weighted modulo-10 checksum algorithm validated in two blocks: the 8-digit bank/branch block and the 14-digit account block. Returns { valid: boolean, cbu: string, bank_code: string } or { valid: false, reason: string }. Use when processing Argentine wire transfers, validating supplier bank accounts, or building Argentine payment flows.
| Name | Required | Description | Default |
|---|---|---|---|
| cbu | Yes | 22-digit Argentine CBU bank account number. Example: '0720309988000019834160' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| cbu | No | |
| bank_code | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds the weighted modulo-10 checksum algorithm, two-block validation, and the return format including bank_code extraction. 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?
Description is compact, starting with the action, then explaining the identifier, algorithm, return format, and usage scenarios. Every sentence adds value 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 simple tool with one parameter and existing annotations/output schema, the description fully covers validation logic, return fields, and usage context. No gaps remain.
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 100% coverage with a description for the single parameter. The description reinforces that it must be a 22-digit string and provides an example, plus explains the algorithm applied to it.
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 validates an Argentine CBU, specifies the 22-digit format, checksum algorithm, and return fields. Distinguishes from sibling tools by targeting a specific Argentine 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 the tool: processing Argentine wire transfers, validating supplier bank accounts, or building Argentine payment flows. Does not explicitly mention when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates the format of a Colombian Cédula de Ciudadanía (CC) — the national identity document for Colombian citizens. Verifies that the number is between 6 and 10 digits as required by the Registraduría Nacional. Returns { valid: boolean, cc: string } or { valid: false, reason: string }. Use when processing Colombian individual tax filings, employment contracts, or KYC onboarding flows requiring a verified Colombian citizen ID. Note: checksum validation is not publicly available for CC numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | Yes | Colombian Cédula de Ciudadanía number. Example: '1234567890' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| cc | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: verifies digit range, return format with valid/invalid and reason, and explicitly notes that checksum validation is not publicly available. No contradiction with readOnlyHint=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?
Four sentences, front-loaded with purpose and format, no fluff. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, return format, and a limitation (no checksum). Could be more explicit about possible error reasons, but sufficient given low complexity.
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 provides parameter name, description, and example. Description adds value by specifying the valid digit range (6-10 digits) and the return structure, beyond the schema's example.
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 validates the format of Colombian Cédula de Ciudadanía, specifies the digit range, and distinguishes from sibling validators like validate_cpf and validate_rut_cl by naming the specific document type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios (tax filings, employment contracts, KYC), but does not mention when not to use or compare with alternatives like validate_nit_co.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a Mexican CLABE (Clave Bancaria Estandarizada) — the 18-digit standardized bank account number used for electronic transfers in Mexico, as defined by BANXICO (Banco de México). Applies the official weighted modulo-10 checksum algorithm (weights: 3,7,1 repeating). Returns { valid: boolean, clabe: string, bank_code: string, city_code: string } or { valid: false, reason: string }. Use when processing Mexican wire transfers, validating supplier bank accounts, or building Mexican payment flows in AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| clabe | Yes | 18-digit Mexican CLABE bank account number. Example: '032180000118359719' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| clabe | No | |
| bank_code | No | |
| city_code | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent hints, the description discloses the weighted modulo-10 checksum algorithm with specific weights (3,7,1 repeating) and the exact return structure including valid, clabe, bank_code, city_code, or reason. 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?
Two sentences: first defines the tool's purpose and background, second gives algorithm and return format plus usage context. No filler, front-loaded with essential info.
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 presence of an output schema and the description covering validation logic, return structure, and use cases, the definition is complete for an AI agent to correctly select and invoke the 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 already describes the 'clabe' parameter with format and example. The description adds context about the algorithmic behavior and return values, providing more meaning beyond the schema alone. With 100% schema coverage, baseline 3, but description adds significant extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a Mexican CLABE, specifies it's an 18-digit bank account number for electronic transfers, mentions BANXICO, and distinguishes from sibling tools that validate other identifiers (CBU, CC, CNPJ, 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?
Explicitly states when to use: processing Mexican wire transfers, validating supplier bank accounts, building Mexican payment flows. While it doesn't list when not to use, the positive guidance is clear and the sibling list provides alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a Brazilian CNPJ (Cadastro Nacional da Pessoa Jurídica) — the 14-digit company registration number issued by the Receita Federal. Applies the official two-pass weighted checksum algorithm. Returns { valid: boolean, cnpj: string } for valid CNPJs, or { valid: false, reason: string } for invalid format or failed checksum. Use when processing Brazilian B2B invoices (Notas Fiscais), supplier onboarding, or any compliance workflow requiring a verified Brazilian company tax ID. Offline validation only.
| Name | Required | Description | Default |
|---|---|---|---|
| cnpj | Yes | 14-digit Brazilian CNPJ, with or without formatting. Example: '11.222.333/0001-81' or '11222333000181' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| cnpj | No | |
| reason | No |
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 revealing the algorithm ('two-pass weighted checksum') and specifying return structures for valid vs. invalid inputs, including a 'reason' field for failures. 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 a single coherent paragraph with logical flow: definition, algorithm, output, use cases, and offline notice. No extraneous content, but could be slightly more structured (e.g., bullet points) for easier scanning.
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 and an output schema (implied by the return description), the description covers all essential aspects: input format, return types, algorithm, and usage context. It is sufficient for an agent to use 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 baseline is 3. The description enhances by clarifying that the parameter accepts formatted or unformatted strings and providing full example patterns. It also ties the parameter to the algorithm and outputs.
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 Brazilian CNPJ, explains what it is, and specifies the return format. It distinguishes itself from sibling validation tools (e.g., validate_cpf, validate_cuit) by focusing on CNPJ and its specific use cases in Brazilian B2B invoices and compliance.
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 typical usage scenarios: processing Brazilian B2B invoices, supplier onboarding, and compliance workflows. It also notes 'Offline validation only,' though it doesn't explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a Brazilian CPF (Cadastro de Pessoas Físicas) — the 11-digit individual taxpayer identification number issued by the Receita Federal. Applies the official two-pass modulo-11 checksum algorithm. Returns { valid: boolean, cpf: string } for valid CPFs, or { valid: false, reason: string } for invalid format or failed checksum. Rejects known invalid sequences (all same digits). Use when processing Brazilian e-commerce orders, fintech onboarding, KYC flows, or any compliance workflow requiring a verified Brazilian individual tax ID. Offline validation only — does not query Receita Federal.
| Name | Required | Description | Default |
|---|---|---|---|
| cpf | Yes | 11-digit Brazilian CPF, with or without formatting. Example: '123.456.789-09' or '12345678909' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| cpf | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds details on algorithm, rejection of invalid sequences, return format, and offline nature, enhancing transparency 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 focused sentences: purpose, algorithm, usage. No redundancy, front-loaded with key 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?
Output schema exists, but description still covers return shape briefly. Usage context, limitations, and algorithm are fully addressed. 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 coverage is 100% with formatting example in description. Description explains algorithm and return behavior, adding value 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?
Clearly states it validates Brazilian CPF using modulo-11 algorithm. Distinguishes from sibling tools like validate_cnpj, validate_rfc_mx by specifying Brazilian individual tax ID.
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 use cases (e-commerce, fintech, KYC) and notes offline-only limitation. Does not explicitly mention when not to use or compare with alternatives, 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.
Validates an Argentine CUIL (Código Único de Identificación Laboral) — the labor identification number for individuals in Argentina, used for employment records and social security (ANSES). Uses the same weighted modulo-11 checksum as CUIT. Returns { valid: boolean, cuil: string } or { valid: false, reason: string }. Use when processing Argentine payroll, employment contracts, or any social security compliance workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| cuil | Yes | Argentine CUIL with or without formatting. Example: '20-12345678-9' or '20123456789' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| cuil | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds behavioral details: it uses a weighted modulo-11 checksum and returns a specific success/failure object. No contradictions, and it gives useful output format information 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?
The description is concise at four sentences, front-loads the key action, and every sentence adds value. No fluff, efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, defined output schema), the description is complete. It covers purpose, usage context, algorithm hint, and output format. 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 a clear description and example for the 'cuil' parameter. The tool description adds context about the meaning of CUIL in Argentina but does not add parameter-specific details beyond what the schema provides. 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 identifies the tool as a validator for Argentine CUIL, explains what CUIL is, and distinguishes it from siblings like validate_cuit and validate_cpf by specifying the country and checksum. The verb 'validates' plus specific resource makes purpose unambiguous.
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: 'when processing Argentine payroll, employment contracts, or any social security compliance workflow.' This provides clear context, though there is no explicit exclusion or alternative mentioned, but siblings serve as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates an Argentine CUIT (Código Único de Identificación Tributaria) — the tax identification number for companies, self-employed workers, and legal entities in Argentina, issued by AFIP (Administración Federal de Ingresos Públicos). Applies the official weighted modulo-11 checksum algorithm. Returns { valid: boolean, cuit: string, type: string } or { valid: false, reason: string }. CUIT prefix identifies entity type: 20/23/24/27 for individuals, 30/33/34 for companies. Use when processing Argentine invoices, supplier registration, or AFIP compliance workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| cuit | Yes | Argentine CUIT with or without formatting. Example: '20-12345678-9' or '20123456789' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| cuit | No | |
| type | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) already cover safety, but description adds value by detailing the checksum algorithm and return format (valid, type, 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?
Description is informative but slightly lengthy. Front-loaded with main action, but additional details like prefix explanation could be condensed. Still clear and 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 presence of an output schema (as per context signals), description suffices with return structure and algorithm. Complete for the tool's validation purpose.
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 of the 'cuit' parameter. Description adds meaning by explaining formatting examples and algorithm, going beyond bare 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?
Clearly states it validates Argentine CUIT, explains what CUIT is, and distinguishes from siblings by focusing on a specific tax ID type. Verb 'validates' plus resource 'CUIT' with algorithm details.
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 to use when processing Argentine invoices, supplier registration, or AFIP compliance workflows. Provides clear context without listing exclusions, which is acceptable 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.
Validates whether an invoice JSON object contains the mandatory fields required for a valid electronic invoice in a given Latin American country, based on official tax authority requirements (SEFAZ, SAT, SII, AFIP, DIAN). Returns { valid: boolean, country, missing_fields: [], present_fields: [], warnings: [] }. Use when building invoice generation pipelines, pre-submission validation, or compliance checks in agent workflows. Information is reference only — not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CL', 'AR', 'CO' | |
| invoice | Yes | Invoice object to validate |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| country | No | |
| missing_fields | No | |
| present_fields | No | |
| warnings | No | |
| disclaimer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. Description adds return format details and disclaimer about reference only, no legal advice.
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 purpose and return shape.
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 nested input and output schema described, description covers use cases, return format, and caveat. Also mentions countries covered.
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 description does not need to elaborate on parameters. It mentions country_code and invoice implicitly but adds no new semantics 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?
Description clearly states it validates invoice JSON for mandatory fields per Latin American country, differentiating from siblings like validate_cuit that validate single fields.
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 recommends use for invoice generation pipelines, pre-submission, and compliance checks. Does not explicitly state 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.
Validates a Colombian NIT (Número de Identificación Tributaria) — the tax identification number for companies and legal entities in Colombia, issued by the DIAN (Dirección de Impuestos y Aduanas Nacionales). Applies the official weighted modulo-11 checksum algorithm with the DIAN verification digit. Returns { valid: boolean, nit: string, verification_digit: string } or { valid: false, reason: string }. Use when processing Colombian electronic invoices (factura electrónica), supplier registration, or DIAN compliance workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| nit | Yes | Colombian NIT with or without verification digit. Example: '900123456-7' or '9001234567' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| nit | No | |
| verification_digit | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint, but the description adds the specific algorithm ('weighted modulo-11 checksum') and return structure, which are not obvious from annotations alone. 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?
Two sentences: first defines the tool, second explains usage and return format. No redundant information. Front-loaded with the core 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?
Given the simple input (one string parameter) and presence of an output schema, the description fully covers the tool's behavior, algorithm, use cases, and return structure. 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 description coverage is 100% and already explains the parameter format. The description adds context about the algorithm but does not further clarify parameter semantics beyond the schema. 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 that this tool validates a Colombian NIT (tax identification number) for companies. It distinguishes itself from sibling validation tools like validate_cuit or validate_rfc_mx by specifying the exact identifier and country.
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: 'processing Colombian electronic invoices, supplier registration, or DIAN compliance workflows.' It does not explicitly mention when not to use, but the context of sibling tools implies the exclusivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a Brazilian PIX key — the instant payment identifier used by Brazil's central bank payment system (Banco Central do Brasil). Supports all 4 PIX key types: CPF (11 digits), CNPJ (14 digits), email address, phone number (+55 format), and EVP (random UUID key). Returns { valid: boolean, type: 'cpf'|'cnpj'|'email'|'phone'|'evp', key: string } or { valid: false, reason: string }. Use when processing PIX transfers, validating payment recipients, or building Brazilian payment flows in AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | PIX key to validate. Can be CPF, CNPJ, email, phone (+5511999999999) or EVP UUID. Example: 'user@email.com' or '+5511987654321' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| type | No | |
| key | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool is safe. The description adds the return object structure and supported key formats, which provides useful behavioral context 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 concise (two sentences) and front-loaded with the primary purpose. Every sentence adds value without unnecessary details.
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 single parameter, high schema coverage, annotations, and output schema, the description fully covers the tool's purpose, usage, and behavior. It is complete for an agent 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?
The schema covers 100% of the parameter with a description including examples. The tool description further explains the key types and formats, 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 clearly states it validates a Brazilian PIX key and lists all supported types. It distinguishes from sibling tools like validate_cpf and validate_cnpj by being the only PIX-specific validator.
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: 'processing PIX transfers, validating payment recipients, or building Brazilian payment flows.' It does not mention when not to use or alternatives, but the specific nature of PIX validation makes it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a postal code format for a given Latin American country using the official pattern for that country. Returns { valid: boolean, postal_code: string, country: string, format: string }. Supports BR (8-digit CEP), MX (5-digit CP), CL (7-digit with dash), AR (4-digit legacy or CPA alphanumeric), CO (6-digit). Use in e-commerce checkout validation, address verification, or logistics workflows across LatAm markets.
| Name | Required | Description | Default |
|---|---|---|---|
| postal_code | Yes | Postal code to validate. Example: '01310-100' for BR, '06600' for MX, '8320000' for CL | |
| country_code | Yes | Two-letter ISO country code. Example: 'BR', 'MX', 'CL', 'AR', 'CO' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| postal_code | No | |
| country | No | |
| format | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds value by detailing the return structure and supported country patterns, without contradicting 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 brief (3 sentences), front-loads the purpose, includes return format and examples, and contains 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?
The tool has an output schema, so return values need not be fully detailed. The description covers purpose, supported countries, format patterns, and usage context, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. The description adds country-specific format examples, providing extra 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 clearly states the tool validates postal code format for Latin American countries using official patterns, lists supported countries with their formats, and distinguishes it from unrelated sibling tools like VAT or holiday calculators.
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 suggests use cases (e-commerce checkout, address verification, logistics) but does not explicitly mention when not to use or name alternatives, though it's clear no other sibling tool performs postal code validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a Mexican RFC (Registro Federal de Contribuyentes) — the tax identification number issued by the SAT (Servicio de Administración Tributaria). Validates format for both individuals (13 characters: 4 letters + 6 digit date + 3 alphanumeric homoclave) and companies (12 characters: 3 letters + 6 digit date + 3 alphanumeric homoclave). Returns { valid: boolean, type: 'individual'|'company', rfc: string } or { valid: false, reason: string }. Use when processing Mexican CFDI invoices, supplier registration, or any Mexican tax compliance workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| rfc | Yes | Mexican RFC with or without spaces. Example: 'ABCD850101ABC' (individual) or 'ABC850101AB1' (company) |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| type | No | |
| rfc | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the exact return format (valid, type, rfc or valid false, reason) and validation rules, adding significant context beyond the annotations (readOnlyHint, idempotentHint).
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, no wasted words: first states purpose and background, second gives format details, third return type, fourth use cases. Ideal structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required parameter, output schema, and comprehensive annotations, the description covers all needed context for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3, but the description adds detailed format rules (character composition, homoclave) and examples, enhancing understanding beyond the schema's example.
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 Mexican RFC, specifies formats for individuals (13 chars) and companies (12 chars), and distinguishes from sibling tools that validate other Latin American identifiers (e.g., validate_cbu_ar, validate_clabe_mx).
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 when processing Mexican CFDI invoices, supplier registration, or any Mexican tax compliance workflow,' providing clear, actionable guidance without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates a Chilean RUT (Rol Único Tributario) — the tax identification number used by individuals and companies in Chile, issued by the SII (Servicio de Impuestos Internos). Applies the official modulo-11 checksum algorithm with check digit 'K' support. Returns { valid: boolean, rut: string, check_digit: string } or { valid: false, reason: string }. Use when processing Chilean DTE electronic invoices, supplier registration, or any Chilean tax compliance workflow. Accepts formats with or without dots and dash.
| Name | Required | Description | Default |
|---|---|---|---|
| rut | Yes | Chilean RUT with or without formatting. Example: '12.345.678-9' or '12345678-9' or '123456789' |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| rut | No | |
| check_digit | No | |
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint annotations, the description adds significant behavioral context: the algorithm, return format including error reason, and accepted input formats, providing a complete picture for the AI agent.
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: defines purpose, algorithm, usage, and return format. Front-loaded with key action verb 'Validates'.
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 is referenced (though not detailed), the description covers input, algorithm, output structure, and error handling, making it self-sufficient for a validation tool with clear sibling differentiation.
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 rut parameter, but the description adds valuable examples ('12.345.678-9') and clarifies formatting flexibility, enhancing 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?
Description clearly states it validates a Chilean RUT, specifies the algorithm (modulo-11 checksum with 'K'), and distinguishes from sibling tools like validate_cpf or validate_rfc_mx by emphasizing the Chilean 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?
Explicitly mentions when to use: processing Chilean DTE electronic invoices, supplier registration, or any Chilean tax compliance workflow, implying alternatives for other countries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0calculate_vat_amount_latamcalculate_vat_breakdown_latamcalculate_working_days_latamget_argentina_holidaysget_brazil_holidaysget_chile_holidaysget_colombia_holidaysget_einvoicing_rules_latamget_invoice_requirements_latamget_mexico_holidaysget_next_payment_date_latamget_payment_terms_latamget_public_holidays_range_latamget_vat_rules_latamsuggest_vat_treatment_latamvalidate_cbu_arvalidate_cc_covalidate_clabe_mxvalidate_cnpjvalidate_cpfvalidate_cuilvalidate_cuitvalidate_invoice_schema_latamvalidate_nit_covalidate_pix_keyvalidate_postal_code_latamvalidate_rfc_mxvalidate_rut_clEach tool has a clearly distinct purpose: tax calculations, holiday lists, payment terms, identifier validations, etc. Even similar tools like calculate_vat_amount_latam vs calculate_vat_breakdown_latam are clearly differentiated by scope (single amount vs breakdown).
All tool names follow a consistent verb_noun pattern in snake_case, with an optional country suffix (e.g., validate_cbu_ar). Verbs are descriptive (calculate, get, validate, suggest), and the 'latam' suffix is used uniformly where appropriate.
28 tools is on the higher end but still appropriate for a comprehensive LatAm business toolkit covering tax, holidays, payments, invoices, and identifier validation. The number is justified given the breadth of countries and use cases, though some tools could potentially be consolidated.
The tool surface covers essential business operations for LatAm: tax calculation, holiday calendars, payment terms, electronic invoicing rules, invoice validation, and identifier checks. Minor gaps exist (e.g., currency conversion, legal document generation), but the core workflows are well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Validate LatAm IDs: Mexican CLABE, Brazilian CNPJ/CPF checksums + BrasilAPI company/CEP/bank lookups
Verified LATAM data for AI agents: sanctions, entity, rates, KYB. Pay via x402.
Privacy-safe synthetic financial data for LatAm fintech, AI agents, testing and ML.
LatAm govt data, cited to source: rates, VAT, tax, wages, holidays, FX. 22 countries; Brazil free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/josemvelez78/mcp-latam-business'
If you have feedback or need assistance with the MCP directory API, please join our Discord server