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

With no annotations, the description carries the full behavioral burden. It clearly communicates a read-only 'Get' operation and discloses that the tool returns both official and informal (blue) rates. It does not specify update frequency or data source, but for a simple, side-effect-free exchange-rate retrieval this is sufficient.

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

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

The description is two sentences with no filler. It front-loads the core purpose and then adds valuable context about the official/blue gap in the second sentence. Every word earns its place.

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

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

For a zero-parameter tool with an output schema, the description is sufficiently complete for selection and invocation. It explains what the tool returns, the Argentina-specific relevance, and why the blue-rate gap matters. The only minor gap is data-update cadence, which is not essential for invoking 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?

The input schema has zero parameters, so the baseline is 4. The description correctly avoids inventing parameter details and doesn't need to explain invocation arguments. Nothing is missing.

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 opens with a specific verb ('Get') and a specific resource ('current Argentine peso (ARS) exchange rates'), then immediately differentiates the tool from generic rate tools by naming the 'official vs blue' split. This clearly distinguishes it from siblings like currency_convert or latam_exchange_rates.

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 context on when the tool is valuable: 'essential context for any pricing, invoicing or purchasing decision in Argentina.' It does not explicitly name alternatives or state when-not-to-use, but the Argentina-specific framing and the blue-rate distinction imply when this tool should be chosen over broader currency tools.

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

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

Since no annotations are provided, the description carries the full burden for behavioral disclosure. It honestly states that it looks up data and returns specific fields, and it mentions the external source 'BrasilAPI'. However, it does not describe behavior on invalid/unknown COMPE codes, possible lack of results, formatting requirements, or any rate limits, which leaves some behavioral uncertainty.

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

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

The description is compact and well-structured: the first sentence states the core action, followed by return fields, a use case, and the data source. Every sentence earns its place with no redundancy or filler.

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

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

This is a simple one-parameter lookup tool with an output schema, and the description covers the parameter, the return fields, and the intended use case. It omits edge-case behavior like not-found handling, but for the simplicity of this tool and the presence of an output schema, it is nearly complete.

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

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

The schema only defines 'code' as a string with no further description, so the parameter semantics rely entirely on the description. The description explains what a COMPE code is and provides concrete examples, adding real meaning beyond the bare schema. It could also specify whether leading zeros or numeric formatting are expected, which keeps it from a 5.

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 opens with a specific verb and resource: 'Look up a Brazilian bank by its COMPE code', which immediately tells an agent what the tool does. The examples '1 = Banco do Brasil, 341 = Itaú' further ground the resource and clearly differentiate it from sibling tools like brazil_company_lookup, which target a different entity 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?

The phrase 'Useful to resolve the institution behind a payment or a bank slip' provides a clear, practical context for when to invoke the tool. It does not explicitly state when not to use it or name alternative sibling tools, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly discloses the data source (Receita Federal via BrasilAPI), the accepted input flexibility (formatted or unformatted numeric CNPJs), and the specific return fields. It does not cover rate limits or error behavior, but for a simple read-only registry lookup this is adequate.

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

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

The description is three short, information-dense sentences with the core action front-loaded. Every sentence adds value: purpose, return data, source, and input format guidance.

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 one-parameter lookup tool with an output schema, the description is complete enough to use correctly. It covers the input format, the expected data source, and the main return contents, leaving no critical ambiguity.

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 0%, so the description must compensate. It explains that the single parameter is a CNPJ and specifies that formatted or unformatted numeric input is accepted, which the bare string schema does not convey. This is sufficient guidance for the one required parameter.

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

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

States a specific verb ('Look up'), a clear resource ('Brazilian company by CNPJ in the federal registry'), and enumerates the returned data. This distinguishes it from sibling tools like validate_tax_id and brazil_bank_lookup.

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 its use case: fetching federal registry data about a Brazilian company from a CNPJ. However, it does not explicitly state when to prefer this over siblings such as validate_tax_id or brazil_bank_lookup, nor does it provide exclusions.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the return shape (every data point plus min, max, average, first, last, change), the accepted series values, the expected ISO date format, and the data source. It does not discuss edge cases like missing dates or rate limits, but it provides solid behavioral context.

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

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

