BR Intelligence

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 cost behavior ('Free.') which no schema field conveys. However it says nothing about authentication requirements or whether the response is static documentation, leaving the behavioral profile 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 compact sentence with the cost qualifier front-loaded. It is a sentence fragment rather than a full clause, which slightly reduces readability but wastes no words.

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

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

For a zero-parameter informational tool with no output schema, the description adequately previews the returned content (service description, pricing, payment network, docs links). An agent knows what it will get; only auth/format details are absent.

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 to document and the baseline is 4. The description does not need to explain argument semantics at all.

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 resource clearly: it enumerates the informational content returned (what the service does, per-tool pricing, payment network, docs links). It lacks an explicit verb like 'describe' or 'get info on', but for a zero-parameter meta tool the intent is unambiguous. No sibling differentiation is offered, though the sibling list makes the informational nature self-evident.

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 only implied: an agent can infer it should call this to learn about the service before using the functional siblings, but the description never says when to reach for it, nor does it name any alternative. The listed content buckets hint at the use case without stating it.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavioral traits: batch cap of 10 and the billing rule that invalid-format entries are not charged. But it says nothing about what the score means, error handling for valid-but-unknown CNPJs, output shape, or rate limits — significant gaps for a paid scoring endpoint.

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: the capability and scope come first, pricing second. Every clause carries information — no restated name, 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 one-parameter, annotation-free tool with no output schema, the description covers input limits and cost but leaves the return value completely undefined. An agent knows how to call it but not what it will receive, which is a meaningful gap when 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?

Schema coverage is 100% and the single parameter is fully documented as comma-separated CNPJs up to 10, so the baseline of 3 applies. The description echoes the batch limit and adds the invalid-format billing nuance, but no format or delimiter detail 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?

States a specific verb/resource ('Health/risk score') and a precise scope ('up to 10 Brazilian CNPJs in one call'), which implicitly distinguishes it from the singular get_company_score sibling. It stops short of naming that sibling or any other alternative explicitly, so differentiation is inferable rather than stated.

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 parenthetical '(supplier/customer list triage)' gives one concrete use case, which is better than nothing. However, it never says when to prefer this over get_company_score or get_company, and lists no exclusions or prerequisites.

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 disclosure burden and does well: it specifies the holiday scope (national holidays including Carnaval and Corpus Christi, no state/municipal holidays), defines output per mode, and states the price. It omits edge-case behavior such as what happens if both add and end are provided, or how invalid dates are handled.

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

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

A single dense paragraph that front-loads the scope and then enumerates the three input modes before closing with the price. Every sentence carries essential information; 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 simple 3-parameter utility with no output schema and no annotations, the description covers the key behaviors: holiday scope, output semantics per mode, and pricing. It falls short of fully specifying the return structure and edge cases, but is adequate for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that end is exclusive and by describing the return for each parameter combination, which the schema does not provide.

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?

Identifies the resource (Brazilian business days) and explains exactly what is returned for each parameter combination, making its function clear. Lacks an explicit verb at the start, but the mode descriptions leave no ambiguity about what the tool computes.

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 for each input mode: 'With only date', 'With add', 'With end'. This tells an agent how to invoke the tool for the desired result. No alternative date tools exist among siblings, so no when-not-to-use guidance is needed.

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 well: it discloses the returned fields (bank, amount, due date, check-digit results), flags a real domain caveat (ambiguity from the Febraban 2025 factor reset), and even states the cost ($0.005). It stops short of describing error behavior for malformed codes, but this is a stateless pure decode function whose safety profile is self-evident.

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

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

Two tightly packed sentences plus a price tag; the input formats come first, then return values, then the ambiguity caveat. Every clause carries information an agent would otherwise have to guess.

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?

There is no output schema, yet the description names the returned fields, so an agent knows what to expect back without one. The only gap is failure handling — what happens to a code that fails the check digit — which is minor for a simple decode utility.

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 single parameter is fully documented in the schema (100% coverage), so the baseline is 3, but the description adds digit-count semantics (47/48/44) that tell the agent exactly what a valid 'code' looks like, going beyond the schema's generic 'digitable line or barcode' phrasing.

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

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

States a precise compound verb ('validate and decode') on a specific resource ('Brazilian boleto') and enumerates the exact accepted input shapes (47-digit cobranca, 48-digit arrecadacao, 44-digit barcode). The resource itself cleanly separates it from the sibling decode_pix.

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 accepted input forms imply when the tool applies, but the description never states when to use it versus alternatives (e.g., decode_pix for Pix keys, validate_identifier for other identifiers) or any prerequisites. Usage is only inferable from the tool's subject matter.

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 several behaviors beyond the schema: it validates CRC16 as well as decoding, states the payload is not stored (data-handling), and quotes a price of $0.005 (cost awareness). It omits error behavior for an invalid CRC or malformed payload, which is the main remaining 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?

