pontofato

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses 'without charging,' which is useful, but it does not mention whether the operation is read-only overall, what happens with an invalid pass, or any authentication requirements. For a status tool with zero annotation support, 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 a single sentence, which is concise and front-loaded. However, its brevity comes at the cost of clarity and completeness, so it earns a 4 rather than a 5.

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 one parameter and no output schema, the description should still explain what the tool returns or what 'status' entails. It does not mention the response format, error handling, or whether the pass must be valid. This is a significant gap for an agent trying to interpret the result.

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 schema itself provides a detailed description of the api_pass parameter including format and a caution to save before buying. The tool description adds no additional meaning about the parameter, so the baseline score of 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 'Monthly data package and private purchase status, without charging' indicates a status-check resource but lacks a strong verb like 'check' or 'retrieve'. It does not distinguish itself from siblings such as api_access_buy (purchase) or api_index (index), so an agent cannot confidently select it without additional inference.

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. It does not mention that this is for checking an existing pass, nor that api_access_buy should be used for purchasing. The absence of any contextual routing leaves the agent to guess.

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 delivers: it discloses explicit payment, idempotent retries ('Same pass in retries recovers the same purchase'), no auto-renewal, separate tariffs for other categories, and the usage headers X-API-Pass and X-API-Credits-Remaining. No annotation contradiction exists.

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?

Four sentences, each carrying a distinct fact: price/validity, payment requirement, idempotency/no-renewal, exclusions, and usage headers. The most decision-relevant information is front-loaded, 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 purchase tool with a fully-described 4-parameter schema and no output schema, the description covers cost, validity, prerequisites, idempotency behavior, exclusions, and how the purchased pass is used. Nothing an agent needs to call or understand the effect of the tool 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 coverage is 100%, so the baseline is 3. The description adds behavioral meaning beyond the schema, particularly for api_pass: idempotent recovery on retries and its later use as X-API-Pass. It doesn't add syntax details for payment, transaction, or credit_token, but the schema already documents those.

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 action and resource: 'Buy 1,000 basic data reads for US$1, valid for 30 days.' It also differentiates scope by noting that 'OCR, AI, documents and delivery keep their own tariffs,' so an agent can tell this purchase bundle apart from related endpoints.

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 clearly establishes the purchase context and the required precondition ('Requires explicit payment'), and tells the agent what is not covered by this purchase ('OCR, AI, documents and delivery keep their own tariffs'). However, it doesn't name an alternative tool or an explicit when-not-to-use condition beyond those excluded tariff categories.

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 the tool returns an index of routes, charges, and integration steps, which is a read-only behavior. But it doesn't specify the output format, structure, or whether any external calls are made, leaving some 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?

One short, front-loaded sentence that immediately communicates the core value proposition. Every word earns its place, with no filler or 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 zero-parameter tool with no output schema, the description adequately covers what it does. It could mention that the output is a list or that it's for onboarding, but these are minor given the 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 tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameter semantics, and it correctly implies no input is required.

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 is a self-described index covering routes, pricing, and MCP integration. It distinguishes itself from siblings by being a meta-documentation tool, though it doesn't explicitly name any sibling as an alternative.

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: it's an index to discover other tools and pricing. However, it doesn't explicitly say 'use this to get an overview before calling other tools' or provide any when-not-to-use guidance, leaving the agent to infer context.

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

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

With no annotations, the description carries the full behavioral burden but discloses only one trait: it is non-mutating ('does not create a charge'). It says nothing about authentication, rate limits, whether data is cached/live, or what the summary contains.

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 with no filler or repetition. It is efficient, though so terse that the reader is left wanting more substance given the absence of any other documentation.

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, the description should convey what the returned 'billing summary' contains, and it does not. It is minimally adequate but leaves the agent guessing about the shape and scope 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The empty schema is self-explanatory and the description need not add parameter 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 names the domain (payments/billing) and the output ('summary'), but leads with the vague noun phrase 'Payment discovery,' which never states a concrete verb or resource. It distinguishes itself only negatively ('does not create a charge') rather than describing what it positively returns.

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 guidance on when to call this versus siblings like pricing, contact, or empresas, nor any stated prerequisites or context. The 'does not create a charge' clause is a scope note, not a usage condition for selecting this tool.

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

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

With no annotations provided, the description carries the full burden. It only says 'textual search' but does not disclose any behavioral traits like rate limits, pagination, authentication, or what is returned. For a search tool, more transparency on expected behavior would be helpful.

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

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