The description is well-structured and front-loaded: it opens with the core action, then lists series values, date format, return contents, use cases, and source. Every sentence adds useful information, and the formatting with backticks and parentheticals improves scanability without wasting space.

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

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

Given the tool's low complexity (3 required string parameters) and the presence of an output schema, the description covers the essential information an agent needs: valid series values, date format, what the response includes, and the data source. It is sufficient for correct invocation and expectation-setting.

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 0%, so the description must compensate. It fully explains the possible values for 'series' (SELIC, CDI, IPCA, USD/PTAX) and clarifies that dates use ISO format YYYY-MM-DD. It does not elaborate on range constraints or inclusive/exclusive date boundaries, but it provides meaningful semantics beyond the 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?

The description states a specific action ('Get a historical time series') and a specific resource ('a Brazilian indicator over a date range'), and even enumerates the exact series supported. It is clear and not a tautology, though it does not explicitly differentiate itself from related siblings like brazil_market_rates or colombia_trm_history.

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

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

The description gives clear usage context by naming example use cases ('trend analysis, indexation, and FX backtesting') and specifying the source (Banco Central do Brasil). However, it does not explicitly state when not to use it or how it compares to sibling tools such as brazil_market_rates or currency_convert.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does add value by stating that values are annual percentages and sourced via BrasilAPI. However, it does not mention update frequency, whether the data is current, or what the response structure contains, leaving some behavioral uncertainty for an agent relying solely on the description.

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

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

The description is two short sentences that front-load the core content (the rate names) and add the essential qualifier about units and source. There is no filler 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?

For a no-parameter data lookup, the description covers what the tool returns (SELIC, CDI, IPCA), the format (annual percentage values), and the provenance (BrasilAPI). The presence of an output schema means the description need not explain return fields in detail. A brief note about these being current/latest values would make it fully complete, but the current text is adequate for a simple read-only 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 tool has zero parameters, so parameter semantics are not applicable. Per the rubric, a no-parameter tool receives a baseline of 4; the description appropriately focuses on the return values rather than input fields.

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 the specific verb 'Get' and names the exact resource: Brazil's key market rates (SELIC, CDI, IPCA). It clearly distinguishes this from sibling tools by naming the specific rates and the Brazil scope, so an agent knows exactly what data to expect.

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 a use case (retrieving current Brazilian market rates) but provides no explicit guidance on when to prefer this over siblings like brazil_historical_series or currency_convert. It does not state exclusions such as 'for historical data, use brazil_historical_series' or 'for exchange rates, use currency_convert'.

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

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

With no annotations, the description carries the full burden and does so well: it discloses weekend/holiday exclusion, ISO date format, inclusive endpoints, and the exact returned shape (count plus only the weekday national holidays that reduced the count). This gives an agent a realistic model of tool behavior.

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

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

The purpose is front-loaded, and each subsequent sentence adds one distinct, needed fact: exclusions, format/inclusivity, return payload, and use cases. No filler or repetition; it is compact for the amount of behavior conveyed.

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 an output schema exists and no annotations, the behavior and return semantics are largely covered. The main completeness gap is the ambiguous country parameter, which is required and has no enum/format guidance; otherwise the description is sufficient to choose this tool over sibling holiday-listing tools.

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 0%, so the description must document all parameters. It usefully specifies start_date/end_date as ISO and inclusive, but the required country parameter is only described as 'a Latin American country' with no accepted code format, country names, or supported-country list. An agent cannot reliably know what value to pass.

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?

States a precise verb and resource: counts business days between two dates for Latin American countries, clarifying that weekends and nationwide public holidays are excluded. The focus on a computed count plus holiday details distinguishes it from listing siblings like public_holidays, next_holidays, and long_weekends.

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?

