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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'free' and 'real authorized bank,' which is some useful context, but doesn't clarify whether this mutates anything, whether it's a read-only operation, what the returned sample represents, or whether rate limits or authentication apply. For a tool with zero annotation coverage, this is insufficient.

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

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

The description is extremely concise at a single short sentence. However, it's arguably under-specified rather than efficiently concise - it's so short it conveys almost nothing about what the sample contains or how to use it. The conciseness itself is fine, but it borders on under-specification.

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

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

Given there's no output schema, no annotations, and this is a data-returning sample tool, the description should explain what the sample contains (e.g., what fields/format of the bank response). It only says 'sample response for a real authorized bank, free' without describing the sample's structure, size, or domain purpose. A sample tool should explain what's being sampled. This is a notable gap.

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

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

The tool has 0 parameters with 100% schema description coverage (there are no parameters to describe). Per the rubric, 0 params = baseline 4. The description correctly implies the tool takes no input since it just returns a static sample. No parameter documentation is needed beyond what's present.

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 'Sample response for a real authorized bank, free' states the tool provides a sample/free response from a real bank, which conveys the general purpose. However, it doesn't clearly state what action the sample is FOR (e.g., checking an institution, Pix data, etc.) and doesn't distinguish what specific data the sample contains. The verb 'obter' (obtain) implies retrieval but the description doesn't clarify what domain area within bcb this checks. It's somewhat clear but lacking specificity.

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 guidance on when to use this tool versus alternatives. There are many sibling sample tools (cnpj_obter_amostra, integridade_obter_amostra, licitacoes_obter_amostra, etc.) and the description provides no context for when this bcb sample would be appropriate, e.g., as a demo or test before calling a paid/full endpoint. No exclusions or alternatives are mentioned.

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

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

With no annotations, the description carries the full burden and does real work: it discloses a per-call cost ($0.005 USDC via x402), a daily update cadence, and that verified internet domains are returned for anti-phishing. It omits error/empty-result behavior and any rate or auth detail beyond payment.

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 tightly packed sentences that front-load the core question, then the return value, then cost and freshness. No filler; every clause adds 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?

For a single-parameter tool with no output schema, the description explains what is returned (registrations and verified domains) and the cost/freshness context. It stops short of describing the output shape or behavior when the company is not authorized, but 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 description coverage is 100% (the cnpj parameter is already documented as 14-digit or 8-digit root). The description only implies the CNPJ input via 'Brazilian company' and adds no syntax or format beyond 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 states a specific check — whether a Brazilian company is a Central Bank-authorized financial institution — with the enumerated categories (bank, credit union, consortium). This clearly separates it from the generic CNPJ lookup siblings like cnpj_consultar_empresa without needing to open either schema.

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

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

The anti-phishing emphasis and 'authorized financial institution' framing imply the use case (verifying legitimacy/domains), but there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling tools. Usage is inferred rather than 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, the description carries the full burden and does disclose important behavior: it requires payment ($0.09 in USDC via x402), gives a cost comparison, and notes a free sample endpoint. A return shape hint ('keyed by family and name') is also given. It does not describe failure modes or what happens if a paid call fails, so it is good but not exhaustive.

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?

One dense sentence that front-loads the scope (13 parameter-free endpoints) before cost and sample details. Every clause earns its place, though the parenthetical category list is slightly packed.

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

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

For a zero-parameter bundle with no output schema and no annotations, the description supplies scope, the covered families, pricing/auth context, and a free preview endpoint. An agent has enough to decide and invoke, with only the exact response schema left unspecified.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. It usefully references the endpoint path (/v1/pacotes/brasil) as the identity of the call.

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

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

States a specific resource (a bundle of the 13 parameter-free Brazilayer endpoints) and enumerates the covered families (commodities, market, fund flows, tax calendar, deforestation, tenders). It implicitly distinguishes itself from family-specific siblings like mercado_pacote and commodities_pacote by claiming the full cross-family set, though it never names those siblings to make the contrast explicit.

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?

Gives a clear reason to prefer this call (43% cheaper, one call instead of 13) and points to a free list at /v1/pacotes/amostra, which implies usage context. However, it never states when to use this bundle versus the sibling packages (mercado_pacote, commodities_pacote) or when a single endpoint is preferable, leaving selection to inference.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the result is deterministic with rules, thresholds and limits included, and that invocation costs $0.05 in USDC via x402 (a real behavioral constraint), but it says nothing about error modes, latency, or the shape of the response.

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

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

Front-loaded with the core framing and then the chain list; the enumeration is dense but every item carries distinct selection value. No filler or restated title.

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 no output schema, the description covers what the output contains, what distinguishes it from measurement tools, and the payment cost. It is close to complete, lacking only return-format and failure guidance.

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

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

Schema description coverage is 0%, but the enum already lists the valid values. The description compensates by unpacking what each enum value means (energia_br = rain → reservoirs → thermal dispatch, cafe_kc = frost/drought → coffee crop, etc.), which is genuine meaning beyond the schema.

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

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

The description states a specific resource (a causal chain behind a Brazilian risk) and explicitly contrasts it with what it is not ('not a measurement but the chain behind it'), which separates it from sibling indicator/sample tools. It enumerates the four available chains and names the components returned (upstream indicator with lead time, state, consequence, deterministic reading).

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

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

Usage is implied by the 'not a measurement but the chain behind it' framing and the risk-topic enumeration (energia, cafe, soja, capital), but there is no explicit when-to-use / when-not guidance and no named alternative among the many siblings such as cadeia_obter_amostra or mercado_indicadores.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this returns sample data vs real data, whether it is read-only, the format of the response, or any limits. 'Free' implies no cost but nothing more is disclosed about behavior.

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

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

The description is extremely short (single clause), which is efficient, but it borders on under-specification rather than conciseness. It front-loads the main idea but sacrifices clarity for brevity.

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 0 parameters, no annotations, no output schema, and a minimal description, the tool provides very little guidance to an agent. Given it returns a sample of complex data (a 'causal chain with reading and rule'), the description should explain what the sample is, how it relates to cadeia_causal, and what the user can expect from the sample.

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?

There are 0 parameters and schema coverage is 100%, so there is nothing for the description to add. Per the rubric, 0 params earns a baseline of 4, which is appropriate here since there are no ambiguity or undocumented parameters to resolve.

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 'A complete chain with its reading and rule, free.' is vague. It references 'chain', 'reading', and 'rule' which suggests this is a sample of a causal chain dataset, but it does not clearly state what 'cadeia_obter_amostra' (get sample chain) does, nor does it use a clear verb+resource structure. It distinguishes poorly from sibling 'cadeia_causal' which likely returns the actual chain data.

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

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

No clear guidance on when to use this tool. The context suggests it provides a free sample, which could be useful for preview/testing, but the description does not state this explicitly or compare against alternatives like cadeia_causal. The 'free' qualifier hints at a demo purpose but is too implicit.

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

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

With no annotations, the description carries the full burden and does disclose two non-obvious traits: the accent-insensitive full-text behavior and the $0.01 USDC x402 cost, which is critical for an agent to know before invoking. It omits return shape and pagination behavior, but the cost and semantics disclosure is substantive.

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

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

Front-loaded with the resource and filter list, followed by the constraint and cost in short clauses. Dense but every clause carries information; only minor cost is the long single sentence for the filter enumeration.

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 an 11-parameter search tool with no annotations and no output schema, the description covers most filter dimensions and the cost, but omits pagination controls (pagina, por_pagina) and any indication of what the response looks like. Adequate but with clear gaps 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 coverage is moderate (64%). The description adds meaning beyond the schema for several filters: 'accent-insensitive' for nome, 'city code' for municipio, 'newly registered companies' for the abertura window, and 'VC/PE fund in the ownership, a proxy for venture-backed startups' for com_investidor. It leaves situacao, pagina, and por_pagina undocumented, but the added semantics are real.

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

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

States a specific verb (search) plus resource (CNPJ registry) and enumerates the filter dimensions, making it clearly distinct from single-entity siblings like cnpj_consultar_empresa or relationship tools like cnpj_buscar_por_socio. An agent can tell this is the multi-filter discovery endpoint without opening the schema.

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

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

Gives a hard constraint ('At least one filter required') and hints at use cases (fresh leads, venture-backed startups), which implies discovery/browsing usage. However, it never explicitly contrasts with the sibling lookup tools (cnpj_consultar_empresa, cnpj_consultar_empresa_completo) or explains when a name search is preferable to those.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds context with the cost disclosure ('Costs $0.10 in USDC via x402'), which is genuinely useful behavioral/practical information beyond the schema. However, it doesn't disclose return format, pagination behavior, matching semantics (exact vs fuzzy name matching), or whether partial matches are returned. For a tool with zero annotation coverage, this is a meaningful but not complete set of disclosures.

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, both substantive and zero wasted words. The purpose statement is front-loaded, and the cost detail earns its place as actionable operational info. Could slightly improve by noting the pagination parameters in the description, but overall it's efficient and well-structured.

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

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

