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 discloses that the search hits a "national full-text index," which is useful, but says nothing about pagination, ordering, result ordering, auth, or the notable default status filter ("recebendo_proposta").

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

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

Two tight sentences with the action and scope front-loaded and the use case plus example trailing. 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?

An output schema exists, so return values need not be explained, and the core purpose is clear. But with five params, zero schema coverage, and no annotations, the description leaves pagination, ordering, and the default status behavior unexplained — gaps an agent would hit on 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 0%, so the description must compensate. It only illuminates "termo" via the keyword phrase and example query; the other four parameters (pagina, status, ordenacao, tamanho_pagina) are entirely undocumented, including the important default status of open/receiving-proposal notices.

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 ("Pesquisa"), resource ("editais e contratações"), and mechanism/scope ("por palavra-chave no PNCP (índice full-text nacional)"). The keyword-search framing distinguishes it from the sibling listing tools like listar_oportunidades_abertas without needing to open any schema.

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

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

"Use para descobrir oportunidades por tema" gives a clear when-to-use with a concrete example query. It stops short of naming alternatives (e.g., listing tools) or stating exclusions, so it is context without routing.

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

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

With no annotations, the description carries the full burden. It does disclose the core behavioral trait — results are scoped to a date window and represent that agency's contractual history — but 'vigentes' is ambiguous against the actual parameter names (vigencia_inicial_min/max), implying currently-active contracts rather than a start-date filter. Auth needs, result size, and pagination behavior are unaddressed.

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

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

Two short sentences, front-loaded with the primary scope. The second sentence is near-redundant with the first, a minor waste, but overall the description is tight and readable.

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?

An output schema exists, so return values need not be explained, and the main filter dimension (agency + date window) is conveyed. However, given zero schema coverage and no annotations, the description leaves pagination, date format, and the precise meaning of 'vigentes' unresolved — gaps that matter for correct invocation of a five-parameter query tool.

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

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

Schema description coverage is 0%, so the description must document all five parameters, but it only alludes to codigoOrgao and the date window. The pagination parameters (pagina, tamanho_pagina) receive no mention, and the date string format and the fact that the window applies to vigência inicial specifically are never clarified.

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

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

States a specific verb and resource: retrieve contracts for a specific federal agency (codigoOrgao) within a validity date window. This scope distinguishes it from the generic listar_contratos_publicados, though that sibling is not named. The second sentence ('Mostra o histórico contratual daquele órgão') largely restates the first rather than adding a new dimension.

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

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

No explicit when-to-use or when-not guidance. The reader must infer from 'de um órgão federal específico' that this is the agency-filtered variant versus the broader listing siblings, but no alternative is named and no exclusion condition is 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?

No annotations are provided, so the description carries the full burden. It does disclose one useful behavioral trait — that an empty query returns active suppliers by default — but omits read-only nature, pagination behavior, and what 'situação' contains, leaving meaningful 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?

Two sentences with the purpose front-loaded and the usage condition following immediately. No wasted words, though it is quite short relative to the four undocumented parameters it needs to cover.

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?

An output schema exists, so return values needn't be described. However, with 0% schema description coverage, no annotations, and three parameters untouched, the description is only adequate for the primary use case and leaves the listing/pagination path under-specified.

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

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

Schema coverage is 0% with four parameters, so the description must compensate. It explains the cnpj parameter (give a value vs. leave empty) but says nothing about ativo, pagina, or tamanho_pagina, leaving three of four parameters undocumented in both schema and description.

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

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

States a specific verb (consulta) and resource (cadastro de fornecedores do governo federal) and clarifies it operates in two modes depending on CNPJ presence. It does not explicitly differentiate itself from siblings, but no sibling concerns suppliers, so the resource itself is distinguishing.

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

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

Explicitly names the two invocation modes: supply a CNPJ for a specific supplier's situation, or leave empty to list active suppliers. This is clear context for how to call it, though it offers no exclusions or alternative tools to consider.

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, and it delivers little: nothing about read-only nature, permissions, behavior when a contratação is not found, or rate limits. 'Detalhe completo' only hints at read semantics and is not a disclosure of traits.

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

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

Two sentences, zero filler, and the core purpose is front-loaded ahead of the input-provenance hint. Every sentence earns its place.

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

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

An output schema exists, so return values need not be explained, and the description covers the required input chain adequately. It leaves out what the tool does not return (items, arquivos, resultados are separate siblings) and any failure behavior, which keeps it from being complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning to the bare titles by identifying cnpj as the órgão's CNPJ and sequencial as a sequential number, and it names their provenance, but it gives no expected formats (punctuation, ranges) for any of the three parameters.

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

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