A single dense sentence front-loads the action and resource, followed by the decode fields and the cost tag. No filler, and every clause supplies information an agent would otherwise have to guess.

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?

There is no output schema, so the description must describe return values — and it does, listing CRC16, key, key type, merchant name/city, amount, txid, and static vs dynamic. For a one-parameter stateless decoder this is nearly complete; only failure-case behavior is unstated.

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 exists and schema description coverage is 100%, so the schema already documents 'payload' fully. The description adds no syntax or format detail beyond what the schema provides, which is the expected 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?

States specific verbs (validate, decode) and the exact resource (PIX copia-e-cola / BR Code), then enumerates the fields it extracts, so the agent knows precisely what comes back. It is distinguishable from the sibling decode_boleto by resource type, though it never names that sibling 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?

No when-to-use guidance, no prerequisites, and no routing to alternatives is given. The agent must infer from the name/description alone that this is the PIX counterpart to decode_boleto.

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

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

With no annotations, the description carries the behavioral burden and does add the useful cost signal ($0.01 per call), which the agent cannot get from structured fields. It does not, however, state return format, whether the lookup is cached, or behavior on invalid/unknown CNPJ, so the disclosure 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?

One dense sentence covering resource, key, and returned fields, plus a short price note. Zero filler and the identity of the tool is front-loaded.

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

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

For a one-parameter lookup with no output schema, listing the returned data fields substitutes meaningfully for a return-value description, and the price is disclosed. Missing only edge-case behavior (unknown CNPJ, error handling), which keeps it short of full 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%, so the single cnpj parameter (formatting optional, numeric or alphanumeric per IN RFB 2.229/2024) is fully documented in the schema. The description only restates 'by CNPJ' and adds nothing 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?

States a specific verb (retrieval) and resource (Brazilian company registration data), keyed on CNPJ, and enumerates the returned fields (legal name, status, address, QSA, CNAE, capital). This distinguishes it implicitly from siblings like get_company_dossier and get_company_score, though it never names those alternatives 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?

No when-to-use guidance and no routing to alternatives such as get_company_dossier or get_company_score, both of which return related company data. Usage is only inferable from the field list; nothing tells the agent which sibling to pick or in what situation.

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. It usefully discloses the per-call price ($0.10), which no structured field covers, but says nothing about authentication, rate limits, failure behavior for an invalid CNPJ, or whether the call is read-only — leaving meaningful gaps for a billed lookup operation.

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

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

Two tight sentences, zero filler. The payload contents are front-loaded and the cost caveat follows immediately; nothing needs to be cut.

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 with no output schema, the description sketches the return content (registration data, signals, health score), which is helpful. However, with no annotations at all it should also cover side effects, error handling, and billing semantics to be fully complete — those are 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?

Only one parameter and schema description coverage is 100%, so the schema already fully documents the CNPJ format (numeric or alphanumeric, formatted or not). The description adds nothing about the parameter, which is the expected baseline when the schema does the work.

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 (Brazilian company dossier) and enumerates its payload: registration data, signals, and health score. The phrase 'in one call' implicitly distinguishes it from the piecemeal siblings get_company and get_company_score, though it never names them 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?

Usage is only implied: an agent can infer this is the aggregated option versus the narrower get_company/get_company_score, and the stated price ($0.10) is a decision input. There is no explicit when-to-use, when-not-to-use, or routing statement tying it to the sibling tools.

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

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

With no annotations, the description must carry the behavioral load. It usefully discloses cost ($0.02) and clarifies the output is a score plus the factors and flags behind it, and that it is not a credit score. It omits auth/permission requirements, latency, and any rate-limit or failure 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?

Three tight clauses with no filler, and the core purpose is front-loaded ahead of the 'not a credit score' caveat and the price. Efficient and scannable.

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

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

For a single-parameter, no-output-schema tool, the description covers what the score is, its scale, what accompanies it (factors/flags), and cost. The main missing piece is guidance on when to prefer the batch sibling.

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, including the numeric-or-alphanumeric (IN RFB 2.229/2024) note. The description adds nothing beyond identifying the resource as a Brazilian company, 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?

