mcp-fiscal-brasil

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

No annotations are provided, so the description carries the full burden. It states the input format (pipe-delimited text) and that it extracts information, but does not disclose potential side effects, error handling, or idempotency. Since it is a read-only analysis, the description is adequate but could be more explicit about safety and limitations.

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

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

The description is a single sentence that front-loads the action and key details. It is concise without being overly terse, though it could include more usage guidance without losing conciseness.

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 existence of an output schema (not shown), the description appropriately focuses on input and purpose. It covers the file types, extracted information, and input format. However, it omits mention of file size limits, encoding, or asynchronous processing, which are minor gaps for a file analysis 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 both parameters described in the schema. The description adds 'formato pipe-delimitado' reiterating what the schema already says for 'conteudo', and does not enhance understanding beyond the schema. No additional semantics are provided for 'nome_arquivo'.

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 'analisa' (analyzes) and the resource 'arquivo SPED' with specific types (EFD-ICMS/IPI, etc.), and outlines what information is extracted. It distinguishes from sibling tools like 'summarize_sped' (summarizes) and 'listar_registros_sped' (lists records) by implying a comprehensive analysis.

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 explains what the tool does but provides no explicit guidance on when to use it versus alternatives like 'summarize_sped' or 'listar_registros_sped'. Usage is implied for when a detailed extraction of period, company, errors, etc. is needed, but no when-not-to-use or prerequisite conditions are stated.

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 full burden. It discloses that the tool combines data from multiple sources and produces a score, risk classification, and actionable findings. It does not mention limitations like data freshness or authentication, but the behavioral traits are well-communicated for a read-only analysis.

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, front-loading the purpose and then detailing the output structure. Every sentence adds value with no wasted words.

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

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

Given the tool's complexity (combining multiple data sources) and the presence of an output schema, the description provides sufficient context: it explains the report components (score, risk, findings) and intended use. Minor gaps like scoring methodology are likely covered 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 coverage is 100% with a single parameter 'cnpj' already well-described in the schema. The description adds no additional meaning beyond what is in 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 states it performs a consolidated fiscal compliance analysis of a CNPJ, combining multiple data sources into a single report with score, risk, and findings. It distinguishes itself from sibling tools like consultar_simples_nacional or consultar_cnae, which are single-source 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?

The description explicitly says to use this tool for deciding to hire/refuse/investigate a company in one call, providing clear usage context. However, it does not explicitly state when not to use it or mention alternative tools, though siblings are available.

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 adequately discloses key behaviors: requires local A1 certificate, uses mTLS, never sends certificate, supports incremental and specific queries, and notes that full XML requires prior consultation (Ciencia da Operacao). Password safety is highlighted.

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

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

The description is a single, well-structured paragraph of five sentences. It front-loads the primary action and requirements, then details search modes. Every sentence provides essential information with no redundancy.

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

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

Given 10 parameters and no annotations, the description covers purpose, requirements, and search modes. It mentions a prerequisite (Ciencia da Operacao) for full XML. An output schema exists, so return values are not needed. It lacks error handling or rate limits but is otherwise 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?

Although schema coverage is 100%, the description adds meaningful context by explaining the search modes (distNSU, consNSU, consChNFe) and their parameters (ultimo_nsu, nsu, chave). It goes beyond schema definitions by clarifying usage semantics like default NSU and prerequisites.

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 downloads fiscal documents via NFeDistribuicaoDFe using a local A1 certificate. It lists three search modes (distNSU, consNSU, consChNFe), distinguishing it from sibling tools like consultar_nfe or manifestar_nfe which serve different purposes.

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

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

The description implies usage for downloading fiscal documents and specifies prerequisites (certificate, CNPJ, UF). However, it does not explicitly state when to use this tool versus alternatives or provide when-not-to-use guidance, leaving agents to infer from context.

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. It clearly states search and return functionality, but does not explicitly mention read-only nature or any limitations.

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

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

Two concise sentences, each serving a purpose: first states action, second explains utility. No extraneous 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?

With a single parameter, high schema coverage, and presence of an output schema, the description provides sufficient context for an agent to use 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?

Schema covers the only parameter 'texto' with description, and the description adds example values ('software', 'restaurante'), enhancing understanding beyond the schema.

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

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

Description clearly states it searches CNAE activities by text in description and returns subclasses. It distinguishes from sibling 'consultar_cnae' by specifying the search-by-text functionality.

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?

Describes when to use (finding CNAE code from business activity), but does not explicitly mention when not to use or mention alternatives like 'consultar_cnae'.

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. It discloses that it fetches historical series from BCB and applies accumulated factor, but does not mention failure modes, performance, or data availability issues. Adequate but not thorough.

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

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

Two concise sentences: first states the action and indices, second provides use cases. No redundant wording, efficiently front-loaded.

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

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

Given presence of output schema, explanation of return values is not needed. The description covers purpose, method, and use cases. Could mention potential data gaps or error handling, but overall complete for a tool of this complexity.

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

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

Schema covers all parameters with descriptions (100% coverage). The description reinforces the meaning (e.g., 'valor original' in reais) but does not add new semantic detail beyond what is in the schema. Baseline 3 is appropriate.

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

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

The description clearly states it calculates monetary correction using IPCA or Selic with specific verbs ('calcula', 'busca', 'aplica') and identifies the resource (valor entre duas datas). It is distinct from sibling tools like ipca_periodo and taxa_selic which only return 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 context ('atualizacao de dividas, contratos e obrigacoes fiscais') but does not explicitly state when not to use or compare with similar tools (e.g., for just rates use ipca_periodo or taxa_selic). The usage is implied but not differentiated.

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 behavioral traits: it explains the cascade order, the need for user-supplied II rate, and lists out-of-scope items. This compensates for the lack of annotations, though the output structure is not described (but output schema exists, so per rules not required).

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 relatively long but well-structured: purpose, usage, important notes, cascade details, disclaimer, parameter list. It is front-loaded with purpose. Some redundancy could be trimmed, but overall efficient given the complexity.

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

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