Names concrete use cases (SLA, payroll, logistics, settlement-date math) and defines the date-range semantics, which makes the intended context clear. It does not explicitly say 'use X instead for holiday lists' or list exclusions, but the use cases imply when this count tool is useful relative to siblings.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: it returns current values, enumerates the indicator set (UF, UTM, USD, EUR), explains the optional filter, and states the unit convention ('CLP per unit'). This goes beyond the bare schema. Minor gaps remain, such as data freshness (daily vs. real-time) and behavior for invalid or unknown codes, but the core behavioral contract is well covered.

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 short sentences, roughly 50 words, with the core purpose front-loaded. Every sentence earns its place: scope, included indicators, filter usage, and unit convention. No redundancy, no filler.

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

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

For a tool with one optional parameter and an output schema present, the description is nearly complete: it states what data is returned, what units, and how to filter. The main omissions are data freshness/staleness and the full set of accepted codes, but these are minor for a simple fetch tool whose return shape is already documented by the output 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 description coverage is 0%, so the description must compensate, and it does: 'Optionally filter with `codes`, e.g. ["UF", "USD"]' explains the purpose of the only parameter, gives a concrete usage example, and clarifies that codes are indicator/currency identifiers. It could go further by listing valid codes or noting case-sensitivity, but for a single optional param, the added meaning is substantial.

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 opens with a specific verb+resource: 'Get current Chilean economic indicators and currency values in CLP.' The Chile scope clearly differentiates it from sibling tools like colombia_trm_history, argentina_exchange_rates, and latam_exchange_rates, and the word 'current' signals this is not a historical-series tool like colombia_trm_history. An agent can identify what this tool does and what it is not without opening the schema.

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?

Usage context is implied ('current Chilean' suggests use when current Chile-only data is needed) but not explicit. The description never names an alternative for other countries (e.g., latam_exchange_rates or currency_convert for general conversion) nor states when NOT to use this tool. No exclusions, prerequisites, or routing conditions are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the rate is officially certified, includes validity dates, and is used for legal purposes, which gives the agent important context about the response's nature. It does not detail update frequency or response structure, but for a zero-parameter getter this is reasonably transparent.

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

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

The description is two brief sentences, front-loaded with the core action and resource, followed by meaningful context. Every word earns its place, and there is no redundancy or fluff.

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

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

For a zero-parameter tool with an output schema, the description sufficiently explains what the TRM is, why it is important, and what the response contains (rate plus validity dates). The presence of an output schema mitigates the need to describe return values, so nothing essential is missing.

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

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

The tool has no parameters, so parameter semantics are not a concern. The schema is trivially 100% covered, and the description adds context about what the returned rate represents, which is useful despite the absence of inputs.

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

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

The description opens with 'Get Colombia's official TRM (Tasa Representativa del Mercado), USD to COP', which states a specific verb, resource, and currency pair. It clearly identifies the tool's purpose as retrieving the legally binding official rate, distinguishing it from siblings like colombia_trm_history or currency_convert.

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 context by explaining that the TRM is the legally binding rate used for taxes, customs, and contracts, implying its use when an official, authoritative rate is needed. However, it does not explicitly name alternatives or state when not to use this tool, leaving some room for inference.

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

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

With no annotations provided, the description carries the disclosure burden and does a reasonably good job: it states the source (datos.gov.co/Superfinanciera), the date format, and that both daily values and a summary are returned. It does not mention edge cases such as weekends, holidays, invalid ranges, or rate limits, but the core behavior is transparent for a read-only history tool.

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

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

The description is compact and front-loaded: the first sentence states the core purpose, and the following sentences add only essential details about format, output, and source. There is no fluff or 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?

The description covers the essential operational context: what data is returned, the date format, and the authoritative source. Since an output schema exists, return-value details do not need to be restated. Missing explicit start/end semantic details and sibling differentiation keep it from being fully complete, but the tool is simple enough that this is not a major gap.

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 0%, so the description must compensate. It adds useful context by specifying ISO (YYYY-MM-DD) format and the date-range concept, but it does not elaborate on inclusive boundaries, allowed ranges, or behavior when dates are invalid or out of order. The parameter names are self-explanatory, making this minimally adequate rather than rich.

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-resource pair: 'Get Colombia's official TRM (USD/COP) history over a date range.' It clearly identifies the resource and scope, and the emphasis on 'history over a date range' helps distinguish it from sibling tools like colombia_official_trm.

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

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