States a specific resource and scope: an explainable 0-100 health/risk score for a Brazilian company, with the backing factors and flags. The 'Not a credit score' disclaimer sharpens the concept, but it never names a sibling (e.g. batch_company_score or get_company_dossier) to distinguish itself within the toolset.

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 implied context via 'KYB / supplier triage', which tells the agent the kind of decision this supports. It stops short of explicit when-to-use/when-not guidance or pointing to alternatives such as the batch variant for multiple companies.

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 usefully discloses the response shape ('each value with unit and reference date') and the cost ('$0.005'), which are non-obvious traits. It says nothing about authentication needs, rate limits, update cadence, or whether historical values are retrievable.

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: content first, response detail second, price last. Every clause carries information and nothing is 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?

There is no output schema and no annotations, so the description must (and does) describe the returned fields, their units, and their reference dates. It is nearly complete for a simple read-only data feed; only freshness/update behavior is left unstated.

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 schema has nothing to explain and the baseline is 4. There are no parameter nuances the description could add.

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 ('Current Brazilian indicators from the Central Bank (SGS)') and enumerates exactly which series are returned: Selic target, CDI annual/daily, IPCA monthly/12-month, USD/BRL sell. No sibling tool overlaps with this, so an agent can select it unambiguously.

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 content list (call this when you need Brazilian macro/rate figures) but there is no explicit when-to-use, when-not, or alternative-tool guidance. For a zero-parameter snapshot tool the implication is strong, but nothing is stated outright.

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

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

No annotations exist, so the description carries the full burden. It does add a real behavioral fact the schema cannot express — the $0.002 per-call price — but says nothing about failure behavior for unknown codes, whether either identifier alone suffices, or rate limits. The cost disclosure is the only meaningful addition.

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 compact sentence plus a two-word input instruction and a price note. Front-loaded with the resource and return values; nothing redundant.

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-param lookup with no output schema, the description usefully names the return fields, compensating for the missing output schema, and discloses cost. The remaining gap is that it never clarifies that at least one identifier is effectively required despite required_parameters being 0.

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 both parameters (COMPE code format, ISPB 8-digit format) are already documented. The description adds that both are registry-keyed identifiers and that either can be supplied, but it does not resolve whether both may be passed together or which wins. 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 the resource (Brazilian bank), both accepted identifiers (COMPE code, ISPB), the authority (Central Bank registry), and the returned fields (short and full legal name). An agent can identify this as the bank-code lookup without opening the schema, and it is distinct from lookup_cep or validate_identifier.

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

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

'Provide code or ispb' tells the agent which inputs to supply, which is implied usage guidance, but there is no statement of when to prefer COMPE vs ISPB, no error/not-found handling, and no named alternative. Adequate but thin.

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, but it is a read-only lookup by nature. It usefully discloses the returned fields and the per-call price ($0.003), which is real context beyond the schema. It does not say what happens for an invalid or unknown CEP, nor whether results are cached or rate-limited.

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?

Very short and front-loaded: the resource and returned fields come first, the price last. It is a telegraphic fragment rather than full prose, but every token 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 read lookup with no output schema, the description adequately enumerates the response payload and the cost, which is the key operational fact. Only error/edge-case behavior is 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?

Schema coverage is 100% and the single 'cep' parameter is fully documented in the schema (8 digits, optional hyphen), so the description adds no parameter detail. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource: lookup a Brazilian address by CEP, and enumerates exactly what comes back (street, neighborhood, city, state, IBGE codes, coordinates). This clearly distinguishes it from siblings like validate_identifier or lookup_bank, though it never names an alternative 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives or when a different lookup tool (e.g. validate_identifier) would be preferred. The agent is left to infer the context 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 the full behavioral burden. It usefully discloses the cost and payment method ($0.005 USDC on Base via x402) and the supported identifier scope, but it omits return semantics, error behavior, and whether value formatting must be normalized before calling.

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

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

The description is two short sentences, front-loads the purpose and supported types, and adds the pricing detail without waste. Every element earns its place for this simple validation 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 annotations and no output schema, the description should carry more of the behavioral contract. It covers supported types and payment, but it leaves the return value (e.g., boolean, status, error details) and input format requirements for each identifier type unstated.

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 both parameters. It does expand the enum by naming CPF, CNPJ, EAN-13, NF-e, and phone, and adds that CNPJ may be numeric or alphanumeric, but it says nothing about the required 'value' format for each identifier type.

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 (validate) and resource (Brazilian identifier), then enumerates the supported identifier types. This makes the tool readily distinguishable from siblings such as decode_boleto, decode_pix, and lookup_bank.

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 identifier types listed and the verb 'validate'; an agent can infer it should use this tool when checking CPF, CNPJ, EAN-13, NF-e, or phone values. However, it gives no explicit when-to-use guidance, no prerequisites, and does not name alternatives for related decode/lookup tasks.

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