Given the tool's complexity (9 parameters, cascade calculation, no annotations, output schema exists), the description covers all major aspects: purpose, usage, cascade method, required user action, disclaimer, and parameter list. It is complete for an AI agent to understand and invoke correctly.

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

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

Schema coverage is 100%, so baseline 3. The description adds value by explaining the cascade relationship and the need to get aliquota_ii from the TEC website, which is not in the schema. However, it mostly repeats 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 explicitly states 'Calcula os tributos de importação em cascata para um produto classificado por NCM', providing a specific verb and resource. It distinguishes from sibling tools like 'consultar_aliquotas_importacao' by focusing on cascading calculation.

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 includes 'Quando usar: ao planejar uma importação e precisar estimar o custo total de tributos', giving clear context. It does not explicitly state when not to use or directly compare with siblings, but the disclaimer about scope provides some exclusion 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns estimates (effective rate, annual tax, best option) and notes that optional payroll impacts Fator R. However, it does not mention any side effects, auth needs, or data persistence, which is acceptable for a comparison 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 three concise sentences in Portuguese, front-loading the main purpose. Every sentence adds value with no redundancy.

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

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

Given the presence of an output schema, the description adequately covers the tool's inputs, purpose, and a key behavioral detail (Fator R). It provides enough context for an agent to understand when to use this tool versus sibling tools that handle SPED or CNPJ queries.

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 compensates by explaining that 'faturamento' (revenue) and 'setor' (sector) are used, and 'folha opcional' (optional payroll) impacts Fator R. It even lists example sectors (comércio, serviços, indústria), adding significant meaning 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 clearly states the tool compares Brazilian tax regimes (MEI, Simples Nacional, Lucro Presumido, Lucro Real) for a given revenue scenario and sector, returning effective rate, annual tax, and best option. This is a specific verb-resource combination that distinguishes it from sibling tools like consultar_cnpj or analisar_sped.

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 mentions it is useful for 'quick tax planning' (planejamento tributário rápido), providing context but no explicit when-to-use or when-not-to-use. It does not name alternative tools for more detailed analysis.

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 handles transparency. It discloses offline behavior ('calcula a partir de tabelas em memória; não requer conexão') and a specific exclusion (4% for imported goods). It does not cover error handling for invalid UFs, but the parameter guidance mitigates that.

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 informative, with clear sections for purpose, usage, behavior, and notes. Every sentence adds value, though it could be slightly more terse.

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

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

Given the presence of an output schema, the description does not need to explain return values. It covers purpose, usage, behavior, parameter details, and a limitation, making it comprehensive for an agent to use correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by specifying that UFs must be uppercase and reinforcing examples. It also explains the parameters' role in the tool's purpose.

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 consults ICMS rates for interstate operations between taxpayers, specifically for calculating DIFAL and the applicable interstate rate for NF-e issuance. It distinguishes itself from sibling tools (e.g., consultar_cfop, consultar_ncm) by focusing on ICMS interstate 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 'Quando usar' section explicitly lists scenarios: issuing interstate NF-e, calculating DIFAL, or verifying tax burden between states. It also provides a limitation note about the 4% rate for imported goods. However, it does not exclude alternative tools or mention when not to use.

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

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

Discloses offline behavior (reads from bundled SQLite database, no connection required) and explicitly states the unavailability of the II rate. While it lacks annotations, the description adds substantial behavioral context beyond the schema.

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 with clear sections for purpose, usage, important notes, and parameter details. Each sentence serves a purpose, and there is no redundant information.

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

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

Given the simple parameter set and the presence of an output schema, the description adequately covers the tool's role and constraints (offline, missing II). It could briefly mention output structure, but the overall context is sufficient.

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

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

Schema coverage is 100% and already describes the NCM parameter format. The description merely repeats the format with examples, adding no significant new semantic meaning beyond what the schema provides.

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

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

The description clearly states it consults reference rates for import tax calculation by NCM, specifically IPI and defaults for PIS/COFINS. It distinguishes itself from the sibling tool 'calcular_tributos_importacao' by identifying its role as a preliminary step.

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 ('antes de calcular tributos de importação') and provides a critical warning that the II tax rate is not available offline and must be sourced externally. This guides the agent on both usage and limitations.

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. It clearly discloses that the tool returns address components (logradouro, bairro, cidade, estado, serviço de origem) and is a read-only query, with no mention of destructive actions.

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

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

The description is two concise sentences, containing all essential information with no unnecessary words. Every sentence adds value.

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

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

Given the tool's simplicity (one parameter, clear output schema hinted at), the description sufficiently covers the purpose, input format, and output fields. No further details are needed 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% for the single parameter 'cep', and the description adds value by clarifying accepted formats (with or without hyphen) and providing examples, which the schema does not fully convey.

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

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

The description clearly states the verb 'Consulta' and the resource 'endereço completo a partir de um CEP brasileiro'. It distinguishes from siblings focused on other Brazilian data like fiscal or tax entities.

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 input format details (with or without hyphen) but does not explicitly state when to use this tool versus alternatives. Context with sibling tools implies use for CEP lookup, but explicit guidance is missing.

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 disclose behavior fully. It states the tool 'orients' and 'provides URLs and alternatives', but does not clarify if it actually performs the consultation or returns static guidance. No mention of side effects, read-only nature, or authentication needs.

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

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

Two sentences: first states the purpose and target resource, second adds key details (URLs, automation alternatives). No redundant information, front-loaded with main action.

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

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

The tool has an output schema but the description does not explain the return value structure (e.g., URLs, guidance text). It does not specify if the tool queries external services or returns static info. Given moderate complexity, more detail is needed for an agent to use 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 schema has 100% coverage (parameter described as CPF/CNPJ with format notes). The description mentions CNPJ/CPF but adds no new details beyond the schema. Baseline of 3 is appropriate.

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

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

