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

No annotations provided, so description takes full responsibility for behavioral disclosure. It accurately characterizes the tool as a read-only query ('consulta') that returns JSON data from an external source (BrasilAPI/BACEN), with no mention of side effects. This is adequate for a simple read 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 succinct, with front-loaded purpose and no unnecessary words. Each sentence contributes distinct value: source, output, usage scenarios, anti-patterns, and common codes. Ideal length for quick understanding.

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

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

Given the tool's simplicity (1 required parameter, no output schema), the description covers all necessary aspects: purpose, input, output format, usage guidelines, and examples. No gaps remain for an agent to misinterpret.

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 parameter description in the schema already details the code format, allowed types, and examples. The description adds only redundant examples and no new semantic information beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly specifies the action ('consultar') and resource ('banco brasileiro pelo código COMPE/Febraban'), distinguishes from siblings by focusing on a specific query via API, and lists the returned fields (nome curto, nome completo, código, ISPB).

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 (user provides bank code, needs name or ISPB for PIX/TED) and when NOT to use (search by name, validate account, consult agency/account), including an alternative tool (listar_bancos) for name-based search.

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?

In absence of annotations, description discloses that source does not expose current day, omitted date defaults to yesterday, and non-trading days return last business day; also describes return JSON structure (ABERTURA, INTERMEDIÁRIO, FECHAMENTO with buy/sell rates). 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 front-loaded with purpose, then covers output, edge cases, usage, exclusions. Every sentence is informative and necessary.

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 2 parameters, 100% schema coverage, no output schema, description fully covers return format, date edge cases, supported currencies, and exclusions. Complete for a single-query currency rate tool.

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

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

Schema covers 100% of parameters, but description adds context: date format, default behavior, list of ISO codes, case-insensitivity. Goes 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 verb 'Consulta', resource 'cotação de câmbio oficial de uma moeda estrangeira em relação ao Real (BRL) numa data', and output format. Differentiates from sibling tools by mentioning listar_moedas for supported currencies.

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 provides use cases (e.g., quanto tá o dólar?) and non-use cases (criptomoedas, BRL, historical series, unsupported currencies). Also directs to listar_moedas for discovering available currencies.

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

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

With no annotations, the description carries full burden. It discloses the use of multiple providers with automatic fallback, return fields including coordinates, and input format. Lacks specifics on error handling but sufficient for a simple lookup.

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 two sentences, front-loaded with purpose, and every sentence adds value. No redundancy or 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, no output schema), the description covers purpose, usage, input format, and return fields. Complete for an agent to select and invoke correctly.

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

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

Input schema has 100% coverage for the single parameter 'cep'. The description adds value by clarifying acceptable formats (with or without hyphen, 8 digits), which is not in schema. Provides usage guidance 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?

The description clearly states the tool consults full addresses from Brazilian CEPs via BrasilAPI v2, with multiple providers and fallback. It explicitly distinguishes from siblings by focusing on CEPs, not other postal codes.

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: for address lookup, validation, or discovering city/state from a CEP. It also clearly states when not to use: for non-Brazilian codes or reverse lookup.

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 details the return format (JSON) and lists all returned fields. It mentions the external API source (BrasilAPI) and invalid input handling. However, it does not discuss rate limits, error responses, or latency, which would improve 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 efficient at 4-5 sentences, front-loading purpose and usage. However, the list of return fields is a dense run-on sentence that could be structured better with bullet points or shorter sentences.

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

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

Despite no output schema, the description thoroughly explains the return values, input handling, and behavioral constraints. It covers all necessary aspects for a single-parameter tool, leaving no major 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%, baseline 3. The description adds value by clarifying accepted formats (with/without mask, 14 digits) and provides validation guidance beyond the schema, such as rejecting invalid formats without calling the tool.

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 consults Brazilian company data by CNPJ via BrasilAPI and lists the specific fields returned. It distinguishes from sibling tools like consultar_cep or consultar_banco by specifying it's for CNPJ only.

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 explicitly says when to use: when user asks for info about a company identified by CNPJ. It also states what NOT to use (CPF, foreign companies, format validation) and instructs to reject invalid format without calling the 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?

No annotations provided, but description covers return format (JSON) and fields included. Does not mention rate limits or error handling, but sufficient for a simple query 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?

Single paragraph with clear sections for purpose, return data, and usage guidelines. Concise but thorough, 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 simple lookup with one parameter and no output schema, description is complete: explains what it does, what it returns, and when to use it.

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

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

Schema covers 100% of parameter, description adds value by specifying format (com ou sem máscara, 14 dígitos) and providing an example, which exceeds schema description.

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

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

Description clearly states it consults cadastral data of a securities broker authorized by CVM via BrasilAPI, specifies the resource and source, and distinguishes from sibling tools like consultar_cnpj.

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

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