States a specific verb and resource ('Detalhe completo de uma contratação do PNCP') plus the three identifying keys, so an agent knows this is a detail lookup rather than a list. It does not, however, distinguish itself from other contratação-scoped siblings such as 'listar_itens_contratacao' or 'listar_arquivos_contratacao'.

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

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

Explicitly tells the agent where the three required values come from ('Esses três campos vêm em listar_oportunidades_abertas'), which sets up the correct call sequence. No when-not condition or explicit alternative is given, so it stops short of a full routing rule.

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

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

No annotations are supplied, so the description carries the full behavioral burden. 'Visão agregada' implies a non-mutating summary read, but the description says nothing about data freshness, whether results are precomputed/cached, rate limits, or how pagination interacts with an aggregate result set.

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

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

Two short sentences, front-loaded with the resource and then the scope, with no filler. It is efficient, though the brevity reflects a lack of content rather than disciplined editing.

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?

An output schema exists, so return values need not be explained, but for a tool with zero annotations and two undocumented parameters the description omits the essential context: which indicators are available, what the aggregation dimension is, and when to choose this over the listing siblings.

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

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

Schema description coverage is 0% for 2 parameters, so the description would need to compensate and does not. 'pagina' and 'tamanho_pagina' are conventional names with schema defaults (1 and 10), but the description adds no meaning about valid ranges or what each page of an aggregate contains.

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 identifies the resource (consolidated federal public procurement indicators) and the shape of the output (aggregated view of volume and values), which separates it at a high level from the listar_*/detalhar_* siblings that return itemized records. However, it never says which indicators are computed (counts, totals, by-supplier, by-modality), so the purpose stays vague beyond 'some aggregate'.

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 and no named alternative among the 14 sibling tools. An agent must infer that this is the summary/statistics tool rather than a listing tool, and receives no signal about prerequisites or whether it should be preferred over e.g. listar_contratacoes_publicadas for totals.

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 confirms this returns links (an output detail) but says nothing about pagination behavior, result limits, auth requirements, or ordering, and does not clarify whether the date window filters on start, end, or both.

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 tight sentence with the core scope front-loaded and no filler. It is appropriately sized, though its brevity comes partly from omitting information an agent would need.

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?

An output schema exists, so return values need not be explained, and the description covers the essential purpose. But for a four-parameter tool with 0% schema coverage and no annotations, it leaves parameter format and pagination behavior undocumented, which is a moderate gap.

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

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

Schema description coverage is 0%, so the schema documents none of the four parameters. The description only obliquely references the date-window filter ('janela de datas') without naming vigencia_inicial_min/max, their required status, accepted date format, or the meaning of pagina/tamanho_pagina. It does not compensate for the coverage gap.

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

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

The description names a specific resource ('Atas de registro de preços federais vigentes'), a scope ('em uma janela de datas'), and the returned links (ata e compra no PNCP). This distinguishes it reasonably from siblings like listar_atas_registro_precos by emphasizing active ('vigentes') records filtered by a date window, though it never names the 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?

Usage is implied by 'vigentes em uma janela de datas' – it suggests calling this to find currently-valid ARPs within a date range. However, there is no explicit when-to-use guidance, no when-not-to-use, and no routing toward or away from the near-identical sibling listar_atas_registro_precos.

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 results are documents with download links and usually PDF, but says nothing about permissions, authentication, pagination, rate limits, or whether the operation is read-only.

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

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

The description is two short, front-loaded sentences with no wasted words. It is appropriately sized for the amount of information it conveys, though it could be slightly more structured.

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

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

An output schema exists, so return values need not be explained. However, the description omits any meaning for the three required input parameters, provides no usage guidance, and has no annotations, leaving the agent with insufficient context to invoke the tool correctly.

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

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

Schema description coverage is 0% and the description does not mention any of the three required parameters (cnpj, ano, sequencial). The agent receives no explanation of what these parameters mean or how to supply them.

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 identifies a specific resource ('Documentos de uma contratação') and gives examples (edital, termo de referência, anexos) plus the output nature (download link, usually PDF). It effectively distinguishes the tool from siblings like listar_itens_contratacao by focusing on documents rather than items, though it does not explicitly state a verb or name a sibling.

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

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

There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The only extra detail, 'Geralmente PDF', describes the return format rather than usage context.

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

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

No annotations are provided, so the description carries full behavioral burden. It adds meaningful context by identifying the data source (PNCP) and that these are already-registered public reference prices, but it says nothing about pagination, result volume, or access constraints. Since an output schema exists, the return format need not be restated.

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 written sentences with the resource and source front-loaded and the intended benefit second. No filler or redundancy, though it could be marginally denser in conveying parameter details.

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

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