The description states it guides on consulting a specific certificate (CND) for CNPJ/CPF, providing URLs and automation alternatives. This clearly identifies the resource and action, but the verb 'orients' is slightly ambiguous as to whether the tool performs the query directly. It distinguishes from sibling tools like consultar_certidao_fgts by the certificate 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?

No explicit guidance on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or comparisons with siblings. The distinction is only implied by the certificate name.

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 that the tool provides a URL and automation alternatives, implying a read-only guidance role, but does not explicitly state that it does not perform direct data retrieval or detail side effects.

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

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

The description is two sentences, front-loaded with the purpose, and adds relevant detail about providing a URL and alternatives. No wasted words.

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

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

Given the tool is simple with one parameter and has an output schema, the description covers the core functionality. It could be more specific about the nature of the response, but it is largely sufficient.

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

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

Schema coverage is 100%, so the schema already describes the 'cnpj' parameter. The description adds no additional meaning about the parameter beyond what the schema provides.

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

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

The description clearly states the tool guides on how to consult the Certidão de Regularidade do FGTS (CRF) for a CNPJ, and distinguishes it from siblings like 'consultar_certidao_federal' by specifying the FGTS context.

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

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

The description does not explicitly state when to use this tool versus alternatives such as 'consultar_certidao_federal' or 'analisar_sped'. There is no guidance on context or 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?

No annotations provided, so description carries full burden. It discloses offline behavior, bundled SQLite, and a warning about sample data with instructions to populate. However, it does not specify what happens if the CEST is not found.

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 well-structured with explicit sections (Purpose, Quando usar, Comportamento offline, AVISO, Formato). No superfluous information.

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

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

Output schema exists, reducing need for return value explanation. Covers purpose, usage, offline behavior, and parameter format. It lacks details on error handling or empty results, but is otherwise complete.

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

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

Schema coverage is 100% with a clear description, but the description adds format details (7 digits, with/without punctuation) and examples, enhancing usability 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's function: 'Consulta o Código Especificador da Substituição Tributária (CEST)' and its purpose to identify products subject to ICMS-ST. It is distinct from sibling tools that deal with other tax 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?

Explicitly states 'Quando usar: ao emitir NF-e com produtos sujeitos ao ICMS-ST,' providing direct context. It does not mention when not to use or alternatives, but the sibling list suggests no overlap.

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 fully carries the burden. It discloses offline behavior, dictionary lookup, no network requirement, and explains CFOP group meanings. 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, front-loaded with purpose and usage, followed by behavioral and param details. Every sentence adds value, no redundancy.

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

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

Given the single parameter and existence of an output schema, the description provides complete context: purpose, usage, offline behavior, and param format. No missing aspects.

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 baseline is 3. However, the description adds significant semantic value by explaining the 4-digit format and group classification beyond the schema description.

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

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

The description clearly states the tool queries the CFOP code and explains its purpose for NF-e, SPED, and accounting. It distinguishes from sibling tools like consultar_cest and consultar_ncm.

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 says when to use: when issuing invoices, classifying entries/exits, or analyzing ancillary obligations. It does not mention when not to use or alternatives, but the context is clear.

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

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

No annotations provided. Description mentions it returns code and description but does not state idempotency, authorization needs, or other behavioral traits. Insufficient for a read operation without annotations.

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

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

Two sentences, front-loaded with key information. No unnecessary words.

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

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

Tool is simple with 1 parameter and output schema exists. Description mentions return values, so complete enough for a 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% and schema description already defines the parameter. Description adds little beyond restating the schema info, so baseline 3.

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

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

The description clearly states it consults a CNAE economic activity by subclass code and returns official data. It is specific but does not differentiate from sibling tool 'buscar_cnae'.

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?

Implies usage for identifying business activities from CNAE code, but lacks explicit when-not-to-use or alternatives like 'buscar_cnae'.

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 for behavioral disclosure. It explicitly describes the output (fields returned) and input flexibility (CNPJ formatting). While it doesn't mention error handling or rate limits, the read-only nature is implied, and the description is adequate 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?

The description is two sentences: the first states the purpose and outputs, the second adds input formatting detail. It is front-loaded, concise, and contains no extraneous information.

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

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

Given the tool's simplicity (one parameter, output schema exists), the description covers the main aspects: what it does, what it returns, and input flexibility. It could mention edge cases like invalid CNPJ, but overall it is sufficiently complete for a straightforward lookup tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds overall context for the parameter by listing what data is returned, but does not provide additional syntactic or semantic detail beyond the schema's own description of the CNPJ parameter.

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

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

The description clearly states the tool consults complete registration data of a company by CNPJ, listing specific fields returned (company name, address, CNAE, partners, etc.). This distinguishes it from sibling tools like 'consultar_empresa_completa' or 'consultar_simples_nacional' which may have different scopes.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention when not to use it. Implicitly it is for basic CNPJ lookup, but no explicit differentiation from siblings like 'analyze_cnpj_compliance' or 'risk_score_supplier'.

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 fully convey behavioral traits. It indicates a read operation but does not disclose potential side effects, rate limits, error handling for invalid CNPJs, or prerequisites. This gap leaves the agent underinformed.

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

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

The description is two sentences long, stating the purpose and listing outputs. No redundant information, front-loaded, and appropriate for a simple query tool.

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

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

Given the simple parameter and presence of an output schema, the description covers the core functionality well. It lacks guidance on usage scenarios and error conditions, but overall it is sufficiently complete for a quick 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?