Explicitly provides when to use (user provides CNPJ to check if authorized broker) and when not to use (for general companies, insurance brokers, or search by name), with clear alternatives.

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

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

With no annotations, description covers the read-only nature and return format. Minor missing details on potential errors or rate limits, but sufficient for an API lookup.

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 main function and output, followed by usage rules. 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?

Despite no output schema, description explains return format. Could mention external dependency on BrasilAPI availability, but overall adequate for a simple lookup.

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

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

The only parameter 'ddd' has full schema description with examples. Description adds clarifications on accepted types (string/number) and example codes, 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 lists cities by DDD code via BrasilAPI and returns JSON with state and cities. It is distinct from sibling tools like consultar_cep, which handle different data.

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 (e.g., user asks about DDD coverage) and when not to (e.g., full phone validation, reverse lookup), providing clear boundaries.

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

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

Discloses that results are never cached (always current), returns specific fields, and notes what the API does not expose (titular/whois). No annotations are provided, so the description carries the full burden; it does well but could mention potential rate limits or authentication.

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-4 sentences) with front-loaded purpose, no redundant words, and clear bullet points for output types. 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?

Despite no output schema, the description fully explains return fields (status, fqdn, servers, expiry, suggestions) and covers when/not to use. It is complete for a single-parameter query 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 description, but the description adds value by explaining normalization of input (URLs, www, path removal) and acceptable formats. This goes beyond what the schema alone provides.

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

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

The description clearly states the tool checks .br domain registration status from registro.br via BrasilAPI, specifying exact purpose and output fields. It distinguishes well from sibling tools like consultar_cep or consultar_cnpj by focusing solely on .br domains.

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

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

Explicitly provides when-to-use examples ('o domínio X.com.br tá livre?') and clear exclusions: not for international domains, whois data, or hosting. This fully guides agent selection.

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

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

With no annotations, the description carries full burden. It discloses return format (JSON array with date, name, type), inclusion of movable holidays (Carnival, Easter, Corpus Christi), and the API source. 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 and front-loaded with the main action. Every sentence provides unique value, with 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?

For a simple list tool with no output schema, the description covers return format, included holiday types, and usage constraints (national only, year range). Complete enough for correct invocation.

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

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

Schema coverage is 100%, baseline 3. Description reinforces the acceptable year range but adds little beyond the schema's parameter description. It does not introduce new semantic details.

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 lists national Brazilian holidays for a specific year via BrasilAPI, with a specific verb and resource. It is distinct from sibling tools (bank, CEP, CNPJ, etc.), making it 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?

Explicitly provides when to use (e.g., querying holidays, planning weekends) and when not to use (state/municipal holidays, non-holiday dates, years outside 1900-2199), with clear 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?

The description discloses it is a read operation returning JSON with specific fields (título, subtítulo, autores, etc.), aggregates multiple sources, and performs local validation of ISBN length. No annotations are present, so the description fully covers behavior.

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

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

The description is compact (4 sentences) and front-loaded with the core purpose. Every sentence adds value: function, return info, usage cases, and exclusions. 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?

For a single-parameter tool without annotations or output schema, the description covers purpose, usage, return details, and validation. It lacks explicit error handling (e.g., ISBN not found), but the coverage is otherwise comprehensive.

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 already fully describes the parameter 'codigo' (type, format, example) with 100% coverage. The description adds further context about ISBN-10/ISBN-13 acceptance and validation, 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?

The description clearly states the verb ('Consulta'), the resource ('metadados de um livro pelo ISBN'), and the sources (BrasilAPI, CBL, etc.), distinguishing it from sibling tools (consultar_cep, consultar_cnpj, etc.) which focus on other types of queries.

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 when-to-use ('quando o usuário fornecer um ISBN e quiser saber sobre o livro') and when-not-to-use (search by title/author, format validation, price/availability) are provided, guiding the agent effectively.

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, description carries behavioral disclosure. It warns about long lists for large states (SP: 645 items, ~30KB) and specifies return format (JSON array). Could mention error behavior or rate limits, but current info is valuable.

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 moderately concise with front-loaded purpose. Each sentence adds value, though some repetition could be trimmed (e.g., 'Prefira usar...' and 'Use quando...' are similar).

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 simple tool (1 param, no output schema), description is comprehensive: covers purpose, input format, output structure, size warning, and exclusions. No gaps remain for competent use.

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

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