For a tool with four parameters, 0% schema description coverage, and no annotations, the description is thin. The output schema covers returns, but date format, pagination semantics, and the distinction from sibling price/ARP tools are all missing for a call to be made reliably.

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%; the four parameters carry only bare titles. The description implies a date interval but gives no date format (ISO vs. DD/MM/YYYY) and never mentions the pagina/tamanho_pagina pagination parameters. With zero schema coverage, it does not compensate sufficiently.

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

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

States a specific verb+resource+scope: listing 'atas de registro de preços publicadas no PNCP em um intervalo'. An agent can tell this retrieves PNCP price-registration records within a date range. It does not, however, differentiate itself from close siblings like listar_arp_vigentes or pesquisar_preco, so it stops short of a 5.

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

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

The description offers an implied use case ('útil para calibrar proposta'), which hints at when the tool is valuable. But it names no alternatives, no when-not conditions, and doesn't distinguish this from listar_arp_vigentes or pesquisar_preco, which overlap in sourcing price references.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses scoping (date range, no theme filter), which is genuine context, but says nothing about permission needs, pagination semantics, or rate limits; the return contract is partly covered by the output 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 short sentences, front-loaded with the core action and scope, then usage guidance, then the modality code. No filler; every sentence carries information.

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

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

The output schema covers the return shape and the description covers purpose, usage context, and the key modality mapping, which is sufficient for a read/list tool. Pagination behavior is the only notable gap, and it is minor given defaults.

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

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

Schema coverage is 0%, so the description must compensate. It explains the date-range intent and gives a useful code mapping ('Modalidade 6 = Pregão Eletrônico'), covering roughly three of five parameters, but leaves 'pagina' and 'tamanho_pagina' (pagination) entirely undocumented.

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 ('Lista contratações publicadas no PNCP') with its scope ('intervalo de datas, por modalidade'), so an agent knows exactly what it does. It implicitly separates itself from theme-filtered siblings via 'Sem filtro de tema', but does not name a specific alternative tool.

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

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

Gives a clear when-to-use context ('para medir volume ou varrer um período') and effectively a when-not via 'Sem filtro de tema'. It does not name the sibling to use instead when a theme filter is wanted, so the routing is left slightly implicit.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about pagination behavior, result scope, permissions, or whether results are complete vs. paged. It only restates the read purpose, leaving the agent without operational 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?

Two short, front-loaded sentences with no filler; the resource and scope lead before the use case. Nothing is wasted, though it is arguably too terse given the schema gaps.

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?

An output schema exists, so return values need not be described. But for a list tool with 0% parameter coverage, missing date-format guidance and pagination semantics leave the agent under-informed 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 0% across 4 parameters, so the description must compensate and does not. The phrase 'intervalo de datas' loosely implies the two required date inputs, but there is no date format, no mention of the required fields, and no explanation of pagina/tamanho_pagina.

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

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

States a specific verb and resource ('Contratos públicos firmados no PNCP') plus scope ('em um intervalo de datas'), which is more than a tautology. It does not explicitly distinguish itself from the near-named sibling 'listar_contratacoes_publicadas' or 'consultar_contratos_orgao', so the agent must infer the difference.

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?

'Serve para mapear quem já contrata o que você vende' gives a concrete use case, implying when the tool is useful. However, it offers no when-not guidance and does not name any alternative among the many siblings (e.g. consultar_contratos_orgao for org-scoped queries).

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read of one contratação's line items, but does not mention permissions, pagination, limits, or what happens with missing data. Only the returned content is gestured at, leaving significant behavioral 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?

Two sentences, front-loaded with the resource and its fields, with no filler. Slightly lean given it omits required usage and parameter context, but structurally clean and appropriately sized.

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?

An output schema exists, so return formatting need not be explained, and the description adequately conveys the tool's identity. But with no annotations and 0% parameter coverage, the lack of usage routing and parameter meaning leaves it only minimally complete for a three-required-parameter tool in a crowded sibling set.

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

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

Schema description coverage is 0% and all three parameters (cnpj, ano, sequencial) are undocumented in both the schema and the description. The phrase 'de uma contratação' hints that the tool keys off a single procurement identifier, but it never explains what cnpj, ano, or sequencial mean or how they combine.

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?

Names a specific resource (itens de uma contratação) and enumerates the fields returned (descrição, quantidade, unidade, valor unitário estimado), so an agent understands exactly what it produces. However, it offers no differentiation from siblings like listar_resultados_item or detalhar_contratacao, which is where a 5 would be earned.

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 use this tool versus alternatives, no prerequisites, and no exclusions. The second sentence ('É aqui que se vê o que o órgão realmente compra...') is evocative but does not tell the agent when to pick this over the many sibling listing tools.

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

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