With 100% schema coverage for the single parameter 'cnpj', the description adds marginal value beyond the schema. It contextualizes that the CNPJ is from two sources but does not enhance parameter understanding significantly.

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 'consulta dados enriquecidos' (queries enriched data) combining Receita Federal and Simples Nacional, listing specific return fields. It distinguishes from siblings like 'consultar_simples_nacional' and 'analyze_cnpj_compliance' by its comprehensive 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 description implies use for comprehensive company data queries, but lacks explicit guidance on when to prefer this tool over siblings or when not to use it, such as for simple compliance checks or authority-specific lookups.

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 burden. It mentions per-CNPJ error handling and the return type (compliance summary + risk score), which is helpful. However, it does not disclose whether the operation is read-only, or any authentication or rate limits, 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 two sentences, each carrying essential information: the operation and the use case/error behavior. No superfluous words, front-loaded with core functionality.

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

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

Given the presence of an output schema, the description does not need to detail return values. It covers the key behavioral aspects (batch, errors per CNPJ, use case). It could mention batch size limit, but that is already in the input schema. Overall complete for a well-known tool pattern.

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

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

Schema coverage is 100%, so both parameters are already well-documented by the schema (e.g., CNPJ formatting, max 50 items). The description adds no new semantic value beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states it queries multiple CNPJs in a single batch call and returns compliance summary plus supplier risk score. The verb 'consulta em lote' and resource 'empresas' are precise, and the scope (batch vs individual) distinguishes it from siblings like consultar_empresa_completa.

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 use for quick screening of supplier portfolios with the phrase 'Útil para triagem rápida de carteira de fornecedores.' While it does not explicitly exclude alternatives like single-company queries, the context is clear enough. Missing explicit when-not-to-use or alternative names.

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 exist, so the description carries full burden. It states the action is a 'consulta' (read) via an external API, hinting at network dependency and potential latency. However, it does not disclose error handling, authorization needs, or idempotency. The return fields are specified, which is helpful.

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 short sentences: first states the action and source, second lists returned fields. No redundant information, front-loaded with the core purpose.

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

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

For a simple tool with one parameter and an existing output schema, the description adequately covers functionality and return values. Missing error or validation details, but overall sufficient for its low complexity.

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

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

Schema coverage is 100% with a clear parameter description ('Sigla do estado'). The description only briefly repeats 'pela sigla da UF', adding no extra semantics beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: consulting Brazilian state data by UF abbreviation via the IBGE API, and lists exact return fields (id, sigla, nome oficial, região). This distinguishes it from sibling tools like 'consultar_municipios_ibge' which focus on 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?

The description does not explicitly provide when-to-use or when-not-to-use guidance. It implies usage for state data queries but does not contrast with alternatives (e.g., 'consultar_municipios_ibge' for municipalities) or mention prerequisites like API availability.

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 bears full responsibility. It discloses that the tool queries an external API and returns specific fields. However, it does not mention behavioral aspects like rate limits, authentication, or error handling for invalid UF input. The description is adequate but not thorough.

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 wasted words. It front-loads the purpose, then describes the optional filter, and ends with the return fields. It is perfectly concise and structured for quick parsing.

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

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

Given the tool has a single optional parameter, high schema coverage, and an output schema (context indicates presence), the description is largely complete. It could optionally mention the data source (IBGE) or limitations, but it covers the key aspects of input, filtering, and output.

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

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

Schema description coverage is 100% with the 'uf' parameter having a clear description. The tool description adds value by summarizing the return fields (id, name, microrregião, state) but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate due to high coverage.

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

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

The description clearly states the tool queries Brazilian municipalities via the IBGE Localidades API, optionally filters by UF (state abbreviation), and returns specific fields (id, name, microrregião, state). This distinguishes it from the many sibling tools that handle different data like CNPJ, CEP, or tax regimes.

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 the tool returns municipalities, optionally filtered by UF, which provides clear context. It does not explicitly state when to avoid using it or mention alternatives, but given the variety of sibling tools, the specific purpose is clear enough.

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

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

The description discloses that the tool works offline using a bundled SQLite database and warns about the database being only a sample (~10,515 records). It also specifies the expected input format. Since no annotations are provided, the description carries the full burden and does well.

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

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

The description is concise, with five sentences each serving a distinct purpose: function, usage, offline behavior, database warning, and input format. It is front-loaded and efficient.

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

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

Given the tool's simplicity (single parameter, output schema provided), the description covers all necessary aspects: purpose, usage, behavior, parameter format, and limitations. It is complete for the agent to correctly invoke the tool.

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

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

The input schema already describes the parameter with 100% coverage. The description adds value by providing an explicit format specification ('8 dígitos numéricos, com ou sem pontuação') and an example, which enhances understanding beyond the schema.

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

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

The description clearly states the tool's function: consulting the Mercosur Common Nomenclature (NCM) for a product, with specific applications like tax calculation and document issuance. However, it does not explicitly differentiate itself from sibling tools like consultar_cest or consultar_cfop.

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 indicates when to use the tool ('ao emitir nota fiscal, fazer importação/exportação ou calcular tributos'). It does not provide guidance on when not to use or suggest alternatives, but the context is clear.

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

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

No annotations are provided, so the description carries full burden. It states the tool 'consults' (implied read-only) but does not disclose behavioral traits like error handling (e.g., invalid key), rate limits, or prerequisites beyond having the key. The description is minimal for safety-critical understanding.

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

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

Two sentences concisely deliver purpose, input specifics, and output summary. No extraneous words; front-loaded with the core function.

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

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

With an output schema present, the description sufficiently covers input requirements (key source and format) and output components. For a simple one-parameter tool, this completeness meets needs without gaps.

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

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

Schema coverage is 100% with a clear description of the 'chave_acesso' parameter (44 digits, accept spaces). The tool description adds value by explaining how the key is found (in DANFE), which aids agent understanding beyond the schema.

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

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