Only one parameter 'uf' with schema covering 100% (2-letter state code). Description doesn't add extra meaning beyond schema, but schema is clear. Baseline 3 applies.

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 lists municipalities by UF, providing name and 7-digit IBGE code. It distinguishes from siblings by specifying scope (list all) and not for other lookups like CEP or population.

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 (need IBGE code or list cities) and when not to (country-wide name search, address/CEP, population). Recommends alternative tool 'consultar_cep' for addresses.

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 provided, but description discloses return format (JSON with name and value), limitation (only latest value, no history), and is clearly read-only. Could explicitly state 'read-only' but context makes it evident.

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 3 sentences, front-loaded with core purpose, then usage guidelines. Efficient and well-structured; slight room to be more concise (e.g., bullet points) but no fluff.

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

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

For a simple 1-param tool, description covers purpose, usage, exclusions, and return format. Could mention error handling or API reliability, but overall sufficient.

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

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

Schema description already covers the single parameter (sigla) with values, case-insensitivity, and meanings. Description adds no new info beyond 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?

Description clearly states it consults current Brazilian economic rates (SELIC, CDI, IPCA) via BrasilAPI, with specific verbs and resource. It distinguishes from sibling tool listar_taxas, which provides an overview of all three.

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 (user asks for current specific rate), when not to use (historical data, other rates, dollar/stock market), and alternative tool (listar_taxas for all three rates). No ambiguity.

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 provided, so description carries full burden. Discloses return format (JSON array), size (~250 entries), and suggests citing only relevant ones. Lacks rate limit or auth info but acceptable for public API.

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?

Single paragraph but well-structured: starts with purpose, then usage guidelines, then constraints. Could be more structured but effective.

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?

No output schema, but description adequately explains return values (array with name, code, ISPB). Also provides size and response suggestion, making it complete for this no-param tool.

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

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

Zero parameters, so baseline 4. Description adds value by explaining output structure and usage 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 lists all Brazilian banks from BACEN via BrasilAPI, returning name, code, and ISPB. Differentiates from sibling tool consultar_banco for specific code.

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

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

Explicitly says when to use (complete list, search by name, discover code) and when not to (if user provided numeric code, use consultar_banco which is cheaper). Provides filtering 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?

Although no annotations are provided, the description clearly states the source (IBGE via BrasilAPI), the output structure, and what data is not included (demographic/population). It could have mentioned idempotency or caching, but for a static list, the transparency 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?

Description is concise with no filler, front-loaded with the main action, then provides details, usage guidance, and exclusions. 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?

Given zero parameters and no output schema, the description fully covers what the tool does, what it returns, and when to use it. The context 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?

Input schema has no parameters, so description carries full burden. It adds meaning by describing the output fields and usage context, compensating for the lack of param info. No extra param details needed.

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

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

Description explicitly states it lists all 27 Brazilian states with IBGE data, returning JSON array with specific fields (id, sigla, nome, região, capital). It clearly distinguishes from sibling tools like 'consultar_municipios' by specifying it does not handle municipalities.

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

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

Provides explicit use cases: needing IBGE code, grouping by region, validating UF acronyms, or knowing capital. Also gives explicit negative cases: not for municipalities (refer to consultar_municipios) and not for demographic data (not in this API).

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 fully discloses behavior: it is a read-only list operation with no parameters, returns JSON array of 10 specific currencies with symbol, name, and type. No destructive side effects.

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

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

Three sentences, each essential. Front-loaded with primary purpose, then details and usage guidance. 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 no output schema, description explains return format (JSON array) and content (symbol, name, type) and enumerates the currencies. No parameters mean no missing parameter info. Fully 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?

No parameters exist, so the description fully covers parameter semantics. Baseline 4 is appropriate since there is nothing to explain 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 lists foreign currencies with available quotes from BrasilAPI, lists the exact 10 currencies and output fields. Distinguishes from sibling tool consultar_cambio by explicitly stating not to use for quotes.

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 guidance: use when user wants to know which currencies have quotes or doesn't know the currency code; do not use for obtaining the quote itself (use consultar_cambio instead).

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 provided, so description carries full behavioral burden. It describes return format (JSON array with name and value), mentions payload size is small, and lists exactly 3 taxes. It doesn't mention any destructive actions (none expected). Could be improved by noting data source or update frequency, but 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?

Highly concise yet informative. Front-loaded with purpose, followed by usage guidance and return format. Every sentence adds value without redundancy.

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

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

Given no output schema, description explains the return structure (JSON array with name and value), lists the specific rates, and notes there are exactly 3. This is complete for a simple list 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?

Input schema has zero parameters, and schema coverage is 100% (vacuously). Baseline for zero-param tools is 4. The description doesn't need to add parameter info, and it correctly implies no user input is needed.

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 lists all Brazilian economic rates (SELIC, CDI, IPCA) with current values. It distinguishes itself from sibling consultar_taxa by noting it returns all rates vs a specific one.

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 provides use cases: when user wants a panoramic view or doesn't know specific rate. Also states when NOT to use (when user knows specific rate) and directs to the sibling consultar_taxa.

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