For a reverse-lookup query tool with no annotations and no output schema, the description communicates the core function and pricing but omits details a caller would likely want: response shape, whether results include company identifiers, pagination semantics, and potential ambiguity when multiple entities share the same name. It's functional and covers the essentials, but for a due-diligence tool the missing return-format detail is a real gap.

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

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

Schema description coverage is only 33% (only 'nome' has a description, though it's minimal: 'person or entity name'). The two undocumented parameters 'pagina' and 'por_pagina' are pagination controls whose behavior is implied by their names but not explained in either the schema or the description. The description's 'by name' clarifies the 'nome' parameter's role as the matching key, adding modest value. Given low coverage, the description should compensate more but does offer some confirmation of the primary parameter'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 the verb ('Find') and resource ('every Brazilian company where a person or entity appears as partner/shareholder') with the lookup key ('by name'). The title adds a helpful conceptual framing ('Reverse lookup') and the 'due-diligence query' phrase signals its investigative use case. It distinguishes well from siblings like cnpj_listar_socios (which lists partners for a company, the forward direction) and cnpj_buscar_empresas.

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 'due-diligence query' label implies an investigative/screening context, and the reverse-lookup concept distinguishes it from cnpj_listar_socios. However, there's no explicit statement of when to use it vs alternatives, no excluded scenarios, and no mention of required inputs or conditions. The guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the transparency burden. It discloses that responses are in Portuguese and that there is a monetary cost, which is genuinely useful. It does not disclose pagination, error behavior for invalid CNPJs, or whether the result is partial versus comprehensive (which appears to be a distinct 'completo' tool). The cost disclosure adds value but significant behavioral details remain undisclosed.

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 zero wasted words. It front-loads the core function, lists key data fields, and adds high-value operational details (cost, language of responses) economically.

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 lookup tool with a clear purpose, the description is reasonably complete. However, given the crowded sibling space with a 'completo' variant, listing socios, and searching tools, it would benefit from distinguishing its scope (basic registration data vs. comprehensive), especially since no output schema exists to clarify what fields are returned.

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 cnpj parameter, which already documents '14 digits, with or without punctuation'. The description adds no additional parameter-level detail beyond confirming it is a CNPJ lookup. Baseline 3 is appropriate since the schema fully documents the parameter and the description doesn't need to compensate.

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 title and description clearly state the primary function: looking up a Brazilian company by CNPJ from the Receita Federal registry. The description lists specific data categories (legal name, status, CNAE activities, address, tax regime) and differentiates the scope. However, among many cnpj_* siblings (cnpj_consultar_empresa_completo, cnpj_listar_socios, cnpj_buscar_empresas), the description doesn't explicitly distinguish this base-consult from the 'completo' variant.

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 fetching official registration data for a known CNPJ. The cost ($0.005 USDC via x402) and Portuguese response format are useful context signals. However, it doesn't explicitly state when to prefer this over cnpj_consultar_empresa_completo or other sibling tools, nor give alternative guidance when the CNPJ is unknown.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It honestly discloses the cost model ('Costs $0.01 in USDC via x402'), which is non-obvious behavioral state. It also clarifies the scope of what's returned (registration, partners, branches). However, it doesn't detail side effects, rate limits, or whether multiple API calls behind the scenes, but the cost transparency is meaningful added value.

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 zero wasted words. It front-loads the purpose, then adds the key distinguishing details (cost, value proposition). Every word earns its place.

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

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

For a single-parameter tool with no output schema, the description is reasonably complete. It explains what the user gets (registration data, partners, branches) and the pricing. It could note whether output is paginated or structured, but given the simplicity of input and the clear scope statement, this 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?

Schema description coverage is 100% for the single parameter (cnpj), so the schema already documents the input fully. The description adds no additional parameter meaning beyond what the schema provides (CNPJ format is already in the schema with '14 digits, with or without punctuation'). Baseline 3 is appropriate since the schema does the heavy lifting and the description doesn't need to add more.

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

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

The description states a specific verb+resource ('Complete bundle in one call: registration data, all partners and all branches'). It clearly distinguishes itself from sibling tools like cnpj_consultar_empresa (basic query) and cnpj_listar_socios (partners only) by emphasizing the comprehensive scope. The title 'Full Brazilian company profile (registration + partners + branches)' reinforces this distinction.

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

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

The description communicates that this is a full-profile tool ('Best value for a full profile'), implying its use case versus narrower siblings. While it doesn't explicitly name alternative tools or state when NOT to use it, the 'complete bundle' framing and mention of cost suggest its premium role. It lacks explicit exclusion guidance but the context is reasonably 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 discloses the cost/payment mechanism via x402, which is genuinely useful behavioral context beyond annotations. However, with zero annotations provided, the description carries the full disclosure burden and fails to mention whether the tax id is always masked (vs. conditionally), rate limits, pagination behavior for companies with many partners, or any response format details.

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

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

Two sentences, zero filler. The description front-loads what the tool returns and appends the pricing note. It is appropriately sized for a single-parameter tool with no output schema.

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

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

For a simple single-param list tool, the description covers purpose, output fields, and cost. However, with no output schema and no annotations, the agent lacks information about pagination for large partner sets, whether the masked tax ID format is standardized, and whether partial data failures can occur. Somewhat complete but with notable 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%, and the single cnpj parameter is already described in the schema as 'CNPJ, 14 digits, with or without punctuation'. The description adds no additional meaning about the parameter beyond what the schema already documents, 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 lists partners/shareholders (socios) of a Brazilian company, with specific output fields (role, masked tax id, entry date). It uses a specific verb+resource construction distinguishing it methodologically from siblings like cnpj_consultar_empresa or cnpj_buscar_por_socio, though it doesn't explicitly name the differentiating sibling.

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 cost ($0.005 in USDC via x402), which is a useful context signal. However, it does not provide any when-to-use vs. alternative guidance — e.g., when to prefer cnpj_listar_socios over cnpj_consultar_empresa_completo, or what prerequisites apply. No exclusions or conditions 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?

No annotations are provided, so the description carries the transparency burden. The description discloses that it's free and returns a sample profile, which covers the payment-related behavioral concern. However, it doesn't disclose specifics like whether the returned data is fictional/real, how large the response is, or whether any fields are representative vs. actual. For a zero-parameter sample tool this is adequate but not rich.

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 with zero wasted words. It states what it does, that it's free, and how to use it (to learn the format). Highly efficient and front-loaded.

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

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

For a zero-parameter sample tool with no output schema, the description adequately covers purpose and usage. It could potentially note that this is a representative/curated sample rather than a live query result, but given the simplicity and self-explanatory nature of a sample endpoint, the description is sufficiently complete. The sibling naming pattern (many _obter_amostra variants) reinforces a consistent, understood 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?

There are zero parameters, and schema coverage is 100% (vacuously, since there's nothing to cover). The description appropriately doesn't need to explain any parameters because there are none. The baseline of 4 for zero-parameter tools applies here, and the description adds the payment/free context which helps set expectations for the interaction.

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

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

The description clearly states the tool returns a free sample company profile, with the specific verb 'obter' (get) plus resource 'amostra' (sample). It distinguishes itself from its sibling 'cnpj_consultar_empresa' by explicitly positioning it as a free sample for learning the response format rather than a paid query tool. However, it doesn't explicitly contrast against all the CNPJ siblings or clarify exactly what data the sample contains.

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

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

The description gives clear usage context: 'Use it to learn the response format before paying for other tools.' This implicitly tells the agent to invoke this when a user wants to see the output format or test the CNPJ service without cost. It doesn't name alternative tools explicitly, but the 'before paying for other tools' phrase clearly signals this is a precursor/demo tool and not for real queries.

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

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

With no annotations, the description carries the full burden and does well: it discloses the payment model ($0.001 USDC via x402), its position as the cheapest paid check, and the exact payload fields (status, date, branch flag, state). It omits rate limits, auth beyond payment, and result formatting, so not a 5.

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

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

Three tight sentences, front-loaded with the core purpose and return fields, then the cost, then the rationale. Every sentence earns its place with no filler.

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

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

Given no output schema and no annotations, the description adequately covers what the agent gets back (existence + status + date + branch flag + state) plus the payment cost. Only the exact response format is unspecified, which is minor for a simple existence check.

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?

Single parameter with 100% schema coverage, so the schema already documents the CNPJ format ('14 digits, with or without punctuation'). The description adds no additional syntax or validation guidance beyond what the schema provides, so the 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?

States a specific verb (Checks) and resource (CNPJ against the official Receita Federal registry) and enumerates exactly what it returns: existence, status (Ativa/Suspensa/Baixada), date, HQ/branch flag and state. It is differentiated from the fuller siblings (cnpj_consultar_empresa_completo, cnpj_consultar_empresa) by its lightweight scope, though no sibling is named explicitly.

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 closing line ('Digit validation alone cannot tell a well-formed number from a real, active company') implies when to reach for it — real-world verification rather than format checking. But it never names the alternatives (cnpj_consultar_empresa, cnpj_consultar_empresa_completo) or states when to prefer the fuller tools, leaving routing to inference.

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

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

No annotations are provided, so the description bears the full burden. It discloses the payment cost ($0.10 USDC via x402), which is genuinely valuable, but omits whether the briefing is fresh/live or cached, whether it requires an API key or wallet setup, rate limits, and what the response contains. For an AI-synthesized aggregation with no annotations and no output schema, this is thin.

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

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

A single front-loaded sentence covering content scope, followed by a short cost sentence. Efficient, though the commodity list is dense; nothing is wasted.

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

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

For a no-param, no-output-schema, no-annotation aggregation tool, the description should disclose freshness, delivery/auth mechanics, and what the returned briefing actually contains. It touches cost but leaves the operational picture incomplete.

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

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

Zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument tool by describing a fixed, comprehensive briefing rather than any filterable fields.

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

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

The description names the specific resource (a synthesized Brazilian commodity briefing covering coffee, sugar, soybeans, corn, OJ, cotton, cattle), the scope (weather, fire, exports, hydro, FX, headlines), and the 'what changed today' temporal frame. An agent can distinguish this composite briefing from granular siblings like commodities_clima, commodities_fogo, or mercado_noticias.

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 states what is included and the cost, but does not indicate when to choose this composite briefing over the granular commodity tools (clima, fogo, exportacoes) or when not to. Usage is implied by 'condensed' rather than 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 the transparency burden. It discloses that data is updated twice daily, includes forecast + observed data, covers 72h frost risk, and costs $0.005 via x402. It's a read tool with no destructive/state-changing implications, and the update cadence and cost disclosure add value. It doesn't describe the return format or how the 'stress' is quantified, which would further aid 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 a single, information-dense sentence that front-loads the core value (weather stress data), enumerates covered commodities, and appends practical logistics (update cadence, cost). Every clause earns its place. Slightly more could be said about output granularity, but there's no waste.

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

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

For a zero-parameter, read-only data retrieval tool with no output schema and no annotations, the description covers the essential scope: what commodities are covered, what data signals are included (rain, dry days, frost risk), temporal coverage (observed + forecast, 72h frost), and commercial terms ($0.005 via x402). It's essentially complete for the tool's simplicity; the only minor gap is specifying the geographic granularity of the belts.

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

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

The tool has zero parameters and 100% schema coverage (empty schema), so there are no parameter semantics to add beyond the description's coverage of what data is returned. Since parameter count is 0, the baseline is 4 per the rubric — the description appropriately explains what the tool returns without needing param-level detail.

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

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

The description clearly states the tool reports crop-weather stress (rain, dry days, frost risk) for Brazilian producing belts that price global commodities, listing the specific commodities covered. It uses specific verbs ('Observed + FORECAST') and a concrete resource (commodities/belts), distinguishing it well from sibling commodity tools like commodities_fogo or commodities_briefing.

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 it covers specific commodities (coffee, soybeans, sugar, corn, orange, cocoa) which helps scope when to use it, but it doesn't explicitly say when NOT to use it or name alternative tools (e.g., commodities_hidrologia for hydrology, commodities_fogo for fire). The scoping by commodity list implicitly guides usage but lacks explicit exclusions or 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 the full burden. It does disclose the cost ($0.005 USDC via x402), which is useful, but doesn't disclose what time period the data covers, whether the data is current/lagged, how many years of history, language of output, or response format. The description mentions 'year-over-year change' which hints at time-series but doesn't confirm.

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, both substantive. Lists all commodities in one sentence and discloses cost in the second. No wasted words. Slightly dense commodity list could be seen as a trade-off, but it's necessary information packed efficiently.

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 parameterless tool with no output schema, the description should carry more weight. It covers what data is included and the cost, but doesn't state the time range of the data, whether results are monthly-aggregated or include detailed records, or the output format. An agent can't tell if this returns raw data or a summary report, or how far back history goes.

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

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

Zero parameters, so no parameter documentation is needed. Schema coverage is 100% (empty schema). The description compensated by listing the specific commodities covered, which is the meaningful 'parameter-like' information an agent would need. Nothing more is required for a parameterless tool.

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

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

Clear verb+resource: 'Monthly export volumes and FOB' for specific commodities (soybeans, corn, coffee, sugar, beef, chicken, cotton, pulp). Distinguishes from sibling tools like commodities_clima, commodities_fogo, commodities_hidrologia which are weather-focused, and commodities_briefing which is a summary. Could be improved by clarifying the geographic scope more explicitly, though 'Brazilian' is in the title.

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 guidance on when to use this tool vs alternatives. The description doesn't explain how it differs from commodities_briefing or commodities_obter_amostra, nor when a user should prefer this export-data tool over other commodity tools. No exclusions or alternatives mentioned in the description text.

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

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

With no annotations, the description carries the full burden. It does disclose a genuinely useful behavioral trait — the $0.002 USDC x402 payment cost — plus a daily update cadence, but says nothing about response shape, geographic granularity, historical depth, 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?

Two tight sentences, with the core capability front-loaded and the commercial detail last. Nothing is wasted, though the ESG/carbon framing is closer to marketing than operational guidance.

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

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

For a zero-parameter tool with no output schema or annotations, the description covers the data content, its segmentation (biome/state), the derived fields, the cadence, and the cost. The remaining gap is that return format and historical coverage are unspecified, but an agent has enough to call it correctly.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description appropriately spends its words on the output dimensions instead.

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

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

States a specific resource (daily fire hotspots) with the output dimensions (by biome and state, intensity, drought proxy), which is far more than a restatement of the name. It doesn't explicitly differentiate from siblings like commodities_clima or desmatamento_ranking, so it falls short of a 5.

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

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

The phrase 'ESG, carbon and ag supply-chain signal' implies the use case, but there is no explicit when-to-use guidance or routing against adjacent tools such as commodities_clima, commodities_hidrologia or desmatamento_fornecedor. Usage is inferable but not 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, the description carries the full burden, and it does disclose a meaningful trait the structured fields cannot: a $0.002 USDC x402 payment requirement. It still omits update timing beyond 'daily', rate limits, and whether the cost is per call or per period, so behavioral coverage is partial.

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

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

A single compact sentence front-loads the metric, granularity, and source, then appends the payment note. No filler and nothing buried.

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

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

For a zero-parameter data tool with no annotations and no output schema, the description covers metric definition, cadence, subsystem granularity, source, and cost — enough to call it correctly. Return shape and freshness lag are the only real gaps, and they are minor.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; baseline 4 applies. The description correctly avoids inventing inputs.

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

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

States a specific resource (daily EAR percent per grid subsystem with 7-day delta) and its provenance (official grid operator). This distinguishes it from generic market siblings like commodities_clima or mercado_indicadores, though it never names those siblings explicitly.

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

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

The phrase 'power-price and drought gauge' implies the intended analytical use case, but there is no explicit when-to-use statement and no routing against the many commodities_* and *_obter_amostra siblings. Usage is only inferable.

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. The description tells the user what they get (belt weather, fires, briefing excerpt) which is some behavioral transparency, but it doesn't disclose what happens on invocation, whether there are rate limits, whether output is truncated, or how this relates to the full dataset tools. For a sample tool, one might expect disclosure that outputs are partial or sample-only.

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 short sentence, front-loaded with the key concept ('A taste of each block'), and wastes no words. The title and description work together compactly. It's concise and efficient, though slightly casual in tone.

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

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

For a zero-parameter, no-output-schema sample tool, the description is largely adequate. The tool is simple enough that the description covers the essential purpose. However, it could benefit from clarifying exactly what 'belt weather, fires, briefing excerpt' refers to (which specific blocks of the Commodity Signals dataset) and how the sample differs from the full dataset obtainable through sibling tools. The informal style ('A taste', 'Free') is acceptable but could be more precise.

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

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

The tool has 0 parameters with 100% schema coverage (empty schema), so there's nothing to explain about parameters. Zero-parameter tools get a baseline of 4 since there's no parameter burden to carry. The description appropriately doesn't add fake parameter information.

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 provides a free sample of a dataset ('A taste of each block: belt weather, fires, briefing excerpt'), which distinguishes it as a sampler tool. However, the title and description are somewhat redundant, and while it's clear it's a sample tool matching the pattern of other *_obter_amostra siblings, the specific mention of 'belt weather, fires, briefing excerpt' shows what's inside. It does differentiate itself from the data-specific commodity tools by being a sampler, but the connection to the specific dataset is implicit.

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 this is for trying out the dataset before using specific tools like commodities_clima, commodities_fogo, or commodities_briefing. However, it doesn't explicitly state when to use this versus alternatives, nor does it name specific sibling tools as alternatives. The 'Free' emphasis implies low-risk trial usage, but no explicit when-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?

With no annotations, the description carries the whole burden, and it does disclose two real behavioral traits: this is a paid call ($0.06 USDC via x402) and it degrades gracefully by listing unavailable components rather than failing outright. It does not cover retry/charge behavior, latency, or auth mechanics.

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?

One tight sentence: the returned payload is front-loaded, then the degradation key, then the cost rationale. Nothing is wasted.

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

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

No output schema exists, so the description correctly explains the response shape (named components) and the failure surface (`indisponiveis`). For a zero-param bundle that is close to sufficient, though it says nothing about what a component's contents look like or payment failure handling.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to compensate for. No param meaning 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?

States precisely what the tool returns — the five named components (clima, fogo, exportacoes, hidrologia, briefing) in one response, keyed by name. The 'one by one' cost comparison implicitly but clearly positions it against the individual sibling tools commodities_clima/fogo/exportacoes/hidrologia/briefing.

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 pricing comparison ($0.06 vs $0.114) gives a clear context for when to prefer this bundle over the individual sibling tools, and the description notes how partial failures surface via `indisponiveis`. It stops short of an explicit 'use only when you need 2+ components; otherwise call the single tool' rule.

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

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

With no annotations, the description carries the full burden and does well: it discloses that ratings are measured rather than declared, that the agent was run by its owner in a fixed x402 arena, that it is free, and how to interpret the NEW and REFERENCE flags and 404 responses. It omits rate limits or auth requirements, but as a public read lookup that is a minor gap.

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?

It is one dense paragraph, but it is front-loaded with the verb and resource, then the returned fields, then the practical rules and the testing link. The long enumeration of output fields earns its place given no output schema, though the text is somewhat run-on.

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 no output schema, the description usefully enumerates return values (tier scale, score range, runs, flags, per-scenario pass counts, honest-task rate) and edge cases (404, NEW, REFERENCE). The main missing element is disambiguation from the sibling trust_check and skill_check rating tools.

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

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

Schema description coverage is 100% and the single slug parameter is already documented with format and an example in the schema. The description repeats the lowercase-with-dashes convention and example (hermes-agent), adding no new semantics. 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 states a specific verb and resource — reading the Agent Economy Report conduct rating of an agent/framework by slug — and enumerates the returned fields (tier, score, runs, flags, per-scenario pass counts). It does not, however, distinguish itself from the sibling tools trust_check and skill_check, so an agent cannot tell from the text alone which rating tool applies.

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

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

It gives clear operational guidance: it is free, check before delegating, and 404 means never tested so treat as unknown. It also instructs how to interpret the REFERENCE flag (never rank it). It stops short of naming when to prefer this over the sibling trust_check/skill_check tools.

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

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

With no annotations present, the description carries the full burden and mostly meets it: it discloses that risk is applied only to exposed sectors, that the signal is geographic rather than plot-level ('the registered address is not the production plot'), and that invocation costs $0.02 USDC via x402. Missing are any notes on error behavior or how sparse data is handled, which keeps this below 5.

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

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

Three sentences, front-loaded with the core CNPJ-to-clearing mechanism, followed by the interpretation caveat and the payment cost. Each sentence adds distinct information, though the payment detail at the end could arguably be folded in more tightly.

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

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

For a one-parameter, no-annotation, no-output-schema lookup, the description supplies the domain context (EUDR cutoff, sector scoping), the interpretation limit, and the payment model an agent needs to call it responsibly. It leaves out the shape of the returned record, which would help given no output schema exists.

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?

There is a single parameter with 100% schema description coverage ('CNPJ, 14 digits, punctuation ok'), so the schema fully documents the input and the description adds no format or syntax meaning beyond it. Per the high-coverage baseline, a 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 a specific transformation: from a Brazilian CNPJ to satellite-detected clearing in the company's registered municipality since the EUDR cutoff. That is a clear verb+resource with scope qualifiers. It stops short of naming its closest sibling (desmatamento_municipio) to explicitly disambiguate the two.

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 frames the output as a 'regional indicator to prioritise due diligence', which tells the agent when and why to reach for it, and adds the crucial caveat that the registered address is not the production plot. No alternative tools are named and no exclusions are stated, so it is clear context rather than full routing guidance.

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

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

With no annotations, the description carries the full burden and does meaningful work: it names the data source (INPE DETER), the biomes covered, the regulatory framing (EUDR cutoff of 31 Dec 2020), the temporal windows, and an explicit cost of $0.01 USDC via x402. It does not cover rate limits, auth requirements beyond payment, or data latency, keeping it short of a 5.

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

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

Two sentences, front-loaded with the core resource and scope, with the cost detail placed last where it belongs. The second sentence is dense with comma-separated clauses but each carries distinct information, so it is efficient rather than padded.

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, no-output-schema tool, the description fully covers what is returned (area cleared, alert count, 30/90/365-day windows, class breakdown, ranking) and the cost model. Nothing an agent needs to decide to call it is missing.

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

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

Schema description coverage is 100% — the single 'ibge' parameter is already documented as a 7-digit IBGE municipality code. The description adds no format, validation, or lookup guidance beyond what the schema provides, so the 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?

States a specific resource (official INPE DETER satellite alerts for Amazon and Cerrado), a precise scope ('for one municipality'), and the metrics returned (area cleared, alert count, class breakdown, ranking). This clearly separates it from siblings like desmatamento_ranking and desmatamento_fornecedor without needing to open any schema.

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

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

The phrase 'for one municipality' implies the single-municipality use case versus the multi-municipality ranking sibling, but there is no explicit when-to-use guidance, no stated prerequisites (e.g. valid IBGE code lookup), and no named alternatives. Usage is inferable but not directed.

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 reveals this is a sample/preview (free, limited scope to national totals and worst municipality) which is useful transparency. However, it doesn't disclose return format, whether data is a subset or aggregate-only, or any limitations beyond being 'free'.

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, zero wasted words. The word 'Free' is front-loaded as the title indicator and the content scope is clearly stated. Highly concise and structured well.

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

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

For a zero-parameter sample tool with no output schema, the description is moderately complete — it signals the scope (national totals by biome, worst municipality) and the free/sample nature. But given there are sibling desmatamento tools that are more capable, it could better clarify what this sample is and isn't, since the sample tools across domains follow a consistent 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?

There are 0 parameters with 100% schema coverage, so per the rubric baseline for 0 params is 4. The description doesn't need to document parameters since none exist. Nothing to fault here.

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 the tool provides 'National totals by biome and the worst-affected municipality' as a free sample of the Deforestation dataset. This gives a specific verb+resource combination and differentiates it from other desmatamento tools. However, it's brief and doesn't clearly relate to its sibling sample tools (desmatamento has no direct naming conflict but other domains have *_obter_amostra siblings).

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

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

No guidance on when to use this vs alternative desmatamento tools like desmatamento_municipio, desmatamento_fornecedor, or desmatamento_ranking. The word 'Free' implies it's a lite/preview version but doesn't explain why one would pick this over the fuller tools. No exclusions or alternatives named.

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 burden. It discloses data origin (official INPE alerts) and pricing (USDC via x402), which is useful. However, it doesn't state edge behaviors like what happens with required parameter defaults, whether both por values are mandatory, or pagination/return format behavior — a mild gap for a ranking tool.

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

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

Two tight sentences, front-loaded with action then scope, then data source and cost. Zero waste — every clause carries meaning.

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 filtering/ranking tool with no output schema and zero schema coverage, this is reasonably complete: purpose, dimensions, filter options, data origin, and cost are all covered. Remaining gaps are parameter defaults and return-format details, but the core decision-making info is present for an agent.

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

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

Schema coverage is 0%, so the description must compensate. It explains the meaning behind 'por' (municipios or states) and 'bioma' (Amazon or Cerrado), which maps two of the four params. However, 'dias' (window length, max 2000) and 'limite' (max 50) are conceptually referenced but not explicitly annotated in prose.

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?

Specific verb (rank) + resource (municipalities/states by area cleared) + clear scope (within a time window, filterable by biome). It clearly distinguishes from siblings like desmatamento_municipio (per-municipality detail) and desmatamento_fornecedor (supplier-focused) by emphasizing the ranking orientation.

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?

States the ranking/filtering capabilities (by municipality or state, biome filter) and names the data source (INPE). The $0.01 cost note is useful context. However, it doesn't explicitly mention when NOT to use this vs desmatamento_municipio or desmatamento_fornecedor, leaving some decision ambiguity.

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

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

No annotations are provided, so the description carries the burden. It transparently discloses the cost ($0.05 USDC via x402) and payment mechanism, which is valuable behavioral context. However, it doesn't mention rate limits, whether results include raw vs processed data, or what happens on sanctions hits (does it block or just report?). Key pricing transparency is a plus but other behavioral traits are sparse.

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 crisp sentences, zero waste. The first sentence front-loads the full scope with a colon-delimited enumeration of the 5 data domains, and the second establishes value (replaces 5 calls) and cost. Every word earns its place.

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

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

The description thoroughly covers what data is included, the pricing model, and its relationship to single-purpose tools. There's no output schema, so return format isn't guaranteed, but for a bundle tool this is acceptable. It could note whether the sanctions/branch/contract results are combined or returned separately, but the completeness is strong for a single-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 the single 'cnpj' parameter is fully documented in the schema (14 digits, with/without punctuation). The description adds no further parameter detail beyond what the schema provides, which is acceptable given the high coverage baseline of 3 for a single simple 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 verb+resource: it's a 'full KYB profile of a Brazilian company' enrichment bundle. It enumerates the exact data sources included (registration, partners, branches, sanctions, Central Bank, contracts) and explicitly distinguishes it from 5 separate lookups, differentiating it from sibling tools like cnpj_consultar_empresa_completo and integridade_consultar.

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 says it 'replaces 5 separate lookups' and implies it's a one-call comprehensive bundle for KYB workflows. It positions this as the consolidated choice versus the individual sibling tools, but doesn't explicitly state when NOT to use it (e.g., when only a single field is needed, where a targeted lookup might be cheaper/faster) or mention alternatives by 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 present, the description carries the full burden and does so well: it names the authoritative source (CVM portfolio disclosure / CDA), discloses the up-to-90-day legal disclosure lag, warns that funds with no equities are absent, and states the payment requirement ($0.01 USDC via x402). Cost, data provenance, and coverage gaps are exactly the traits an agent needs before invoking.

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

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

Front-loads what the tool returns, then appends the three constraints that affect interpretation (source, lag, empty-fund behavior) plus the cost. Every clause earns its place; no filler.

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

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

For a single-parameter, no-output-schema, no-annotation tool, the description covers everything needed to call it correctly and interpret results: source authority, disclosure lag, empty-result conditions, and payment cost.

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

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

Schema description coverage is 100% and the single cnpj parameter is documented in the schema itself, so the baseline is 3. The description adds the per-fund scoping context but nothing about CNPJ format beyond what the schema already states.

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

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

States a specific verb+resource+scope: 'Every stock/BDR a fund holds in its latest disclosed month', and enumerates the returned fields (ticker, quantity, market value, buy/sell). This is clearly distinguishable from siblings like fundos_fluxos or fundos_movimentacoes, which cover flows rather than holdings.

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 useful context for when results are meaningful (per-fund, lagged up to 90 days, funds with no equities do not appear), which implicitly tells the agent when to expect empty results. However, it never names an alternative tool or states when to prefer fundos_fluxos/fundos_movimentacoes over this one, so routing guidance is only implied.

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 behavioral burden. It discloses the data source (CVM filings), scope (~25,000 fund classes), and pricing ($0.005 in USDC via x402), which is useful behavioral context. However, it doesn't describe return format, pagination, or what happens with the single 'dias' parameter's 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 compact (two sentences plus pricing) and front-loaded with the core purpose. The 'Emerging-market smart-money netflow' phrase is slightly redundant marketing framing, but the description is efficient overall with no wasted content.

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

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

For a single-parameter filter tool with no output schema, the description adequately conveys the domain, source, and scale. Gaps exist: no mention of what the response looks like (since there's no output schema), and 'dias' semantics are only implied, not stated. It's adequate but not rich, consistent with a minimal single-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 description coverage is 0% and there is only one parameter ('dias', integer 1-60). The description does not explain what 'dias' controls beyond what the schema annotations (min/max) already imply about a time window. It doesn't clarify whether this is the number of days of history to fetch. Baseline 3 is appropriate given the schema constraints partially self-document the 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 reports daily net fund flows (subscriptions minus redemptions) by fund class in the Brazilian fund industry, sourced from official CVM filings. It names the specific resource (daily net flows across ~25,000 fund classes) and is distinct from siblings like fundos_ranking, which presumably ranks funds rather than reporting flows.

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 when-to-use guidance or alternatives are mentioned. The description has a marketing-style framing ('Emerging-market smart-money netflow') that hints at use cases but provides no exclusions or comparison to fundos_verificar, fundos_ranking, or other fund tools. The x402 cost note is useful but isn't usage 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 present, so the description carries the full burden. It usefully discloses the data provenance (CVM CDA) and the x402 payment cost of $0.02 USDC, which an agent must know before calling. It does not cover return shape, pagination, or latency, leaving gaps for a zero-annotation 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?

A single dense sentence front-loads the core concept (institutional net flow per ticker) before the source and cost clause. Nothing is redundant, though the packed phrasing makes the payment detail easy to miss.

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 no output schema and no annotations, the description should explain the return shape, but it only says 'how much funds bought and sold.' The undocumented limite parameter and unspecified response fields leave the definition only marginally complete for a two-parameter data 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 only 50%: competencia is documented in the schema (YYYY-MM, default latest consolidated) and the description merely restates that default. The limite parameter has no description anywhere and the description never mentions it, so an agent cannot tell whether it caps tickers or funds.

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

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

States a specific resource and scope: net institutional flow per Brazilian stock ticker, sourced from official CVM portfolio disclosure. An agent can tell it returns buy/sell totals per ticker. However it does not differentiate from the sibling fundos_fluxos, which by name sounds closely related, so a 4 rather than 5.

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

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

The description implies the data is month-scoped ('for the latest consolidated month') but gives no explicit when-to-use guidance, no prerequisites, and never names fundos_fluxos, fundos_carteira, or fundos_ranking as the alternative for a different need. Usage must be inferred entirely.

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 behavioral burden. The description is minimal and doesn't disclose what 'sample' means operationally (e.g., how much data, whether it's read-only, whether it costs money, response format). 'Free' hints at monetization model for other tools but doesn't clarify the behavior of this call. Given zero annotation coverage, this is a significant gap.

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

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

The description is extremely concise—two short sentences plus a terse 'Free.'—with zero waste. It's front-loaded with the key value proposition (sample of Fund Industry data). However, 'Free.' as a trailing fragment is more of a marketing tag than informative structure, and the brevity borders on under-specification.

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 0-parameter, no-output-schema tool, the description should clarify what the sample contains and how to interpret it. It mentions 'daily flows by class' and 'a real registered fund,' which is helpful, but doesn't explain the purpose of a sample (preview vs. production), data volume, or relationship to sibling fundos_* tools. Companion tools like cnpj_obter_amostra and various *_obter_amostra follow the same pattern, suggesting samples are a recognizable pattern, but the description could still clarify usage context.

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

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

The tool has 0 parameters and 100% schema coverage (empty params object), so there's nothing to document. Per the rubric, 0 params = baseline 4. The description correctly implies no inputs are needed, which is consistent.

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 provides a 'Free sample of the Fund Industry dataset' with 'Latest daily flows by class plus a real registered fund.' The verb is implicit but the resource (Fund Industry sample) and content (flows, fund) are described. However, it doesn't clearly distinguish from sibling tools like fundos_fluxos (which likely provides flows directly) or fundos_verificar, so differentiation is weak.

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 when-to-use or when-not-to-use guidance is given. The title says 'Free sample' which implies it's for previewing data before committing to a paid tool, but this is only implied. It doesn't mention alternatives like fundos_fluxos, fundos_verificar, or fundos_ranking, nor does it state when the sample is appropriate versus the full tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The only behavioral trait disclosed is the $0.01 USDC cost via x402, which is useful. However, there's no mention of pagination behavior, rate limits, output format, or whether this is a read-only operation. For a data-access tool with zero annotation coverage, this is a significant gap.

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 fluff. The first sentence carries the core purpose and the second adds the cost detail. Efficient and 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?

With 4 parameters, 0% schema coverage, no output schema, and no annotations, the tool has many dimensions to compensate for. The description addresses the ranking-criteria dimension and the cost, but leaves 'dias' and 'limite' semantically unexplained, doesn't describe the returned data structure, and doesn't clarify whether all parameters are optional and what defaults apply. For a filtering/ranking tool, this is under-specified.

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

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

Schema description coverage is 0%, so the description must compensate for the 4 undocumented parameters. It maps 'por' to the three ranking criteria (net assets, net inflows, shareholder count) and 'classificacao' to fund classes, which helps. However, 'dias' and 'limite' get no semantic explanation, and the mapping leaves ambiguity (e.g., exact Portuguese enum values vs English 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 states the tool ranks funds by three criteria (net assets, net inflows, shareholder count) with filters by class, from a specific data source (official CVM). The verb 'Rank' plus the resource 'funds' is specific. It doesn't explicitly distinguish from sibling fund tools like 'fundos_fluxos' or 'fundos_verificar', but the ranking purpose is clear.

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 ('Rank funds... filterable by class') and mentions it uses official CVM data, giving context about data provenance. However, it provides no when/when-not guidance or alternatives for other fund tools in the sibling list, nor does it explain what ranking use-case would warrant this over 'fundos_fluxos'.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the return contents (manager, administrator, class, latest NAV, net assets, shareholders) and a genuinely important behavioral trait, the $0.005 USDC x402 payment cost. It omits what happens when the CNPJ is not a fund, and any rate-limit or retry behavior.

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

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

Front-loaded with the core question, then return contents, then the fraud-check framing and cost. Every clause earns its place with no filler; appropriately sized for a single-parameter 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?

With no output schema or annotations, the description steps in to enumerate return fields and cost, which is enough for an agent to call it correctly. It lacks coverage of the negative-result behavior and payment/auth mechanics beyond the price, leaving a small gap for a tool whose only output channel is the description.

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

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

Only one parameter (cnpj) with 100% schema description coverage ('14 digits, punctuation ok'), so the schema already does the semantic work. The description adds no format or syntax detail beyond what the schema provides, warranting the 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?

States a specific verb (verify) and resource (CNPJ as a fund registered/operating at CVM), framed as a direct yes/no question an agent can act on. This distinguishes it from bcb_verificar_instituicao (different regulator/entity type) and the generic cnpj_* tools without needing to open schemas.

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

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

Provides a clear use case — 'the check against fake-fund and Ponzi schemes' — which tells the agent when this tool is the right choice. It does not name explicit alternatives or when-not conditions (e.g., versus fundos_obter_amostra or bcb_verificar_instituicao), so it stops short of full routing guidance.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully discloses the output (matches with details and a clean-record flag), the update cadence (daily), and the cost ($0.01 in USDC via x402). It does not note potential side effects or failure modes, but the tool is a read-only screening call, so the disclosed output and cost are adequate behavioral 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?

Three sentences with zero waste. It names the resource and databases, states return values, discloses cost, and notes update frequency, all in tight, information-dense prose. Every sentence earns its place.

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

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

For a read-only screening tool with one fully-documented parameter, the description is quite complete: it names all databases checked, return format (matches + clean-record flag), update cadence, and pricing. No output schema exists, so the return-value description is helpful. Minor gap: no explicit caveat about what portion of matches constitutes a hit or how leniency agreements differ, but this is largely sufficient for a screening 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% and there is only one parameter (cnpj). The schema already documents the CNPJ format ('14 digits, with or without punctuation'). The description adds the meaning of what screening entails but doesn't add format or syntax details beyond the schema. Baseline 3 is appropriate when the schema fully documents the single 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 verb ('Screen a CNPJ') and the resource (official Brazilian government sanction lists), enumerating specific databases (CEIS, CNEP, CEPIM, slave-labor blacklist, leniency agreements). It is highly specific and clearly differentiates from siblings like cnpj_consultar_empresa and licitacoes tools, which focus on company records and procurement, not integrity sanctions.

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 establishes when to use this tool (screening a Brazilian company for sanctions/integrity) and notes it checks a specific set of government lists. It does not explicitly name alternatives or exclusions, but the 'in one call' phrasing and list of databases gives clear context that this is the go-to integrity screening tool among siblings, many of which are unrelated (commodities, funds, desmatamento).

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

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

With no annotations, the description carries the full burden. It clearly discloses the tool is free, returns a sample of a real sanctioned entity, and is educational in nature. It doesn't mention any rate limits or cost implications, but the 'free' disclosure is important and honestly conveys the tool's nature.

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, zero wasted words. Front-loaded with the key value proposition (free sample), and the second sentence clarifies the use case. Highly efficient.

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

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

For a zero-parameter, no-output-schema sample tool, the description is reasonably complete. It discloses cost (free), content (sanctioned company screening response), and purpose (learn format). However, it doesn't describe what the returned data looks like or its size, leaving some ambiguity about what the agent should do with the response.

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

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

The tool has 0 parameters, so schema coverage is 100% by default and there's no parameter information to add. The description doesn't need to document parameters that don't exist. Per the rubric, 0 params earns a baseline of 4, which is appropriate here.

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

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

The description clearly states it returns a free full sample screening response for a real sanctioned company. The purpose is specific (sample/trial content) and it distinguishes from siblings like integridade_consultar by being a free preview. Could be slightly better by naming the specific company or format, but the core purpose is clear.

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 (learn the format before paying), which gives context on when to use it, though it doesn't explicitly exclude alternatives or name sibling tools like cnpj_obter_amostra. The 'before paying' phrasing suggests it's a first-step/prelude tool. No explicit when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses the cost ($0.01 in USDC via x402) and notes it returns summary totals in addition to raw data, which adds value. However, it does not describe pagination, potential volume of results, rate-limiting, or what happens when no contracts exist for a CNPJ. The cost disclosure is useful transparency not present in structured fields.

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

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

The description is extremely compact — three sentences that deliver purpose, scope, data fields, positioning, and cost. No filler, no redundancy with the schema, and information is front-loaded with the primary purpose stated first.

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 a single parameter, no output schema, and no annotations, so the description must carry most informational weight. It covers data source, fields returned, summary totals, and value proposition. The missing elements are minor: output format/return shape and behavior when a CNPJ has no contracts. For a read-only data retrieval tool with one param, this is solid completeness.

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% (the cnpj parameter is described as 'CNPJ, 14 digits, with or without punctuation'), so the baseline is 3. The description adds meaningful value by confirming the parameter drives the query and specifying that it's 14 digits with flexible formatting, reinforcing format tolerance. With a single, well-documented parameter, the description's contribution is genuine but modest.

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 a specific verb+resource ('Every government contract won by a company (CNPJ)') with the data source (PNCP portal) and the specific fields returned (body, object, value, dates, summary totals). It also distinguishes itself from siblings by framing it as 'The B2G piece of due diligence,' separating it from the corporate data tools (empresa_*, cnpj_*) and other licitacoes tools.

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

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

The description implies usage context by labeling this as 'The B2G piece of due diligence,' which suggests it's for researching a company's government business activity. However, it does not explicitly state when to use this versus sibling tools like licitacoes_oportunidades_abertas (which logically deals with open opportunities rather than won contracts) or provide exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that this is a sample (not full data) and is free, which is useful. However, it doesn't clarify whether the output differs structurally from the real response, whether throttling/limits apply, or that no real procurement data is returned — the key behavioral caveat for an agent deciding to invoke this.

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, zero waste. Each sentence earns its place: the first states what it returns, the second states the purpose (learning). Efficient and 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?

The tool is simple (0 params, no output schema, no annotations), so the completeness burden is low. The description adequately conveys the tool's role as a free sample for learning the format. However, it doesn't clarify how the sample maps to sibling tools (which paid tool's format it samples) or whether the sample is representative of the full response structure.

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

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

The tool has 0 parameters and schema coverage is 100% (empty schema), so there is nothing for the description to add regarding parameters. Per the rubric, a 0-parameter tool gets a baseline of 4, and there are no parameter gaps to compensate for.

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 provides a 'Full sample supplier-contracts response, free' with the purpose of learning the format. However, the title 'licitacoes_obter_amostra' and description are generic and don't clearly distinguish from sibling sample tools like 'cnpj_obter_amostra' or 'integridade_obter_amostra' — though the mention of 'supplier-contracts' does position it within the licitacoes domain as distinct from other domain sample tools.

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

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

The description implies the tool is for learning the response format before paying for the full/paid version ('Learn the format before paying'). This conveys a clear context for when to use it — as a precursor to a paid call. However, it doesn't explicitly state when NOT to use it (e.g., when you need real data) or name the specific paid alternative among siblings like licitacoes_contratos_fornecedor.

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 data is live from the official source, lists what fields will be returned (object, estimated value, deadlines, bidding link), and notably discloses the $0.01 USDC cost via x402 — a significant behavioral trait the agent needs. Missing some aspects (rate limits, pagination behavior) but strong for a read tool.

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

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

Two sentences, zero wasted words. First sentence packs the core purpose and returns; second sentence covers filters and cost. Front-loaded and fully actionable with no filler.

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

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

For a filtered-list read tool with 4 optional params and no output schema, the description covers purpose, return fields, filters, and cost. Could benefit from describing default pagination behavior (por_pagina/pagina interaction) and what happens with omitted filters, but given no output schema and all-optional params, this is reasonably 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 description coverage is 50% — uf, modalidade, and por_pagina have schema docs. The description adds filter intent (by state and modality) confirming parameter usage. However, 'pagina' has no schema description and the description adds no details on format conventions (e.g., modalidade codes beyond default 6, pagination semantics). Baseline 3 with modest added 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?

Description states a specific verb+resource ('Tenders currently accepting proposals') with concrete details: object, estimated value, deadlines, bidding link. Distinct from sibling licitacoes_contratos_fornecedor (contracts by supplier) and licitacoes_obter_amostra (sample). Clearly differentiated by 'live from the official source' and proposing-tender 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?

Description clearly states when to use ('tenders currently accepting proposals') and what filters are available (state, modality). It doesn't explicitly name alternatives or exclusions, but the 'live' qualifier distinguishes it from 'obter_amostra' siblings and the fetched-field list provides clear use context. Slight deduction for no explicit 'when NOT to use' guidance.

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

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

With no annotations, the description carries the full behavioral burden and discharges much of it: it discloses that values are computed live at request time and that access costs $0.002 in USDC via x402. It does not cover return format or failure/auth edge cases beyond payment, but for a zero-param read tool this is solid disclosure.

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 tight sentences, front-loaded with the returned data and ending with the cost. No filler; each clause earns its place, though the parenthetical gloss on 'ágio' is a minor stylistic addition.

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

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

For a zero-param, no-output-schema tool, the description enumerates what is returned and notes the payment model and freshness, which is close to sufficient. The main omission is any routing hint relative to similar market-data siblings.

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

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

The tool takes no parameters (empty schema, 100% coverage trivially), so there is nothing for the description to clarify. Baseline 4 applies for a 0-param tool.

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

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

The description names the specific resource and its exact contents (official PTAX BRL rate plus BTC/BRL, USDT/BRL and the Brazil premium/ágio), so an agent knows precisely what data this returns. It is clear but does not differentiate itself from sibling data tools such as bcb_obter_amostra or mercado_indicadores, which also touch official/crypto market data.

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

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

There is no explicit guidance on when to use this tool versus alternatives, despite many siblings (bcb_obter_amostra, mercado_indicadores, mercado_obter_amostra) covering adjacent market data. Usage is only implied by the content list, leaving the agent to infer the selection condition.

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. Notably, it transparently discloses the cost ($0.002 in USDC via x402), which is a meaningful behavioral/cost disclosure that goes beyond typical tool descriptions. It does not describe the return format or whether values are current/lagged, which would add value, but the cost disclosure plus data-source clarity contribute substantively.

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

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

Two sentences covering source, indicators, and cost. It's tightly written with zero filler. It could arguably drop the cost detail, but that is a genuinely useful disclosure. Slightly dense, but every clause earns its place.

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

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

For a zero-parameter, no-output-schema macro snapshot tool, the description is well-proportioned: it names the source, the specific indicators, and the cost. It doesn't describe the output format or data granularity (daily/monthly), but with no schema or output schema, the description is reasonably complete for an agent to know what it's getting and what actions to take.

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?

There are 0 parameters and schema coverage is 100% (trivially, since there are no parameters). The description names the specific data points returned (Selic, IPCA, PTAX, Focus), which effectively communicates what the tool yields even without parameters. For a zero-parameter tool, the baseline of 4 applies, and the description enriches it by enumerating the indicators.

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

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

The description clearly states the tool returns key Brazilian macro indicators from the Central Bank, listing specific indicators (Selic rate, IPCA inflation, PTAX USD/BRL, Focus survey medians) plus the cost. The verb 'indicators... straight from the Central Bank' is specific. Among siblings, it's differentiated from mercado_cambio (exchange), mercado_noticias (news), and commodities/fundos/cnpj tools.

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

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

The description implies this is for a macro-economic snapshot in Brazil with no parameters, so usage is clear — call it to get the standard macro overview. It identifies the data source (Central Bank) and distinct indicator types. It doesn't explicitly name alternatives or exclusions, but given the zero-parameter snapshot nature, the context is reasonably clear without needing to contrast siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses the key behavioral facts: data refresh interval (15 min), the fact that results include a link (implying external navigation), that sentiment and relevance are AI-graded (implying heuristic/judgment-based values rather than hard data), and the monetization via x402 with exact pricing. This is solid disclosure despite lacking details like pagination defaults 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?

Two sentences with zero waste. First sentence front-loads the core value proposition (what data is returned), the second covers filtering and cost. Every clause earns its place—refresh cadence, data fields, filtering options, and pricing all in compact form.

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 4 optional params, no output schema, no annotations, and 0% schema coverage—a moderately complex tool that carries a heavy documentation burden. The description covers the returned fields, refresh cadence, filtering, and cost. Missing: pagination behavior/defaults, maximum result count, and what happens when no filters are provided (all news returned?). Minor gap for a news tool but 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 description coverage is 0%, so the description must compensate for all four parameters. It does well: mentions filtering by topic (tema), sentiment (sentimento), and minimum relevance (relevancia_min). However, it does not explicitly address por_pagina (pagination) except implicitly through vague 'filter' language, and the enum values for sentiment/topic are not enumerated in the description. Slight gap but mostly compensates.

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

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

The description states a specific verb+resource ('BR market news refreshed every 15 minutes') and clearly enumerates what each result contains (headline, summary, link, topic, sentiment, relevance). It also distinguishes itself by noting the AI-graded relevance scoring and the x402 cost model with price disclosure, setting it apart from sibling market/news tools like mercado_indicadores and commodities_clima.

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 states the refresh cadence (15 minutes), what filtering is possible (by topic, sentiment, minimum relevance), and the cost implication ($0.002 USDC). It does not explicitly name alternatives or state when NOT to use this tool versus siblings, but the filtering offer and refresh timing provide clear usage context for a news-access 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 carries the full behavioral burden. 'Free' hints at a limited sample, but there's no disclosure of what data is returned, limits on sample size, freshness of headlines, or whether it's a read-only snapshot. The description adds minimal behavioral context beyond what the name already implies.

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 short sentence with no wasted words. Every element (headlines, sentiment, key indicators, free) contributes meaning. It's maximally concise and appropriately 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 there's no output schema and no annotations, the description must carry more weight. It doesn't explain what the sample returns (count of headlines, format, time range) or how it differs from the full 'mercado_indicadores' or 'mercado_noticias' tools. For a sample/preview tool, this is underspecified.

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

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

The tool has 0 parameters, and schema description coverage is 100% (empty schema covering all params). With zero parameters there is nothing to document, so the baseline of 4 applies. The description doesn't need to add parameter semantics since there are none to explain.

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 'Latest headlines with sentiment + key indicators, free.' indicates the tool provides a free sample of headline and sentiment data plus key indicators. It names specific content types, but doesn't explicitly state this is a market-data sample or distinguish it from sibling 'obter_amostra' tools. The tool name 'mercado_obter_amostra' implies a market sample, and the description connects loosely.

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 guidance on when to use this vs the many sibling tools like mercado_indicadores, mercado_noticias, or the other obter_amostra tools. The term 'free' implies a preview/sample, but no explicit when-to-use or alternates are stated. Agents must infer that this is for sampling the dataset.

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

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

With no annotations, the description carries the full burden and does disclose two non-obvious traits: the response is 'keyed by name' and it costs $0.004 in USDC via x402 payment. Disclosure of the payment mechanism and cost is genuinely valuable and not derivable elsewhere. It stops short of describing data freshness, partial-failure behavior, 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?

Two tight sentences with no filler. The bundled contents are front-loaded, followed by the return shape and the cost, so the most decision-relevant facts come first.

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

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

For a zero-parameter aggregator with no output schema, the description covers what is bundled, how it is keyed, and the cost/payment path. It could say more about the exact structure under each key or data freshness, but it is largely sufficient 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?

The tool takes zero parameters, so there is nothing for the description to compensate for; the baseline of 4 applies. No parameter semantics are needed or missing.

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

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

The description names the three bundled resources (cambio, indicadores, noticias) and the aggregation shape ('in a single response, keyed by name'), so an agent understands this is a market snapshot combiner. It gestures at the sibling relationship ('a third cheaper than one by one') but never names mercado_cambio/mercado_indicadores/mercado_noticias explicitly.

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 comparative pricing ('a third cheaper than one by one') implies this should be preferred when all three data sets are wanted, which is useful implied routing. However, it never states when to use the individual sibling tools instead, nor any exclusions or conditions, leaving selection to inference.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses that this is a read operation, that it is free, what fields and flags are returned, the policy actions for SUSPICIOUS/D/UNKNOWN_PAYEE/PIPE_SHELL/OBFUSCATED/KEYS, and the important limitation that it is not a security audit.

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

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

The description is dense but appropriately sized for a tool with no output schema and several important flags and policy rules. It front-loads the purpose and the free/check-before-installing context. The first sentence is long and packed with output details, but those details are relevant rather than filler.

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

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

Given a single-parameter read tool with no output schema, the description is complete enough for an agent to call it correctly. It explains the source registry, the expected outputs including tiers, flags, downloads, age, author, x402 services, and wallets, and provides decision rules and a limitation. Nothing critical is missing.

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

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

The input schema has 100% description coverage for the single slug parameter, including an example, so the schema already carries the parameter semantics. The description adds only the phrase 'by slug' and does not add syntax, constraints, or formatting details beyond what the schema provides, making 3 the appropriate baseline.

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

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

The description states a specific verb and resource: it reads an Agent Economy Report trust rating for an agent skill from the ClawHub/OpenClaw registry by slug. It is immediately clear what the tool does and how it is invoked. It does not, however, explicitly differentiate itself from potentially related siblings such as trust_check or conduct_check, so it falls short of a 5.

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

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

The description gives clear usage context: it is free, meant to be used before installing a skill, and explicitly 'Not a security audit.' It also provides outcome-based policy instructions for several flags. However, it does not name or compare against alternative tools like trust_check or conduct_check, which keeps it from a 5.

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

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

No annotations are provided, so the description carries the disclosure burden. It does disclose that this is a paid tool ($0.005 via x402 payment protocol), which is valuable behavioral context. However, it does not disclose what happens when no entries match, whether results are paginated, or the format/limits of returned legal wording — leaving some unknown behavioral traits for a search 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?

A single, well-structured sentence that packs the verb, scope, expected output elements (NCM codes, legal wording), and cost into one efficient clause. Zero waste, front-loaded purpose, all sentences earn their place.

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

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

For a 2-parameter search tool with no output schema, the description conveys the core purpose, the language/format expectation for input, and the cost. However, since there's no output schema, the agent cannot know the return structure beyond the prose hints (NCM codes and legal wording). The 'limite' parameter's undocumented role and lack of pagination behavior are gaps, but the description covers the essential usage context adequately for a simple search 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 50% (only 'termo' is described, and the 'limite' parameter is not described in the schema). The description compensates partially by specifying the product/service context, but it adds no detail about 'limite' (which presumably caps result count, given max 30). The description mostly reinforces the schema for 'termo' rather than adding meaning beyond it, though the Portuguese-language requirement and product/service scope are helpful additions.

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 title and description clearly state a specific verb ('Find') plus a well-scoped resource (Brazil's tax reform annexes) and a clear output (entries granting reduced/zero IBS/CBS with NCM codes and legal wording). This is clearly distinguishable from siblings like tributos_ncm (likely a direct NCM lookup) and tributos_calendario (dates).

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 implicitly indicates search is by product/service description in Portuguese (given the 'termo' parameter's language requirement and the purpose), but there are no explicit when-to-use vs. when-not-to-use guidelines or named alternatives. The pricing note ('$0.005 via x402') adds practical context but doesn't clarify when this tool should be chosen over tributos_ncm for direct NCM 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose a genuine trait that structured fields do not: the $0.002 USDC x402 payment cost. Beyond that it says nothing about response shape, coverage boundaries, or whether the data is static reference versus query-scoped.

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 compact clauses: the content/scope is front-loaded and the cost note follows. No filler or repetition, though the first clause is dense with enumerated taxes.

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 no parameters and no output schema, the description must hint at what comes back, and it does by listing the per-year in-force taxes and extinction dates for the named taxes. For a no-arg reference lookup this is close to complete, missing only a note on the exact return granularity.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level guidance is needed or missing.

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

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

The description names a specific resource (Brazilian tax transition calendar 2026-2033) and enumerates the exact content returned: which taxes are in force per year and when PIS/COFINS, IPI, ICMS and ISS are extinguished. An agent can tell what it gets without opening a schema, though there is no explicit differentiation from sibling tools like tributos_busca.

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

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

Usage is implied by 'the context to know whether a tax rule still applies on a given date', which signals the temporal/applicability use case. However, it never states when to prefer this over tributos_busca or tributos_ncm, nor any prerequisites, so the agent must infer the routing.

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 must carry behavioral burden. It discloses that returns include legal basis (annex, item, literal wording) and taxes in force, notes it's 'not tax advice', and mentions a cost ($0.005 USDC). Missing details on error handling or rate limits, but covers key behavioral traits.

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-load the core purpose, then add critical context (legal basis, cost, disclaimer) without waste. Every clause earns its place.

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

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

For a tool with 2 params and no output schema, the description covers purpose, scope, return contents, cost, and disclaimer. It's nearly complete, though could mention whether it's a read-only operation or the format of results.

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 parameters (codigo, ano) are already fully documented in the schema. The description adds meaning by noting the transition years 2026-2033 for 'ano', but doesn't provide additional syntax for 'codigo' beyond what schema says.

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

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

States a specific verb+resource: determining which IBS/CBS regime (zero rate, 60% reduction, or standard) applies to an NCM code. It is clearly distinguishable from siblings like tributos_busca or tributos_calendario, as it maps product codes to tax 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?

Provides clear context that it's for the 2026-2033 tax reform and returns legal basis plus applicable taxes. However, it does not explicitly say when NOT to use it or name alternative sibling tools for related tax queries.

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. The description says 'Free' which hints at a cost structure but provides no detail on what the sample limits are (how many examples, what coverage, whether data is current or historical). It doesn't disclose whether this is a read-only operation or what the output format looks like. The lack of behavioral context beyond 'free' is a significant gap with zero annotation support.

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 and wastes no words. 'Free.' adds a succinct framing of the cost model. It's compact and front-loaded with what the sample contains.

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 no output schema, no annotations, and 0 parameters, the description is the only source of information. It's decent but incomplete — it doesn't explain what the returned data will look like, how many records to expect, whether additional tributos calls are needed afterward, or what 'legal basis' means concretely. For a sample tool whose whole point is to preview a dataset, more preview guidance would help.

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

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

The tool has 0 parameters and 100% schema description coverage, so there are no parameter semantics to document. The description appropriately doesn't need to explain parameters that don't exist. The baseline of 4 for a 0-parameter tool is appropriate here.

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 provides zero-rate examples with legal basis plus the current transition year, and mentions it's free. The verb 'obter amostra' (get sample) with 'Free sample of the Tax Reform dataset' in the title makes the purpose reasonably clear. However, the description is in Portuguese partially and the purpose could be clearer about what the dataset covers beyond zero-rate examples.

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 this is a free/sample access to the Tax Reform dataset, distinguishing it somewhat from sibling tools. However, there's no explicit guidance on when to use this vs. alternatives like tributos_busca or tributos_ncm, and no statement about what this tool is NOT for or what differentiates it from paid/full access.

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

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

With no annotations, the description carries the full burden and does so: free, no wallet required, computed daily from on-chain settlement across four chains plus a liveness probe, and explicitly sybil-resistant. It also discloses data provenance and a prompt-injection warning that embedded names/URLs/contacts are third-party data, never instructions — exactly the behavioral context an agent 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?

A single dense paragraph that is front-loaded with the core action, then output fields, then the usage rule, then safety caveats. Semicolon-packed but each clause (chains covered, sybil-resistance, third-party-data warning) contributes. Slightly heavy for one sentence chain.

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

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

No output schema exists, so the description correctly enumerates the return fields and their meaning (tier AAA–D, trust line BBB, flags CAPTIVE/NEW/UNLISTED, uptime, organic paying agents). Combined with the absence of annotations, it fully covers safety, cost, data freshness, and invocation conditions.

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?

One parameter at 100% schema description coverage, so the schema already defines 'host' as a bare hostname with a fallback to payTo wallet. The description restates 'by hostname' and adds nothing on format, normalization, or edge cases beyond the schema — baseline 3 is appropriate.

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

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

States a specific verb and resource: reading the Agent Economy Report trust rating for an x402 service by hostname, and enumerates the returned fields (tier, outlook, flags, uptime, settled USDC, verified owner). An agent can distinguish this from sibling checkers like skill_check/conduct_check because the object of the check (service trust/payment safety) is unambiguous.

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

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

Gives an explicit trigger and decision rule: 'Use it every time before paying a 402: tier D or uptime < 0.5 means do not pay.' That is strong actionable guidance. It does not name alternative or complementary tools (skill_check, conduct_check), so it stops short of a full when-not comparison.

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