The description provides clear context for when to use the tool: when a historical date-range of Colombia's official TRM is needed. However, it does not explicitly name alternatives or state when not to use this tool versus colombia_official_trm or currency_convert, so it stops short of full routing guidance.

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

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

With no annotations provided, the description carries the full disclosure burden, and it delivers substantial behavioral context: it accepts three distinct cédula variants (física, jurídica, DIMEX), enumerates the returned data (name, regime, activities, compliance status), explains the compliance flags (moroso/omiso), and states the source is official and keyless. It does not disclose failure behavior for malformed/non-existent cédulas, rate limits, or data freshness, which keeps it below a 5.

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?

Roughly 70 words, front-loaded with the core action in the first sentence, then progressively detailed: input format, return payload, use case, and source. Every sentence earns its place — the source/no-key note and the moroso/omiso gloss both add information the agent could not infer from the schema or annotations.

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

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

For a simple one-parameter tool with an output schema already documenting return structure, the description covers the essential operational facts: what identifier to pass, what comes back, and the authoritative keyless source. The remaining gap is edge-case behavior — what happens when a cédula is invalid or not found, and how fresh the registry data is — which is not disclosed anywhere.

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 0% and the cedula parameter is just a bare string, so the description must fully compensate — and it does. It specifies the exact accepted formats: 9-digit cédula física, 10-digit jurídica, or DIMEX. This converts an opaque string parameter into something the agent can validate and format correctly before calling.

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 first sentence states a specific verb ('look up'), resource ('Costa Rican taxpayer/company'), identifier ('cédula'), and registry ('Hacienda'), making the tool's scope immediately unambiguous. It also self-differentiates from siblings: it is clearly a Costa Rican registry lookup rather than a validation-only tool like validate_tax_id or a Brazilian lookup like brazil_company_lookup, and the cédula formats and rich return payload reinforce that distinction.

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

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

The description gives an explicit context for when the tool adds value: 'valuable for KYC/AML and onboarding', which tells the agent the intended use case. However, it never names alternatives or states when-not-to-use scenarios — e.g., it does not route to validate_tax_id for simple format checks — so it stops short of the explicit exclusions a 5 requires.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses the source ('certified by Hacienda') and the nature of the data (buy/sell USD and EUR reference), making it clear this is an official read-only lookup. It does not mention update cadence, but that is a minor gap for a zero-parameter tool.

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

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

Two tightly written sentences front-load the core purpose and add only relevant detail (Hacienda certification, invoicing use case). No filler.

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

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

For a zero-parameter tool with an output schema present, the description is complete: it names the exact data (USD/EUR rates, buy/sell, EUR reference) and the authoritative source. The agent needs no additional info to select and call it correctly.

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

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

The input schema has zero parameters, so there is nothing to disambiguate. Baseline is 4; the description's mention of specific currency pairs and buy/sell orientation complements the empty schema without needing parameter-level detail.

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 opens with a specific verb and resource: 'Get Costa Rica's official USD and EUR exchange rates (colón, CRC).' It further adds buy/sell for USD and EUR reference, certified by Hacienda, which clearly distinguishes this tool from generic exchange-rate or country-specific siblings.

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 the intended application: 'used for invoicing and accounting in Costa Rica.' This gives clear context for when to call the tool, though it does not name alternative tools or explicitly state when not to use it.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It transparently reveals the data source ('open.er-api.com'), the fact that rates are live and USD-based, and the currency coverage scope. It does not discuss failure modes or rate limitations, but for a conversion tool this is meaningful transparency.

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

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

The description is compact and front-loaded: purpose, use case, source/coverage, and code format each earn their place. There is no redundant wording or padding.

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 three-parameter conversion tool with an output schema, the description supplies all needed invocation context: what to pass, how codes should be formatted, which currencies are supported, and where rates come from. It is complete without needing to describe the return value.

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

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