The description clearly states the tool's purpose: consulting NFe data using a specific 44-digit access key. It specifies the source (DANFE) and lists the returned data types (emitente, destinatário, itens, valores, protocolo). This distinguishes it from siblings like 'consultar_nfse' (different document) and 'validar_chave_nfe' (validation vs consultation).

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 consulting NFe data but does not explicitly define when to use this tool versus alternatives. It lacks exclusions or when-not-to guidance. However, the context (siblings list) and tool name make the intended use clear without confusion.

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. It discloses the key behavioral trait (municipality-specific systems) and mentions guidance on accessing portals, but does not detail what the tool returns or its internal 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?

Two concise sentences: the first states the purpose, the second provides a critical warning. No unnecessary words.

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

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

Given the complexity of NFSe (no national standard), the description addresses the main challenge. An output schema exists, so return values are covered. It could be improved by specifying whether the tool fetches actual data or provides guidance.

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

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

Schema coverage is 100%, so the description adds little beyond reinforcing the municipality context. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding.

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 NFSe data and immediately distinguishes it by highlighting the lack of national standard, contrasting with sibling tools like consultar_nfe.

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 provides clear context by warning about municipal variability and how to find the correct portal, but does not explicitly state when not to use this tool compared to 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?

No annotations provided, so description carries full burden. It discloses that the tool queries a company's tax regime status and returns current situation, option dates, and exclusion dates. This covers the main behavioral trait (read-only query) without mentioning permissions or errors, but it 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 two sentences: the first states the purpose, the second states the return values. It is front-loaded, concise, and contains no superfluous information.

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

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

Given the tool's simplicity (one parameter, no nested objects, presence of output schema), the description completely covers the tool's behavior: checking Simples Nacional/MEI status and returning relevant dates. No gaps.

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

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

Schema coverage is 100% for the single parameter 'cnpj', and the schema already describes it as a 14-digit CNPJ with optional formatting. The description adds no additional meaning 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 states the verb 'Consulta' and the specific resource 'optante do Simples Nacional ou MEI', and distinguishes from sibling tools like 'consultar_cnpj' by focusing on the tax regime status.

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?

No explicit guidance on when to use this tool versus alternatives such as 'analyze_cnpj_compliance' or 'compare_tax_regimes'. The description implies usage for checking Simples Nacional status but does not provide when-not-to-use or alternative recommendations.

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 notes it uses BrasilAPI and returns dates, but does not disclose authentication, rate limits, or failure modes. It is adequate but not detailed.

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

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

Two sentences, front-loaded with purpose, no fluff. Highly efficient.

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

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

Tool has output schema so return values are covered; description adds context on what is returned. Single parameter fully described in schema. Complete for agent 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?

Schema coverage is 100% and already describes the CNPJ parameter format. The description adds no new meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool checks the MEI and Simples Nacional status of a CNPJ via BrasilAPI, specifying the return fields. It distinguishes from sibling tools like 'consultar_simples_nacional' by focusing on MEI.

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 checking MEI status, but does not explicitly state when to use this tool over siblings like 'consultar_simples_nacional' or provide when-not-to-use criteria.

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

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

No annotations are provided, so the description carries the full burden. It indicates a read operation (querying status) with no side effects, which is implicit. However, it does not explicitly state that it is safe or read-only, nor does it describe the response nature beyond the output schema. An explicit statement about being a non-destructive query 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 concise with three sentences, each providing essential information: what it does, the specific check, and its utility. No redundant words or unnecessary details.

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

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

Given the simple one-parameter query tool and the presence of an output schema for return values, the description sufficiently covers the tool's behavior and purpose. No additional details about output are needed.

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 already describes the 'uf' parameter as a two-letter state abbreviation, but the description adds valuable context: it specifies that the state must be Brazilian, provides examples ('SP', 'MG', 'RJ'), and mentions validation against Brazilian states. This goes beyond the schema's minimal description.

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

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

The description clearly states the tool's purpose: to query the current status of the SEFAZ service for a Brazilian state, specifically checking if the NFe webservice is operational. This distinguishes it from sibling tools like consultar_nfe (which queries NFe documents) and validates its specific role.

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 a clear use case: diagnosing transmission failures of tax documents. It implies using this tool before transmitting NFe to verify service availability. However, it does not explicitly state when not to use it or mention alternatives, but the context of siblings makes the guidance sufficient.

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 fully carries the burden. It discloses the return format (base64), the required namespace, model restriction, and that no certificate is needed. This is comprehensive for a simple 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 four sentences, front-loaded with the core purpose, and contains no unnecessary information. Every sentence adds value (purpose, model, return format, important note).

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

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

Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema (though not shown), the description adequately explains the input requirements, behavior, and output format. No gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by emphasizing the namespace requirement and confirming no certificate is needed. This enhances understanding compared to the schema alone.

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

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

The description explicitly states it generates the DANFE PDF from NF-e XML, specifying model 55 and the return format (base64). This clearly distinguishes it from sibling tools like parse_nfe_xml or consultar_nfe, which have different purposes.

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

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

The description clearly indicates when to use (generate DANFE) and provides constraints (only model 55, namespace required, no certificate needed). It lacks explicit alternatives or when-not-to-use statements, but the context is sufficient.

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

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

No annotations are provided, so the description bears the full burden of disclosing behavioral traits. It only states the return value (monthly percentage variation) but does not mention whether the tool is read-only, if it requires authentication, or any rate limits. For a tool that fetches external data, this is insufficient transparency.

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

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

The description is concise, consisting of two sentences that immediately convey the tool's purpose and usage context. Every sentence provides essential information without redundancy.

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

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

The tool is straightforward (date-range query with two parameters) and has an output schema, so the description does not need to detail return values. It covers the core functionality adequately. However, it could mention that the data comes from BCB/SGS series 433, which is already in the description. Small omissions like error handling or data freshness are acceptable given the presence of an 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 100%, with both parameters described in the schema itself (e.g., 'inclusive' dates, format). The description does not add additional semantic meaning beyond the schema; it merely restates the purpose. Thus, it meets the baseline without adding extra value.

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

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

