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

With no annotations, the description carries the full burden. It discloses that it uses the external ViaCEP API and accepts two input formats, but it does not mention error behavior, rate limits, or what happens when a CEP is not found. This is partial 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?

Two sentences, front-loaded with purpose, and no wasted words. The second sentence adds necessary input format detail.

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

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

For a simple lookup tool with one parameter and no output schema, the description covers the core purpose and input format. It does not describe the return structure or error handling, but the tool is simple enough that the address lookup intent is clear.

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 has no description for the 'cep' parameter (0% coverage), but the description explicitly explains accepted formats with examples: hyphenated (12345-678) and numeric (12345678). This fully compensates for the schema gap and adds clear semantic value.

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

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

The description starts with a clear verb and resource: 'Consulta endereço pelo CEP' (looks up address by CEP). It also names the ViaCEP API, making its function distinct from siblings like validar_cep, which validates rather than consults.

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 implies when to use this tool: when you need an address from a CEP. However, it does not explicitly mention alternatives or exclusions, such as 'use validar_cep to validate the CEP format' instead.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool uses an external API (AwesomeAPI), implying network dependency, and gives a usage hint about the code format. However, it does not mention potential error cases (e.g., invalid codes), rate limits, or the structure of the returned data, which are important for a basic query tool.

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

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

The description is a single, focused sentence followed by a short usage hint. It is concise, front-loaded with the main purpose, and every word adds value. No fluff or repetition.

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

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

The tool is simple (one parameter, no nested objects), but with no output schema, the description should clarify what the tool returns (e.g., the exchange rate value and currencies involved). The description only says 'consulta a cotação' without specifying the response format, leaving a gap in user expectations. Beyond that, the tool's behavior is reasonably clear given its simplicity.

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

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

The input schema only has a parameter 'moeda' with type string and no description, leaving 0% schema coverage. The description compensates by explaining that the parameter is a 3-letter currency code and provides examples (USD, EUR, BTC, ARS). This adds critical semantic meaning that the schema lacks, though it does not enumerate all supported currencies or case sensitivity.

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

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

The description clearly states the tool's function: querying exchange rates of a currency against BRL, USD, and EUR using the AwesomeAPI. It specifies the resource (currency quotes) and the verb (consulta), and it distinguishes itself from sibling tools like validar_cpf and gerar_cpf, which serve completely different purposes.

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

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

The description provides clear context for when to use the tool (when a currency exchange rate is needed) and includes an example of the input format (3-letter code). It does not explicitly mention alternatives or exclusions, but since the sibling tools are unrelated, the guidance is sufficient.

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

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

No annotations are provided, so the description carries the burden. It discloses that the CNPJ is 'válido aleatório' (valid and random) and explains the two format variants, which is useful. However, it does not mention output details such as formatting (e.g., with or without punctuation) or that each call yields a different result, leaving some behavioral ambiguity.

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

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

The description is two sentences: the first states the core purpose, the second explains the parameter values. It is front-loaded, concise, and every word contributes meaning without redundancy.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose and parameter semantics adequately. The only minor gap is the lack of explicit output format details (e.g., whether the result includes dots/slashes), but this is not critical for a generator of this type. Overall, the description is complete enough for an agent to use the tool correctly.

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

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

The schema has a single parameter 'formato' with an enum and default, but 0% description coverage. The description fully compensates by explaining the semantic difference between 'numerico' (old format) and 'alfanumerico' (new format), going beyond the bare enum values. This gives the agent clear understanding of how to choose the value.

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

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

The description clearly states 'Gera um CNPJ válido aleatório' (generates a valid random CNPJ), with a specific verb and resource. It also distinguishes from sibling tools like 'validar_cnpj' (validation) and 'gerar_cpf' (CPF generation).

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 by the name and purpose, but does not explicitly mention when to use this tool vs alternatives like validar_cnpj. It does provide guidance on choosing between 'numerico' and 'alfanumerico' formats, but this is parameter-level guidance, not tool-selection 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 full burden. It only says 'generates a valid random CPF', which is essentially the purpose. It does not disclose the return format (e.g., with or without punctuation), any algorithm details, or side-effect information, leaving the agent with minimal behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose 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 tool with no parameters and no output schema, the description is sufficient to understand the core function. It could be slightly more informative about the return value's format, but given the tool's simplicity, it is adequately complete.

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

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