Schema description coverage is 0%, so the description must compensate. It does by specifying ISO 4217 codes with examples (CLP, BRL, USD), clarifying from_currency and to_currency. Amount is left as a plain number, which is already represented in the schema, so the added value is solid but not exhaustive.

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?

Begins with 'Convert an amount between any two currencies at the current rate,' which states a specific verb, resource, and scope. This clearly distinguishes it from sibling rate-lookup tools because it performs conversion rather than merely returning a rate.

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 practical context: 'Handy for pricing, invoicing and reporting across LatAm' and a concrete example (Brazilian price to Chilean pesos). It does not explicitly exclude alternatives or name sibling tools for rate-only lookups, so it stops short of full when/when-not guidance.

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

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

With no annotations provided, the description carries the full burden. It does disclose useful non-obvious behavior: rates are expressed as local currency units per 1 USD, and data is updated daily. However, it does not address what happens on invalid currency codes, whether filters are strict, or any error/edge-case behavior, leaving some transparency gaps.

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

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

Three crisp sentences, each serving a distinct purpose: main scope, coverage list, and rate semantics/update frequency. No filler or repetition, and the most important information is front-loaded.

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

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

For a low-complexity tool with one optional parameter and an output schema, the description covers the essential elements: scope, filter, units, and freshness. It is slightly incomplete in that it leaves alternative-selection and error handling implicit, but nothing critical is missing for a straightforward 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?

Schema description coverage is 0%, so the description must compensate. It does by listing all accepted currency codes and explaining the optional filter behavior. This adds meaning beyond the bare 'array of strings' schema, though it does not explicitly state response behavior for unknown codes.

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 opens with a specific verb+resource: 'Get current USD exchange rates for all Latin American currencies at once.' This clearly differentiates the tool from sibling country-specific tools like argentina_exchange_rates and costa_rica_exchange_rate, and the explicit currency list reinforces the exact scope.

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

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

The 'at once' phrasing implies the tool is for bulk multi-currency needs, and 'Optionally filter with `currencies`' gives basic invocation context. However, there is no explicit when-not-to-use guidance or mention of alternatives such as currency_convert or country-specific rate tools, so usage context is only implied rather than explicit.

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

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

With no annotations at all, the description carries the full burden of behavioral disclosure. It does reveal that the tool returns start/end dates, day count, and bridge-day information, which is useful. But it does not clarify what qualifies as a long weekend, how bridge days are determined, any limitations on supported countries/years, or whether the operation is purely read-only and safe to call.

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

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

The description is very concise and front-loaded. The first sentence states the exact operation and scope, and the second sentence adds return details and use cases. Every sentence contributes meaningful information with no filler.

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

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

The output schema exists, so the return structure does not need to be fully described. However, the input side is under-specified: there is no guidance on country code format, supported countries, or year constraints, and the relationship to sibling tools like public_holidays is left implicit. This is adequate for a basic call but has clear 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 0%, so the description must compensate. It adds meaning by specifying that country must be a Latin American country and that year is the target year for the long weekends. However, it does not provide supported country identifiers, format expectations, or possible year ranges, leaving the agent to guess at valid inputs.

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

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

The description clearly states that the tool returns long weekends, identifies the scope (Latin American country and year), and defines what each result contains. It does not explicitly contrast itself with siblings like public_holidays or business_days, but the 'long weekend' resource is distinct enough that an agent can infer its purpose.

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

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

The description implies usage for travel, staffing, and demand planning, which gives some context for when it would be valuable. However, it does not explain when to use this tool instead of public_holidays, business_days, or next_holidays, nor does it mention any exclusions or conditions.

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

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

No annotations are provided, so the description carries the behavioral burden. It does communicate a read-only lookup and a regional restriction, but it leaves unspecified details such as whether today is inclusive, the timezone used, and how unsupported countries are handled.

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?

A single sentence with no filler. It front-loads the action and resource while including the key temporal and regional constraints.

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

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