The description is a single, concise sentence that front-loads the verb and resource. Every word earns its place; there is 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 simple search tool with 3 parameters and no output schema, the description is adequate but not complete. It does not mention return format, any constraints, or whether authentication is needed, but for a straightforward search it may suffice. Given no annotations, a bit more context would be expected.

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 schema already documents each parameter. The description adds the word 'textual' and notes that UF and city are optional, which slightly enhances understanding but does not significantly add meaning 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?

The description states a specific verb ('Busca textual' – textual search) and resource ('logradouro' – street/address), clearly distinguishing it from siblings like 'cep' (postal code) or 'raio' (radius). It is unambiguous about what the tool does.

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 mentions optional parameters (UF and city), implying the user can refine the search, but it does not explicitly state when to use this tool versus alternatives, nor does it give exclusions. The context is implied 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 of behavioral disclosure. It states the output includes addresses and coordinates, but says nothing about whether the CEP must exist, what happens for invalid or malformed inputs, whether results are limited, or whether this is a read-only lookup. Some behavioral expectation can be inferred from the name, but the description does not explicitly disclose limits or error 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 a compact single sentence in Portuguese that states the resource and the key output fields. It is appropriately sized for the tool's simplicity, though it could be slightly more explicit about the action (e.g., 'looks up' or 'returns').

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

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

Given the simple single-parameter tool, the description covers the main purpose but lacks usage context relative to siblings and does not mention return details beyond the presence of addresses and coordinates. A slightly fuller sentence naming the output shape or behavior for invalid CEPs would make it 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 schema has 100% description coverage for the single parameter, documenting that 'cep' is an 8-digit string with or without hyphen. The description adds no further parameter meaning beyond noting that addresses and coordinates are returned for that CEP. Baseline 3 is appropriate because the schema already provides complete parameter documentation.

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 that the tool returns addresses for a CEP along with latitude and longitude. It clearly identifies the resource (Brazilian postal code) and the type of output (addresses plus geocoordinates). It does not differentiate among sibling tools, though the specificity is sufficient to understand its core purpose.

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

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

There is no guidance on when to use this tool versus its siblings. Sibling names such as 'buscar', 'raio', and 'vizinhanca' suggest related geolocation or search tools, but the description does not explain when cep is the right choice or what types of queries fall outside its scope.

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 discloses meaningful behavioral traits: free, no captcha, no payment, no account, a 10-second rate limit per network with a queuing mechanism ('a que chega antes espera a vez e sai — sem erro'), and email delivery with the `email` field as reply-to. This goes beyond basic safety and gives the agent a realistic model of constraints and side effects.

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

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

The description is front-loaded with purpose, but it repeats the same facts twice: 'Grátis, sem captcha nem pagamento' is later restated as 'Sem captcha, sem conta, sem pagamento', and the rate-limit sentence appears twice in slightly different wording. This redundancy means not every sentence earns its place, though the overall flow is clear.

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

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

For a 10-parameter tool with no annotations and no output schema, the description covers purpose, rate limits, queueing, and email delivery, but it leaves a gap: it does not explain which parameters are relevant only for proposals (e.g., `tipo`, `espaco`, `orcamento`, `pagamento`) versus a simple question. An agent might populate proposal-specific fields for a question or fail to include them for a proposal.

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 baseline is 3, but the description adds useful semantic guidance: it ties `tipo` to the question-vs-proposal routing and tells the agent that `espaco` values come from `GET /api/partners`. This helps the agent populate those parameters correctly beyond what the schema alone provides.

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

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

The description clearly states the action ('Fale com quem faz o produto' – talk to the product team) and the two specific use cases: questions and sponsorship/partnership/ad proposals. It is specific about the resource and purpose, but it does not explicitly differentiate from sibling tools like chat_send or post_comment, so it misses the explicit sibling routing that would earn 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 context on when to use the tool: for questions or sponsorship/partnership/ad proposals, and it even distinguishes two routes via the `tipo` parameter. It does not name alternative tools or state when not to use it, but the use cases are clearly scoped, which is sufficient for an agent to select it appropriately.

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

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

Sem anotações, a descrição carrega toda a responsabilidade de divulgar o comportamento. Ela menciona paginação, mas não informa se a operação é somente leitura, se há autenticação, limites adicionais, ou o formato da resposta. Não há contradição com anotações (não há), mas o texto não agrega contexto comportamental além do óbvio.

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 descrição é uma frase única, direta e sem redundâncias. A informação principal está no início e o detalhe de paginação é incluído. É eficiente, embora não explore contexto adicional.

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?