No annotations are provided, so the description carries the disclosure burden. It makes clear this is a static reference table (a read-only lookup), but says nothing about auth requirements, caching, or that the set of codes is fixed. Adequate for a zero-parameter lookup but not rich.

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

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

Two short sentences, both front-loaded with the essential fact (what it is) followed by the action rule (when to call it). 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?

With an output schema present, the return shape needn't be described, and the zero-param schema needs no parameter explanation. The description supplies purpose plus timing, leaving only minor behavioral details 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 baseline is 4. Nothing in the description misrepresents how it is called.

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

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

The description names a precise resource — the PNCP procurement-modality code table — and implicitly the verb (listing/consulting it). An agent can immediately tell this is a reference lookup distinct from the action-oriented siblings like buscar_editais or detalhar_contratacao.

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

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

It gives an explicit when-to-use rule: consult this before passing the 'modalidade' value to the other tools. That directly routes the agent's sequencing behavior, which is unusual and valuable for a lookup tool.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that results are deadline-filtered and sorted by deadline, but says nothing about pagination semantics, how a missing/empty result behaves, or whether the required deadline is inclusive. For a no-annotation tool this is thin.

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

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

Two short sentences that are front-loaded with the core scope. Minor redundancy: the second sentence partly restates the first ('lista de oportunidades em aberto'), but no sentence is wasteful enough to hurt usability.

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?

An output schema exists, so return values need not be described. However, with four parameters at 0% schema coverage and zero annotations, the description should compensate by clarifying modalidade and pagination; it does not, leaving real gaps 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 0%, so all four parameters rely on the description. 'até uma data limite' loosely maps to data_final and 'ordenável por prazo' hints at ordering, but pagina, tamanho_pagina, and especially modalidade (default 6, an opaque integer with no enum) are entirely unexplained.

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

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

The description states a specific verb and resource ('Lista contratações que ainda aceitam proposta'), which is a clearer scope than the bare name. It conveys the key filter (deadline) and ordering. It does not, however, explicitly distinguish itself from close siblings like listar_contratacoes_publicadas or buscar_editais, leaving the agent to infer the difference.

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 and no named alternative. An agent cannot tell from the description why it should pick this open-opportunities list over listar_contratacoes_publicadas or buscar_editais. Usage is only implied by the phrase 'oportunidades em aberto'.

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 a data-availability trait — results only exist for a homologated/closed dispute — but says nothing about read-only nature, permissions, or error/empty behavior when a dispute is not yet finalized.

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

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

Two sentences, zero waste, and front-loaded: the returned resource comes first, the usage trigger second. Every sentence earns its place.

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

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

An output schema exists, so return-value detail is not required, and purpose plus usage are adequately covered. However, for a four-required-parameter lookup with no annotations, the total absence of parameter meaning and safety context leaves real gaps.

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

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

Schema description coverage is 0% for four required parameters (cnpj, ano, sequencial, numero_item), and the description gives the agent no meaning for any of them — in particular whether cnpj identifies the buyer organ, the supplier, or the dispute, and what 'sequencial' keys against. It fails to compensate for the coverage gap.

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

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

The description names a specific resource and payload ('Resultado homologado de um item: quem ganhou e por qual preço'), so an agent knows it returns the finalized outcome of a dispute with winner and price. It is clearly distinguishable from listing siblings, though it does not explicitly contrast with the price-oriented sibling pesquisar_preco.

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

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

It gives a clear triggering context ('Use para saber o preço praticado e o fornecedor vencedor') and adds a useful scope condition ('disputa encerrada'). No alternatives or exclusions are named, so it stops 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, the description carries the full burden, and it partially does so by disclosing the return content ('preços praticados em compras públicas'). However it omits permission requirements, pagination behavior, and any indication of result scope or rate limits.

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

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

Three short, front-loaded sentences with no filler; the core purpose leads and the parameter guidance follows. Efficiently sized for the amount of 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?

An output schema exists, so return values need not be detailed, and the description covers the essential tipo/codigo pairing. It is still incomplete on pagination and on when this tool is the right choice, leaving gaps for an agent.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that 'tipo' accepts 'codigoItemCatalogo' or 'codigoPdm' and that 'codigo' is the item code, but leaves 'pagina' and 'tamanho_pagina' entirely undocumented.

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?

Names a specific verb (Pesquisa) and resource (preços de materiais no catálogo federal), and states it returns prices from public purchases. The purpose is clear, though it does not explicitly distinguish itself from price-adjacent siblings like listar_atas_registro_precos.

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

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

The description explains how to call the tool but gives no when-to-use context, prerequisites, or alternatives among the 14 siblings. An agent gets no routing guidance for choosing this over other procurement lookups.

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