The tool is simple and has an output schema, so return-value documentation is not the description's responsibility. Still, the missing country value format and lack of explicit sibling differentiation leave meaningful gaps for an agent deciding how to invoke it correctly.

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

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

Schema description coverage is 0%, and the only parameter 'country' is a bare string. The description adds the useful constraint that the country must be Latin American, but it does not specify whether the value should be a country name, ISO code, or other format, leaving the agent to guess.

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?

States a specific verb and resource: 'Get the upcoming public holidays' for a Latin American country from today. The phrase 'from today' helps distinguish it from the sibling public_holidays, which likely returns a broader holiday set.

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

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

The description implies the tool is for upcoming holidays starting today, which gives some usage context. However, it does not explicitly name alternatives like public_holidays, long_weekends, or business_days, nor does it state when not to use this tool.

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

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

With no annotations, the description carries the behavioral burden and directly discloses the return shape: each holiday with date, local name, English name, and nationwide flag. It clearly frames the operation as a read-only lookup ('Get'), though it omits edge-case disclosures like supported country coverage and year ranges.

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 short sentences front-load the action, then provide parameter context and return fields. Every sentence earns its place, and the use-case list is compact, with no filler.

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

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

The presence of an output schema covers the response structure, so the description only needs to handle selection and parameters. It gives enough to call the tool correctly for a simple country+year holiday lookup, though it omits edge cases like unsupported country codes or invalid years.

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 0%, so the description's explanation of 'country' as an ISO 3166-1 alpha-2 code with examples (CL, AR, MX, BR, CO, PE, UY) adds essential meaning. 'year' is not explained beyond being part of the query, but its role is reasonably inferable; a range or format note would make it fully solid.

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 opens with a specific verb and resource: 'Get official public holidays for a Latin American country and year.' It distinguishes itself from holiday-related siblings like next_holidays, long_weekends, and business_days by focusing on official holidays for a specified country and year and by listing return 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?

The description states concrete use cases ('scheduling, SLAs, logistics, and payroll') and scopes the query to a country and year, making selection clear. It does not explicitly name alternative tools or when not to use them, but the country+year lookup is sufficiently distinct from sibling tools.

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

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

With no annotations provided, the description carries the full burden and covers the key behavioral traits: check-digit verification, per-country format validation, canonical reformatting, and structural decoding into bank/branch/account. The only gaps are handling of unsupported countries and tolerance for input separators, which are minor for a validation tool.

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

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

The purpose is front-loaded in the first sentence, followed by compact format specifics, return structure, and use case in roughly 70 words. Every sentence earns its place and nothing repeats what the schema already provides.

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 2-parameter tool with a bare schema, no annotations, and an existing output schema, the description covers supported inputs, formats, outputs, and the intended scenario—enough for an agent to call it correctly. Minor ambiguity remains over whether MX and AR are the only supported countries, and unsupported-country error behavior is unspecified.

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

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

Schema description coverage is 0%, so the description must compensate — and it does: country is tied to the ISO 3166-1 alpha-2 standard with MX and AR named, and account is constrained by per-country digit lengths (18 for CLABE, 22 for CBU/CVU). It stops short of stating input formatting rules (digits only, no dashes/spaces) or confirming whether the country list is exhaustive.

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?

Opens with a specific verb and resource: 'Validate a Latin American bank account / interbank code, check digit included.' It enumerates concrete country-specific formats (MX CLABE 18 digits, AR CBU/CVU 22 digits) and the decoded output (bank code/name, branch, account number), which clearly differentiates it from siblings like validate_phone_number, validate_pix_key, and validate_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?

Provides clear usage context: agents that 'must confirm an account is well-formed before initiating a transfer' in fintech, payouts, and payment-collection scenarios. However, it does not explicitly name alternatives or state when not to use this tool, even though multiple validation siblings (validate_pix_key, validate_tax_id) sit alongside it.

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

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

With no annotations, the description carries the behavioral burden. It discloses normalization behavior (accepts spaces, dashes, parentheses, optional country code), what it returns (validity, E.164, national format, line type), and even highlights tricky regional cases. It doesn't mention error handling or side effects, but validation terminology implies a read-only operation.

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

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