The tool has 0 parameters, giving a baseline of 4. The description does not need to explain parameters, and there is no ambiguity in the input 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 'Gera um CPF válido aleatório' uses a specific verb (gera) and resource (CPF) with a qualifier (válido aleatório) that clearly distinguishes it from sibling tools like validar_cpf (validate) and gerar_cnpj (generate CNPJ).

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

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

Usage context is implied by the name and description: use this when you need a random valid CPF, not when validating an existing one. However, there is no explicit statement of when to use it vs. alternatives, or any exclusions.

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

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

With no annotations, the description carries the full burden. It states accepted input formats but does not disclose what constitutes a valid CEP, what the tool returns (e.g., boolean, error), or any side effects. This is insufficient for a validation tool.

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

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

The description is two short sentences, front-loads the purpose, and contains no redundant or filler content.

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

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

For a simple one-parameter tool, the description covers core purpose and input format, but omits important context such as output/return behavior and differentiation from sibling 'consultar_cep.' This makes it minimally viable but with clear gaps.

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

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

The schema provides only a string parameter with no description (0% coverage). The description compensates by explicitly listing accepted formats: with hyphen (12345-678) or just numbers (12345678), which clarifies parameter usage 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 begins with 'Valida se um CEP é válido,' which is a specific verb and resource. This clearly distinguishes it from sibling tools like 'validar_cpf' (different document type) and 'consultar_cep' (lookup vs validation).

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

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

No guidance is given on when to use this tool versus alternatives such as 'consultar_cep.' It does not mention exclusions or prerequisites, so the agent is left to infer usage from the name and description alone.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It adds useful context by stating that both numeric and alphanumeric formats are accepted and that the format is auto-detected. However, it does not mention what the function returns (e.g., true/false) or behavior on invalid input, so transparency is partial but not absent.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence adds value: the first states the function, the second covers format compatibility and auto-detection. No wasted words.

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

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

For a simple one-parameter validation tool with no output schema, the description covers the essential context: what it does and the input formats. It does not explicitly state the return value, but that is implied for a validator. The description is sufficiently complete given the low complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning by explaining that the 'cnpj' parameter can be in numeric or alphanumeric format and that detection is automatic. Yet it omits specifics like length, punctuation handling, or examples, leaving some ambiguity about the exact accepted input format.

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

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

The description clearly states the tool's function: 'Valida se um CNPJ é válido' (validates if a CNPJ is valid). It uses a specific verb (valida) and resource (CNPJ), and the sibling tools include validar_cpf and gerar_cnpj, which are clearly differentiated by document type and operation (validate vs. generate).

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 purpose is so specific that the usage context is clear—use this tool to validate a CNPJ, as opposed to generating one (gerar_cnpj) or validating a CPF (validar_cpf). However, it does not explicitly state when not to use it or directly name alternatives, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool returns the reason for invalidity, but it does not describe the accepted input format, the output structure for valid CPFs, or whether the operation is purely local and read-only. This leaves significant ambiguity for an agent.

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, concise sentence that states the main function and a key behavioral detail. It is front-loaded and free of unnecessary 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 the absence of annotations, an output schema, and parameter descriptions, the description should provide more context about input format and return behavior. It only partially explains the output (invalidity reason) and omits details about valid inputs and the structure of the returned data, making it incomplete for an agent to invoke the tool confidently.

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 one parameter 'cpf' with no description, and the tool description does not elaborate on the parameter's format, constraints, or examples. The description only repeats the term 'CPF' from the parameter name, adding no 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 clearly states the action 'Valida' (validates) and the object 'um CPF' (a CPF), adding the specific behavior of returning the reason for invalidity. This distinguishes it from sibling tools like 'gerar_cpf' and 'validar_cnpj'.

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

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

The description does not explicitly mention when to use this tool versus alternatives such as 'validar_cnpj' or 'gerar_cpf'. The use case is implied by the tool's name and description, but no explicit guidance or conditions are provided.

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