The description clearly specifies the tool's function: consulting the accumulated monthly IPCA from BCB for a period and returning monthly percentage variation. It uses a specific verb ('Consulta') and resource ('IPCA'), making it distinct from sibling tools that deal with other economic indicators like SELIC or PTAX.

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 mentions that the tool is useful for inflation calculations and monetary correction, which implies appropriate use cases. However, it does not explicitly state when not to use it or provide alternatives (e.g., 'taxa_selic' for interest rates, 'ptax_data' for exchange rates), leaving the agent without clear differentiation 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?

Discloses that public free APIs do not support textual search and that the tool returns guidance instead of actual results, adding critical behavioral context beyond the schema.

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

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

Three concise sentences cover purpose, usage, behavior, and parameters. Front-loaded with key information, no unnecessary words.

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

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

Given simple parameters, presence of output schema, and description covering purpose, behavior, and usage, the description is complete for an agent to select and invoke the tool.

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

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

Schema coverage is 100%, so baseline is 3. Description lists parameters and states 'obrigatório'/'opcional', but adds minimal new meaning beyond the schema's own descriptions.

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

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

Description starts with 'Busca empresas pelo nome empresarial ou razão social', clearly stating the verb (Busca) and resource (empresas). It distinguishes from sibling 'consultar_cnpj' by specifying when not to use.

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 'Quando usar' and 'não usar' sections with clear alternative tool ('prefira consultar_cnpj'), providing direct guidance on when 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?

No annotations are provided, so the description must bear full burden. It implies a read-only list operation, but does not disclose details like pagination, rate limits, or authentication needs. The description is not misleading, but lacks depth beyond basic functionality.

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, front-loading the core purpose and then adding the filter option. No unnecessary words; each 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?

For a simple list tool with one optional parameter, the description covers what it returns (nome, grupo, descrição) and the filter option. Output schema exists, so return format is covered. No gaps given the tool's complexity.

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

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

Schema description coverage is 100% for the single parameter 'grupo', which already details case-insensitive partial matching. The description adds modest value by summarizing the filter options, but largely restates schema information. Baseline of 3 is appropriate.

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

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

The description clearly states the verb (lista), resource (eventos do eSocial), and provides details on output (nome, grupo, descrição). It distinguishes from siblings like listar_registros_sped and validar_evento_esocial by focusing on listing eSocial events with filtering.

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 use: listing events with optional group filter. It lists specific group values. However, it does not explicitly state when not to use it or mention alternatives like validar_evento_esocial for validation tasks.

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

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

With no annotations, the description carries full burden. It only says 'lista' (list), implying read-only, but does not disclose any behavioral traits such as authentication needs, error handling, or performance. Missing details about edge cases (e.g., malformed file, no records).

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

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

Two sentences: first states purpose, second provides an example. No redundant information. Front-loaded and efficient.

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

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

Given the tool's simplicity (2 required params, no nested objects, has output schema), the description covers the core purpose and parameter interpretation. It does not describe the output, but the output schema likely handles that. Leaves minor gap about return format, but overall adequate.

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

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

Schema coverage is 100%, baseline 3. The description adds value by giving concrete examples of record types (C100, E110, 0150), mentions case-insensitivity for 'tipo_registro', and clarifies that 'conteudo' is a pipe-delimited text. This exceeds the schema's basic descriptions.

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

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

The description clearly states the tool lists all occurrences of a specific record type in a SPED file. The verb 'lista' and resource 'ocorrências de um tipo de registro em arquivo SPED' are specific. The example differentiates from siblings like 'analisar_sped' and 'summarize_sped'.

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 an example (e.g., 'buscar todos os registros C100') but does not explicitly state when to use this tool versus alternatives, nor when not to use it. Usage is implied but not explicitly guided.

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 full burden. It discloses critical security behavior: the certificate is never sent to any server and the password is never logged. It also lists event types with requirements. Some server-side behavior is implied but not detailed.

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 somewhat long but well-structured, with clear formatting for event codes. It is front-loaded with the main action and includes important details like certificate handling and password security.

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

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

Given the tool's complexity (10 parameters, output schema exists), the description covers key behavioral aspects, security, prerequisites, and event types. It could include more detail on server-side processing but is generally complete.

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

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

Schema coverage is 100%, so the schema already documents parameters. The description adds value by clarifying the event codes and their meanings, but does not significantly enhance parameter semantics beyond what the schema provides.

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

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

The description clearly states the tool's purpose: 'Manifesta o destinatario em uma NF-e via NFeRecepcaoEvento.' It lists specific event codes, distinguishing it from sibling tools like consultar_nfe or baixar_nfe_distribuicao.

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 requires a local A1 digital certificate and explains that the 'Ciencia' event is a prerequisite for obtaining the full XML. It provides context but does not explicitly mention when not to use this tool or suggest 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, the description carries full burden. It explains that the tool accepts XML with/without envelope and namespace, and returns structured data. However, it does not disclose error handling behavior (e.g., malformed XML) or confirm that it is a pure local operation (no network calls). Behavior is mostly clear but missing some edge cases.

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, front-loaded with the main action and key resource. Every sentence earns its place, no redundancy. It is appropriately concise for a simple tool.

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

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

The tool has an output schema (exists but not shown), so the description does not need to detail return values. It mentions extracted fields (emitente, etc.), which is sufficient. However, it omits handling of parsing errors or encoding issues. Given the simplicity, it is largely complete.

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

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

Schema coverage is 100% for the single parameter 'xml_content'. The description adds meaning beyond the schema by detailing acceptable formats (with/without envelope, namespace). This provides context that helps the agent prepare the input correctly, justifying above baseline 3.

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

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