Para uma ferramenta simples com dois parâmetros e sem schema de saída, a descrição é adequada mas não completa. Não explica o que exatamente retorna (apenas 'empresas'), nem trata de casos de erro ou comportamento quando não há empresas. Dado que não há schema de saída, uma descrição mais rica sobre o conteúdo da resposta seria útil, mas não é essencial para o uso básico.

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?

O schema já cobre 100% dos parâmetros, descrevendo 'cep' (8 dígitos, com ou sem hífen) e 'page' (página 0-based, 50 por página). A descrição não adiciona nenhum significado além disso, apenas repete a paginação. O baseline para alta cobertura é 3, e a descrição não eleva o valor.

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?

A descrição declara explicitamente o propósito: retornar empresas registradas em um CEP específico, com paginação de 50 por página. O verbo está implícito mas claro ('Empresas registradas'), e o recurso é específico (CEP). Diferencia-se de siblings como 'cep' (informação do CEP) e 'raio' (busca por raio), deixando claro o escopo.

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?

Não há nenhuma orientação sobre quando usar esta ferramenta em vez de alternativas como 'buscar', 'raio' ou 'proximo'. A descrição apenas informa o que faz, sem excludentes ou condições de uso. Em um conjunto de ferramentas com sobreposição potencial, isso deixa o agente sem critérios de seleção.

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 phrase 'service availability and coverage by UF' implies a read-only status operation and hints at the response granularity, which is useful. However, no annotations are provided and the description does not explain the response format, error behavior, or how availability is represented, leaving the agent to infer important behavioral 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?

The description is a compact one-line phrase with no filler. 'Disponibilidade' is front-loaded and the entire text is informative given the zero-parameter interface, so 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?

Because there are no parameters, the call shape is fully defined by the schema. However, there is no output schema and the description does not specify exactly how availability and UF coverage will be returned, so the agent may not know how to interpret the response without additional inference.

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 accepts zero parameters, so the description is not required to explain parameter details. The phrase 'by UF' adds useful context about the expected response granularity even though no input parameter exists.

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 identifies the resource as 'service availability' and the specific scope as 'coverage by UF', which lets an agent infer this is a status/health tool. It lacks an explicit verb, so it doesn't reach 5, but it is not a tautology and is understandable on its own.

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 guidance about when to use this tool versus sibling tools like api_access, billing, or unidades. The use case is only implied by the name and description, with no mention of alternatives or circumstances that would make this tool the right choice.

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 supplied, so the description carries the full burden, and it does little: 'no charge' is ambiguous (does it mean the endpoint is free to call, or that listed prices are zero?). It never states whether the call is read-only, whether auth is required, or whether results are cached/static.

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 short clause with no filler, and the key content (what it returns) is front-loaded. It is arguably too terse to stand alone, but 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?

With no output schema, the description is the only source of return-shape information, and it only gestures at the payload ('prices and free allowances') without indicating structure or freshness. For a trivial zero-parameter informational tool this is adequate but thin.

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 is 4. No parameter meaning is 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 resource ('public prices and free allowances') so an agent can tell it returns pricing information, but it gives no verb and no differentiation from the sibling 'billing' tool, which an agent could easily confuse it with.

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 statement of when to call this versus the sibling 'billing' or 'api_index' tools, and no prerequisites are given. Usage must be inferred purely from the resource 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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does address a critical behavioral trait: absent or empty lat/lon values are not converted to zero, and (0,0) is intentionally honored only if the user explicitly sent it. However, it omits other important behaviors such as error handling, return format, and whether the operation is read-only, leaving notable gaps.

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

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

The description is three short sentences with no filler. The core purpose is front-loaded in the first sentence, and the two subsequent sentences provide critical edge-case warnings that earn their place. The structure is efficient and easy to parse.

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 two-parameter tool, the description covers the most important edge case (zero-coordinate semantics), but it does not mention return values or failure behavior, and there is no output schema or annotations to fill that gap. An agent would not know what the tool returns on success or how errors are signaled. Coverage is adequate for basic invocation but not 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 input schema already documents both required parameters (lat and lon) with ranges, so schema coverage is 100%. The description adds meaningful semantic context beyond the schema: it clarifies the zero-coordinate behavior and warns against accidentally treating absent values as (0,0). This helps an agent handle edge cases correctly, justifying a score above the schema-covered 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 clearly identifies the tool's function: returning the closest address to a given latitude and longitude. The verb is implied ('find') but the resource ('Endereço mais próximo de latitude e longitude') and the scope are specific and unambiguous. It does not explicitly differentiate from siblings like 'raio' or 'vizinhanca', but the purpose is distinct enough that an agent can infer the intended use.

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

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