The description is dense but every part earns its place: the core verb, supported countries, input flexibility, return fields, tricky cases, and ideal use cases are all packed into a compact block. No filler or redundant phrasing.

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 there is an output schema, the description doesn't need to detail return values. It provides enough information to call the tool correctly: supported countries, input format tolerance, and the distinguishing regional complexities. Missing error behavior is a minor gap 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 description coverage is 0%, so the description must compensate. It fully explains 'country' as an ISO 3166-1 alpha-2 code with the 15 supported values, and clarifies that 'number' can include or omit country codes and accept various formatting characters. This adds significant meaning beyond the bare parameter names.

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 ('Validate and normalize') with a clear resource ('Latin American phone number'). It distinguishes itself from sibling validation tools (validate_pix_key, validate_tax_id, validate_bank_account) by being phone-specific and listing supported countries and normalization behavior.

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

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

The description gives clear context for when to use the tool: 'Ideal for WhatsApp, SMS/OTP and CRM hygiene.' It doesn't explicitly state when not to use it or name alternative tools, but the supported country list and use cases make selection straightforward.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains accepted key formats, CPF/CNPJ check-digit validation, and the type-detection behavior. It does not state precisely what happens for invalid keys or how type detection is returned, but the core behavior is transparent.

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

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

The description is compact and front-loaded with the main purpose. The background sentence on PIX is brief and relevant, and the closing usage sentence adds practical value. No major redundancy, though it could trim small redundancies around key types.

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

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

For a single-parameter validator with an output schema, the description covers accepted inputs, validation strength, type detection, and intended use context. It is complete enough for an agent to confidently call the tool, though explicit error/return behavior would add more color.

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

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

The input schema only defines 'key' as a string with 0% coverage, so the description must compensate. It does by detailing that the key can be CPF, CNPJ, e-mail, phone, or EVP and giving digit lengths and format hints. It stops short of providing concrete examples or exact patterns.

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 clear verb ('validate') and specific resource ('Brazilian PIX key') and adds that it detects the key type. It also distinguishes itself from siblings like validate_tax_id and validate_phone_number by covering PIX-specific formats including EVP and phone keys.

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 phrase 'Lets a payments agent confirm a PIX key is well-formed before initiating a transfer' gives a clear use context. It does not explicitly list alternatives or say when not to use it, but the PIX-specific framing is enough to signal it over generic validators.

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

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

With no annotations, the description carries the full burden, and it delivers: it states check-digit verification is conditional, discloses the Mexico RFC exception and the check_digit_verified:false flag, and notes format-only coverage for CR and BO. It also clarifies auto-detection for BR/EC and describes the return information: validity, canonical formatting, and entity type.

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?

Front-loaded with the core action, followed by a dense but necessary country list, then the key algorithm exception and return summary. Every sentence and parenthetical contributes to correct invocation; there is no filler.

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

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

For a high-complexity tool covering 14 countries and multiple ID schemes, the description covers accepted ID types, check-digit verifiability, exceptions, auto-detection, and result semantics. Since an output schema exists, the lack of exhaustive return-field detail is not a gap; nothing an agent needs to select or call the tool correctly is missing.

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

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

Schema description coverage is 0% and the schema only defines two plain strings, so the description must add meaning; it does by defining country as ISO 3166-1 alpha-2 codes and mapping each code to accepted tax ID types, including auto-detection for CPF/CNPJ and cédula/RUC. It also ties check-digit behavior to the tax_id parameter.

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

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

The description opens with a specific verb and resource: 'Validate a Latin American national tax ID, including its check digit.' It also enumerates supported country-specific ID types (CL RUT, AR CUIT/CUIL, MX RFC, etc.), which clearly distinguishes it from sibling validators like validate_phone_number and validate_bank_account.

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

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

It gives clear context for when to use: validating tax IDs of the listed Latin American countries, with auto-detection and format-only caveats. However, it does not explicitly name alternatives or state when-not-to-use it, so it stops short of fully explicit alternative routing.

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