The description clearly states the verb 'parse' (Parseia) and the resource 'XML completo de uma NF-e ou NFC-e'. It specifies that it returns structured data and lists the extracted fields (emitting, recipient, items, totals, protocol). This is distinct from sibling tools that query by key or validate, showing clear 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 when raw XML is available (e.g., 'Aceita XML com ou sem o involucro <nfeProc>') but does not explicitly state when to use this tool over alternatives like 'consultar_nfe' or 'validar_chave_nfe'. No exclusions or when-not-to-use guidance is given.

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. It mentions the business-day constraint but does not disclose any other behavioral aspects like authentication, rate limits, or return format. More detail would be expected.

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 with only two sentences. The first defines the action and resource, the second adds a critical constraint. No wasted words.

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

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

Given the low complexity (2 parameters, 1 required, output schema exists), the description adequately covers purpose and usage constraints. It could mention output structure but output schema already exists to handle that.

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

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

Schema description coverage is 100% with clear parameter descriptions ('data' format YYYY-MM-DD and moeda defaults to USD). The description adds context about PTAX being compra e venda but does not significantly enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool queries the official PTAX exchange rate from Brazil's Central Bank, specifying both buying and selling rates for a given date and currency. It is distinct from sibling tools like 'consultar_cep' or 'taxa_selic'.

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 a key usage constraint: 'Só disponível para dias úteis' (only available for business days). While it doesn't explicitly compare with alternatives, the tool's specific function makes its context clear.

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

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

The description explains that the tool combines ComplianceReport, applies conservative adjustments, and that the criterios_estritos parameter reduces the score by 10 for anti-corruption policies. However, it does not disclose whether the tool is read-only, requires authentication, or triggers external systems, and no annotations are provided to compensate.

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

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

The description is two sentences long, front-loading the core purpose and output, then elaborating on the optional parameter. Every sentence is informative with no redundancy.

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

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

The output schema is present, so return values are covered. The description mentions the score range and recommendation categories. However, it lacks context about what 'ComplianceReport' is or how the combination works, which could be important for interpreting the results. Overall, it is mostly complete for a simple two-parameter tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context for the criterios_estritos parameter by explaining its effect (reduces score by 10 for anti-corruption policies), which goes beyond the schema's default/description. For cnpj, the schema already specifies format, so no additional info 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?

The description clearly states the tool calculates a risk score (0-100) for supplier due diligence, combining ComplianceReport with conservative adjustments and returning a binary recommendation (approve, approve_with_reservations, investigate, refuse). This distinguishes it from sibling tools that focus on specific compliance checks or data 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?

No explicit guidance is provided on when to use this tool versus alternatives like analyze_cnpj_compliance or consultar_certidao_federal. There is no mention of prerequisites, limitations, or when not to use the tool, which reduces the agent's ability to select it appropriately.

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?

Without annotations, the description carries full burden. It discloses that the tool compares regimes, shows a blend during transition, and returns yearly projections with premises and disclaimers. It is transparent about its simulation nature but could be more explicit about assumptions and error handling.

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

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

The description is three sentences, front-loaded with the core purpose. Every sentence adds essential information without redundancy. It efficiently covers what, when, and how to use the tool.

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

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

Given the tool's complexity (6 parameters, 3 required, tax reform simulation), the description covers the time frame, comparison details, sectors, regimes, and optional inputs. It mentions returning yearly projections with disclaimers; since an output schema exists, this is sufficient for an agent to understand the return format.

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 significant value by explaining the role of optional parameters (aliquota_icms_atual, aliquota_iss_atual) and providing default values (12%, 5%) and examples for PIS/COFINS. This goes beyond the schema's descriptions.

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

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

The description explicitly states the tool simulates the impact of Brazil's tax reform (LC 214/2025) year by year from 2026 to 2033, comparing old and new regimes. It clearly distinguishes from sibling tools like consultar_aliquota_icms or compare_tax_regimes by specifying its unique scope and output.

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 (e.g., for simulating tax reform impact over the transition period, for specific sectors and regimes). It gives guidance on optional parameters for precision but does not explicitly state when not to use it or compare to 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?

No annotations are provided, so the description carries full burden. It mentions input (local .txt file) and output (summary in pt-BR), but does not disclose error handling, file size limits, whether data is modified, or any permissions needed. Significant gaps remain.

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

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

Two concise sentences font-load the main purpose with no unnecessary words. Every sentence adds value, making it efficient and easily scannable.

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

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

For a single-parameter tool with an output schema, the description is fairly complete, covering input, process, and output. However, it lacks mention of error cases or limitations (e.g., file size, unsupported formats). For a complex SPED file, this could be insufficient, but as an executive summary tool, it is adequate.

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

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

The sole parameter 'file_path' has no schema description (0% coverage). The description adds context: 'Recebe caminho de arquivo .txt local', clarifying file type and requirement for local file. However, it lacks details like absolute vs relative paths, file existence checks, or format constraints. The output schema exists, reducing need to explain return values.

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 provides an executive summary of SPED files, identifying type, extracting period, company, total records, blocks, and producing a summary in Portuguese. It distinguishes from siblings like 'analisar_sped' (likely deeper analysis) and 'listar_registros_sped' (listing records).

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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives like 'analisar_sped' or 'listar_registros_sped'. The purpose is implied but no exclusions or usage context are given.

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 discloses that it is a read-only query returning daily rate points. It does not mention limits or behavior for no data, but for a simple data retrieval tool, 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 two sentences, front-loaded with the core purpose, and no unnecessary words. Every sentence adds value.

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

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

Given the presence of an output schema, the description covers purpose, parameters, return format (daily points with date and rate), source, and use cases. It is complete for an agent to use correctly.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description adds context that the parameters define a period, but does not add significant new semantic meaning beyond what the schema already provides.

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

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