No explicit guidance is provided on when to use this tool versus its alternatives such as 'raio' or 'vizinhanca'. The description focuses on a data edge case (the (0,0) coordinate), not on contextual decision rules. An agent must rely on the tool name and sibling names to infer appropriate usage, which is insufficient.

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 mentions 'Grátis' (free) and that it returns distances and addresses, but it does not state whether the operation is read-only, whether authentication is needed, what happens on invalid input, or any rate limits. This is a significant gap for a tool with no annotation coverage.

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, compact sentence that front-loads the key purpose (return CEPs within a radius), mentions the input options, and notes the output fields and cost. Every word earns its place, with no redundancy or fluff.

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

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

Given the tool's simplicity (4 optional parameters, no output schema), the description is fairly complete: it states what is returned (CEPs with distance and addresses) and the free cost. However, it does not clarify the mutual exclusivity of 'cep' vs 'lat'/'lon' or the default radius value, though these are present in the schema. For a simple tool, 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?

The input schema has 100% description coverage, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it explains the concept of a radius ('N metros') and the two possible center types (CEP or lat/lon), but these are already implied by the schema fields. No additional semantics about parameter interaction (e.g., precedence when both 'cep' and 'lat'/'lon' are provided) are given.

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 CEPs within a radius from a point (CEP or lat/lon), including distance and addresses. It uses a specific verb ('returns') and resource ('CEPs'), and mentions the optional input types. However, it does not explicitly differentiate from sibling tools like 'cep' or 'proximo', which likely have related purposes.

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

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

The description implies when to use the tool (when you need CEPs within a radius from a point) but provides no explicit guidance on when not to use it or which sibling tools to prefer as alternatives. The sibling list includes 'cep', 'proximo', and 'vizinhanca', which could overlap, but no comparison is offered.

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 discloses pagination plus the grouping behavior of the parent lookup. It clarifies the effect of optional parameters on result scope, which is valuable behavioral context beyond the bare schema.

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

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

Three focused sentences in Portuguese, with the core purpose front-loaded. Every sentence adds information: what it returns, pagination, and the behavioral rule for optional parameters. 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?

The coverage is adequate for a simple, read-only resource: it states purpose, pagination, optional parameter behavior, and the contained fields (complemento and tipo). It does not enumerate all response fields or potential errors, but given the sibling context and simple resource, those gaps 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?

Schema coverage is 100%, so the baseline is 3. The description adds semantic value by noting that logradouro/numero are optional and that their absence changes pagination to the entire CEP, which is not obvious from the schema alone.

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

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

The description clearly states it returns units (apartment, store) of a CEP, with complement and type, and is paginated. It explicitly contrasts with the CEP lookup that groups by logradouro+número, distinguishing it from the sibling 'cep' route.

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 explains that omitting logradouro/numero pages the entire CEP, giving agents clear context on when to provide those parameters. It contrasts this route with the grouped lookup, implying when to choose this over the sibling, though it does not name the alternative route explicitly.

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 useful charging behavior: free when quota includes vizinhanca or *, and daily franchise before per-query tariff. However, it omits other behavioral context such as authentication needs, rate limits, result ordering, or side effects.

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

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

The purpose sentence is front-loaded and efficient. However, the quota instruction is repeated twice with nearly identical wording ('Consulte quota.free_now no índice...'), which makes the description less tight than it could be.

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 6-parameter tool with no output schema and no annotations, the description conveys core business meaning and billing context. Still, it leaves gaps around output structure, pagination, error cases, and explicit coordinate-versus-CEP selection rules. It is adequate but not comprehensive.

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

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

Schema description coverage is 100%, so the baseline is 3. The description maps business concepts like radius, CNAE, recent openings, and distance to the parameters, but adds no syntax or format details beyond the schema. It does not clarify the relationship between `cep` and `lat`/`lon` beyond the schema's existing note.

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 opening phrase identifies the resource: companies within a radius in meters, by CNAE, with recent openings and distance. It is specific enough for an agent to infer the tool's function, but it lacks an explicit verb and does not distinguish itself from sibling tools like `raio` or `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 description provides billing/access guidance ('Consulte quota.free_now...') but no guidance on when to use this tool versus alternatives. There are no explicit conditions, exclusions, or references to sibling tools, so the agent must guess when this is the right choice.

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