The description clearly states the tool queries the daily Selic rate from a specific source (BCB/SGS series 11) and returns a list of daily points with date and rate. It is distinct from sibling tools like ptax_data or ipca_periodo.

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 mentions use cases: interest calculations, monetary correction, and monetary policy analysis. It does not explicitly state when not to use it or alternatives, but the context of sibling tools provides differentiation.

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. It describes the verification process, certificate extraction, and optional CA bundle chain validation. It does not explicitly state read-only behavior, but the actions are inherently read-only. Could be improved by stating no 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, front-loaded with primary function. Every sentence provides essential information without redundancy. Excellent conciseness.

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

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

Given the tool's complexity (signature validation, certificate extraction), the description is complete. It covers optional chain validation and assumes output schema explains return values. No gaps identified.

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

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

Schema coverage is 100%, but description adds meaningful context: xml_content is validated against XXE, and ca_bundle must be PEM content, not a path. This exceeds the schema descriptions.

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

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

Description clearly states it validates XMLDSig signature of NF-e, verifies DigestValue and cryptographic signature, and extracts certificate data. This is distinct from sibling tools like validar_chave_nfe or validate_nfe_full.

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?

Implies usage when needing signature validation of NF-e, but does not explicitly differentiate from alternatives like validate_nfe_full or when not to use this tool. No mention of prerequisites or context.

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, but the description discloses that the tool does not consult APIs and only performs mathematical verification. This is sufficient transparency for a validation tool, though it does not cover permissions or rate limits.

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 highly concise with two sentences: the first states the core purpose, the second adds key behavioral context (no API, extraction). No wasted words.

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

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

Given the tool's simplicity and presence of an output schema, the description fully covers what the tool does and its limitations. It is complete for an agent to understand and use correctly.

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

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

The schema covers 100% of the single parameter, providing a baseline of 3. The description adds value by explaining validation logic and extracted information, going beyond the schema's minimal description.

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

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

The description clearly states the tool validates format and check digit of an NFe access key and extracts information. It distinguishes from sibling tools like 'validate_nfe_full' by explicitly stating it does not call APIs, only mathematical calculation.

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 on what the tool does (validation without API calls) and mentions extracted info, but does not explicitly state when not to use it or list alternative tools. However, the sibling list implies differentiation.

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 burden. It discloses that the operation is offline and mathematical (suggesting no side effects), but does not mention potential limitations or what happens on validation failure.

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 sentences that convey essential information without redundancy or unnecessary detail.

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 and the existence of an output schema, the description adequately covers the core purpose and constraints. It could mention the return type briefly, but the output schema compensates.

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 describes the parameter with examples of formatting; the description adds no additional meaning beyond what is in the schema, so 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?

The description clearly states the tool validates the check digit of a Brazilian CPF using an offline mathematical verification, distinguishing it from siblings that consult external APIs or deal with CNPJ and other documents.

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

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

The description explains that the verification is offline and does not use external APIs, and notes that the Receita Federal lacks a public CPF API, implying this is the appropriate tool for CPF validation. However, it does not 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 carries full transparency burden. It discloses offline behavior ('valida contra tabelas em memória; não requer conexão') and parameter details, but doesn't mention potential return format or error handling.

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, front-loading purpose and usage. It is slightly verbose but each sentence adds value, covering offline behavior, parameter instructions, and digit validation rules.

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 (2 params, offline validation), the description is fully complete. It covers when to use, parameter guidelines, offline behavior, and the output schema existence covers return values.

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

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

Schema coverage is 100%, and the description adds significant value beyond the schema by explaining digit lengths ('3 dígitos para CST ICMS', '2 dígitos para CST PIS/COFINS/IPI', '3 dígitos para CSOSN') and providing examples ('ex: "000", "040"').

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

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

The description clearly states the tool validates CST/CSOSN codes, with specific examples and context (NF-e, SPED). It distinguishes well from sibling tools, as no other sibling appears to focus on CST/CSOSN validation.

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

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

The description explicitly states when to use: 'ao preencher o campo CST/CSOSN na NF-e ou no SPED EFD'. It lacks explicit when-not-to-use or alternatives, but the specific context makes the usage clear.

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

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

Describes specific validations performed (root element, event code, layout version). No annotations provided, so description carries burden; it does not explicitly state non-destructive nature but actions are clearly read-only. Could mention that no modifications occur.

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

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

Two sentences, no wasted words. Front-loaded with primary action. Efficient and clear.

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

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

Given single parameter, no nested objects, and existence of output schema, the description adequately covers what the tool does. No missing essential behavioral details for a basic validation step.

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

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

Schema coverage is 100% for the single parameter xml_conteudo, with a description in schema. Tool description adds no additional meaning: it only repeats the parameter's purpose. Baseline 3 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 validates basic structure of an eSocial event XML, specifying checks for correct root element, event code, and layout version. Distinguishes from sibling tools like validar_chave_nfe that target different document types.

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?

Implied usage for basic eSocial XML validation, but no explicit guidance on when to use this versus a more comprehensive validation tool. Lacks when-not-to-use or alternative recommendations.

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 full burden. It explains the validation steps and return report, but does not disclose error handling, side effects, or authentication requirements. Adequate but not detailed.

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

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

Two sentences, front-loaded with purpose, every word adds value. No redundancy or irrelevant details.

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

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

Given complexity (multiple validation steps) and presence of output schema, description covers inputs, outputs, and key behaviors. Lacks mention of prerequisites like network access for CNPJ check, 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?

The only parameter, 'xml_path', is explained as 'caminho de arquivo XML local' (local XML file path), adding meaning beyond the schema's string type. Could specify format or constraints, but sufficiently clear.

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 performs consolidated validation of an NFe from XML, listing specific checks (structural parse, key digit, CNPJ issuer status). It distinguishes itself from siblings like 'validar_chave_nfe' which only validates the key.

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

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

Description implies usage when local XML file needs full validation, but provides no explicit guidance on when to use this vs. alternatives, nor conditions to avoid using it.

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