MCP Compras Públicas Brasil

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
With 175 tools, many serve nearly identical purposes, such as multiple variations of contract or purchase queries distinguished only by version numbers or CSV flags. The descriptions are generic and overlap heavily, making it difficult for an agent to reliably select the right tool.
Naming Consistency2/5
Tool names mix multiple conventions: 'compras_listar_modulo_...' vs 'pncp_obter_...' vs 'pncp_listar_...', and include version numbers and resource names in unpredictable orders. Some names use 'por_id', others embed parameter lists, creating an inconsistent and hard-to-navigate pattern.
Tool Count1/5
175 tools is far beyond the reasonable scope for an agent-facing server, especially since many are minor endpoint variations (e.g., with/without CSV, with/without quantity). This results in cognitive overload and poor navigability.
Completeness4/5
The server provides extensive read-only coverage of Brazilian public procurement, including purchases, contracts, ATAs, suppliers, and reference tables. Aggregated tools like pncp_obter_contratacao_completa fill integration gaps, though the overwhelming granularity makes it hard to confirm coverage.
Average 2.8/5 across 175 of 175 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, yet it only discloses that the data is 'público' (public, implying no auth) and gives the endpoint. It does not state whether the response returns file metadata, download URLs, or binary content, nor does it mention pagination behavior or that this is a read-only GET. The misleading first clause compounds this by implying the response includes IRP items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first clause earns no place — it describes the wrong resource scope — and the second half has an awkward auto-generated phrasing ('ação consultar informacoes documentos irp no caminho...'). The actual function (retrieving IRP files) is buried after the misleading clause instead of being front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no annotations, no output schema, and a sibling family where names differ only by suffixes (arquivos vs. arquivos_quantidade vs. itens vs. historico), this description is grossly inadequate. An agent cannot determine what the response contains, how the six pagination parameters relate, or how this differs from the quantidade sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (formato, auto_paginar, limite_resultados), so the description must compensate but adds nothing about parameters. The 9 undocumented parameters include a confusing set of six pagination aliases (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina) whose relationships are never clarified. The tool name implicitly encodes cnpj/ano/sequencial, but that comes from the name, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is internally conflicted: the first clause says it consults 'intenções de registro de preços e seus itens' (the IRP and its items), which is the scope of sibling tools pncp_obter_orgaos_irp_por_cnpj_ano_sequencial and pncp_obter_orgaos_irp_itens_por_cnpj_ano_sequencial, not this files endpoint. The second clause does name the actual resource (IRP documents at /arquivos), so the purpose is recoverable, but the leading clause actively misleads an agent about what this tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the closely related siblings that differ only by suffix: pncp_obter_orgaos_irp_arquivos_quantidade_por_cnpj_ano_sequencial, pncp_obter_orgaos_irp_por_cnpj_ano_sequencial, or the itens variants. The only usage context is the endpoint path itself; there are no exclusions, alternatives, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only adds 'dados públicos', implying public data, but discloses nothing about pagination behavior (despite three page-size parameters), result limiting (limite_resultados), format normalization (formato), or what a response contains. For a 20-parameter query tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence, but it wastes words on redundancy: 'consulta dados públicos de contratos públicos' and the action name are near-duplicates, and the endpoint path repeats the action verbatim. It is appropriately short, yet the structure does little beyond restating the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 20 parameters, 3 required, no output schema, and no annotations, the description needed to explain the required inputs, the filtering semantics (validity end-date window per órgão), and the response shape. It provides none of these, leaving an agent to reverse-engineer behavior from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% — 15 of 20 parameters are undocumented in the schema. The description adds zero parameter-level information: it never mentions the three required parameters (codigoOrgao, dataVigenciaFinalMin, dataVigenciaFinalMax) or their interplay. The only useful parameter hints come from the schema itself, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('consulta dados públicos de contratos') and identifies the specific variant ('consultar contratos fim vigencia') with its endpoint path, which separates it from the general _1_consultar_contratos sibling. However, it largely restates the tool name — 'fim vigencia' is repeated verbatim — and never explains what the variant actually does (contracts whose final validity date falls within a given range). The semantics must be inferred from the required parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over alternatives. The sibling list includes _1_consultar_contratos (general contract listing) and _1_1_consultar_contratos_id (by ID), but the description names none of them and provides no selection criteria, exclusions, or context. An agent must guess which variant fits the user's intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only adds 'dados públicos', hinting that no auth is needed, and 'consulta', implying read-only. It does not mention pagination behavior, the normalized-vs-original response format toggle, result limits, or any legacy-system quirks an agent should expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no fluff. However, the second clause ('ação consultar rdc no caminho /modulo-legado/7_consultarRdc') mostly restates information already present in the tool name, and the space could have been used for substantive guidance instead.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 26 parameters, 2 required fields, no output schema, and no annotations, this description is severely incomplete. An agent would not know what RDC means, which filters matter, how pagination works with the duplicate page parameters, what the formato option changes, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 19%, so the description must compensate for 26 mostly undocumented parameters, including six overlapping pagination parameters (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina) and the required date-range fields. The description explains none of these and does not even clarify that data_publicacao_min/max are the mandatory filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('consulta dados públicos de licitações e compras legadas') and identifies the RDC action. However, 'rdc' is never explained, and the phrasing overlaps heavily with the many sibling legado tools (licitacao, pregoes, compras sem licitacao), so an agent cannot tell what makes this tool distinct or what RDC refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over siblings. There is no mention of what type of contracting RDC covers, no exclusions, and no alternatives named. An agent facing 7+ legacy-module siblings is left to infer selection from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. The only behavioral clue is that the data is 'públicos' (public read-only), but it says nothing about pagination behavior, the normalizado versus original response formats, auto-pagination semantics, result limits, or how filters combine. For a query tool of this complexity, that is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and is not bloated, but it spends half its length restating the tool name ('ação consultar compra itens sem licitacao') rather than adding information. The endpoint path is the only novel element; better structure would front-load the resource and required filter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter tool with no annotations, no output schema, and only 19% schema parameter coverage, this description is far too thin. An agent cannot determine which filters are required or combinable, what the response looks like, or how this relates to the _id variant, so the tool is effectively unusable from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 19% (formato, auto_paginar, limite_resultados carry descriptions), so the description must compensate for the other 13 undocumented parameters. It contributes zero parameter meaning: no explanation of dt_ano_aviso_licitacao, co_uasg, co_orgao, co_modalidade_licitacao, nu_cpf_cnpj_fornecedor, or the duplicated pagination aliases (page/pagina, pageSize/page_size/tamanhoPagina/tamanho_pagina).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Consulta'), a resource ('compra itens sem licitacao'), and a concrete endpoint path, which is genuinely useful. However, the first clause ('dados públicos de licitações e compras legadas') is generic boilerplate, and the action phrase largely restates the tool name. It does not differentiate this from the sibling compras_listar_modulo_legado_6_1_consultar_itens_compras_sem_licitacao_id, which targets the same resource by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling variants. It does not mention that dt_ano_aviso_licitacao is the required entry point, does not contrast with the _id-based sibling, and gives no conditions or exclusions for selecting this over modulo_legado_5_consultar_compras_sem_licitacao or modulo_legado_2_consultar_item_licitacao.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, yet it only adds 'dados públicos' (implying public access, a small positive). It discloses nothing about pagination despite the schema exposing six pagination aliases (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina), nor about the default response format (formato=normalizado), result limits, or any operational quirks of a 23-parameter endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is a single compact sentence and the path reference earns its place, but 'dados públicos de contratos públicos' repeats 'públicos' and the sentence mostly restates the action name rather than adding meaning. For a tool of this complexity it reads as underspecified rather than elegantly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, 23 parameters (3 required), and a sibling list with at least five near-identical contract tools, a one-sentence description is nowhere near sufficient for correct selection and invocation. It omits required-parameter guidance, pagination disambiguation, and any differentiator from sibling tools, so an agent would have to reverse-engineer the schema and sibling names to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contributes zero parameter semantics, and schema description coverage is only 22% — 20 of 23 parameters are undocumented. The three required filters (codigoOrgao, dataVigenciaInicialMin, dataVigenciaInicialMax) are never surfaced, and the duplicate pagination fields are left completely ambiguous. The description needed to compensate for the low coverage and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('consulta') and a resource ('dados públicos de contratos públicos') and includes the concrete API path, which is useful. However, 'ação consultar contratos item' merely restates the tool name without explaining what an item-level query returns or how it differs from the sibling contracts tools such as compras_listar_modulo_contratos_1_consultar_contratos. The stated purpose is generic enough to describe several siblings, so it does not rise above vague-purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description gives no indication of when to choose this tool over the near-identical siblings — the contracts-list tool, the by-ID variant compras_listar_modulo_contratos_2_1_consultar_contratos_item_id, or the fim_vigencia variant — so an agent must infer the 'item' scope entirely from the tool name. There are no exclusions or alternative-routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says the tool consults public data, but it does not mention pagination behavior, result limits, formatting defaults, or any legacy-specific quirks. The read-only nature is lightly implied by 'Consulta', but the description does not meaningfully disclose behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than deliberately concise. It repeats the tool's action and endpoint without adding useful decision-making information, so the brevity does not serve the agent well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 17 parameters, one required parameter, no annotations, and no output schema, this description is far too sparse. It omits what values can be filtered by, how pagination works, what the response represents, and how it relates to the by-id sibling. An agent would have to guess or inspect the schema extensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18%, and the description itself provides no parameter guidance. It does not explain that 'modalidade' is required, nor does it clarify the distinction among the many pagination/filter parameters such as page, pagina, pageSize, page_size, tamanhoPagina, or tamanho_pagina. The description adds essentially no value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Consultar item licitacao') and resource ('dados públicos de licitações e compras legadas'), along with the endpoint path. It goes beyond a tautology, but it does not explicitly distinguish itself from the sibling tool compras_listar_modulo_legado_2_1_consultar_item_licitacao_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the by-id variant or other legacy-module list tools. The public-data nature is implied, but there are no exclusions, preferred filters, or conditions that would help an agent choose it confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 reveals only that the operation is a public data 'consulta' (read) returning a 'quantidade', but does not explain what quantity is being counted, the shape of the response (e.g., a bare integer versus an object), or whether the historic records this count refers to are available via the sibling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but its first sentence is wasted filler that lists resource types (itens, resultados, arquivos) not served by this endpoint, and the most specific information is buried in the second sentence. A front-loaded phrasing like 'Returns the count of historical records for a purchase identified by CNPJ, year, and sequential number' would be both shorter and clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description alone must answer what the response is and why to pick this endpoint among 100+ siblings. It does neither: an agent cannot determine what a 'quantidade' response looks like, and there is no guidance separating this from the full-history sibling. The path is the only salvageable information, and it mostly duplicates what the tool name already encodes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'formato' is documented), so the description must compensate. The embedded path does show that cnpj, ano, and sequencial act as path segments identifying a purchase, which adds some meaning beyond the bare schema. However, it does not explain acceptable CNPJ formats, year ranges, or what 'sequencial' refers to, nor the effect of choosing 'normalizado' vs. 'original' beyond the schema's own one-line note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The second clause identifies a specific action ('consultar quantidade') and resource via the path /v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/historico/quantidade, which is genuinely informative. However, the opening clause 'Consulta dados públicos de compras públicas, itens, resultados e arquivos' is generic boilerplate that misleadingly suggests the endpoint returns purchases, items, results and files, when it actually returns only a history quantity count. The description never articulates the conceptual scope drawn from the name: the count of historical records for a specific purchase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. In particular, it does not distinguish itself from the near-identical sibling pncp_obter_orgaos_compras_historico_por_cnpj_ano_sequencial (full history vs. quantity), nor from the other 'quantidade' variants for arquivos, itens, contratos, and IRP. An agent must infer the selection criteria purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only says the data is public and gives the endpoint. It does not mention whether this is a list operation, how pagination works, what the response format looks like, or the required date filters. The agent gets almost no behavioral context beyond 'read public data'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main purpose, and the endpoint clause adds useful path information. However, it is too terse for a 21-parameter tool with no output schema; the brevity veers into under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity — 21 parameters, no annotations, no output schema, and many closely related sibling tools — the description is clearly insufficient. It does not explain the essential filters, whether it returns a list or single item, pagination defaults, or how this tool relates to compras_listar_modulo_arp_2_1_consultar_arpitem_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no parameter semantics at all. The required dataVigenciaInicialMin/dataVigenciaInicialMax filters, the formato option, auto_paginar, and limite_resultados are never mentioned, so the description fails to compensate for the many undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Consulta dados públicos') and resource ('atas de registro de preços') and identifies the endpoint action 'consultar arpitem', so an agent can tell it is querying ARP item data. It does not explicitly differentiate it from sibling tools like the id-based arpitem variant, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of related siblings such as compras_listar_modulo_arp_1_consultar_arp or compras_listar_modulo_arp_2_1_consultar_arpitem_id. There are no conditions, prerequisites, or exclusions to help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. 'Dados públicos' hints at an open read-only profile, but nothing is said about pagination behavior, response format, result limits, or how the redundant pagination parameters interact. For a query tool with 13 parameters, this level of disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; the generic scope ('dados públicos de atas de registro de preços') is front-loaded before the specific action and path. The phrasing 'ação consultar unidades item' is slightly awkward but the description is compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity — 13 parameters, no output schema, no annotations, and a large family of nearly identical ARP sibling tools — this description is incomplete. It does not explain what the response contains, what 'unidades item' means, which parameters are essential and why, or how it differs from sibling endpoints. An agent would struggle to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 31% (4 of 13 parameters described), so the description needed to compensate but never mentions any parameter. The three required parameters (numeroAta, unidadeGerenciadora, numeroItem) are only known from their names, and the confusing six-way pagination redundancy (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina) is entirely unaddressed, creating a real trap for agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta') and resource ('dados públicos de atas de registro de preços') and provides the exact endpoint path. However, the actual meaning of 'consultar unidades item' is left undefined — an agent cannot tell whether this returns participating units (UASGs), units of measure, or item-level details. It also fails to differentiate from the seven closely related ARP sibling tools (arp, arpitem, empenhos_saldo_item, adesoes_item), which all also query public ARP data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the sibling ARP tools such as compras_listar_modulo_arp_2_consultar_arpitem or compras_listar_modulo_arp_4_consultar_empenhos_saldo_item. There are no when/when-not conditions, no mention of prerequisites, and no clues about which endpoint covers which ARP query scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only that this is a public data read of price registration minutes. It does not explain pagination behavior, the effect of the redundant pagination parameters (page/pagina/pageSize/page_size/tamanhoPagina/tamanho_pagina), or how auto_paginar/limite_resultados affect the call. There is no contradiction, but the behavioral disclosure is minimal for a tool with this many parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, naming the resource, the data type, and the endpoint in two lines. It is concise, but it sacrifices useful behavioral context. For its length, it is structured acceptably.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high number of parameters (12), no output schema, no annotations, and a large family of similar ARP sibling tools, the description is too thin. It leaves the agent uncertain about the exact meaning of the required fields, how pagination options interact, and what the response contains. The description needs to clarify usage context and parameter intent to be minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds almost no parameter meaning. The required identifiers (numeroAta, unidadeGerenciadora) are named in the description implicitly through the path, but the description does not explain them. The pagination cluster has three near-duplicate sets (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina), and the description gives no guidance on which to use. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it consults public data of price registration minutes and names the specific endpoint action (consultar empenhos item) on the path /modulo-arp/4_consultarEmpenhosSaldoItem. However, it doesn't define what 'empenhos saldo item' means or what the returned data represents, and the long tool name mostly restates the endpoint. It is distinguishable from siblings only through the endpoint path and 'empenhos' term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus the many sibling ARP tools (e.g., consultar_arp, consultar_arpitem, consultar_unidades_item, consultar_adesoes_item). The description states only what it does, not when it should be preferred or what context requires it. An agent must infer from the name and path that this is for querying commitment balances per item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral disclosures are that the data is public ('dados públicos') and the explicit endpoint path. With no annotations provided, the description carries the full burden, yet it stays silent on pagination defaults, the normalized-vs-original response format, the auto_paginar flag, and the six duplicated pagination parameters. For a 14-parameter tool this is a substantial transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 20-word sentence with no filler, and the endpoint path is useful information. However, it is under-specified for a tool of this complexity — the conciseness comes at the direct cost of omitting parameter, pagination, and usage context that an agent needs to invoke it correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters, 3 required, only 29% schema description coverage, no annotations, and no output schema, this one-liner is far from complete. It does not explain what the adhesions data looks like, which pagination parameters to use, how to page through results, or how this call differs from the ARP module's other item-level endpoints. The domain and endpoint are named, but almost everything an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (4 of 14 parameters), so the description needed to compensate, but it mentions no parameters at all — not even the three required ones (numeroAta, unidadeGerenciadora, numeroItem). It also gives no help disambiguating the confusing pagination aliases (page/pagina/pageSize/page_size/tamanhoPagina/tamanho_pagina). The action name loosely implies an item identifier, but the description itself adds zero parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta') and names the specific action 'consultar adesoes item' with its endpoint path, set in the broad domain of public price-registration data. However, it never explains what 'adesões de item' means or what data the call returns, and the action phrase essentially restates the tool's own name. The generic resource phrase applies to every ARP sibling, so the description provides little differentiation beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many ARP siblings, such as compras_listar_modulo_arp_4_consultar_empenhos_saldo_item or compras_listar_modulo_arp_2_consultar_arpitem. There are no exclusions, prerequisites, or named alternatives. The intended use case is only implied by the tool's name, not stated, which is a serious gap in a family of similarly named endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'consulta dados públicos', which weakly implies a read-only public query, but it says nothing about pagination behavior, response shape, result limits, filtering semantics, or the fact that the query is driven by publication-date range and modality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and scannable, but it spends characters on an endpoint path that largely repeats the tool name. There is no filler, but the conciseness reflects under-specification rather than disciplined prioritization of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — 20 parameters, no output schema, and no annotations — the description is far too thin. An agent needs at least the return type, pagination contract, and required filter semantics to invoke this correctly; the description provides only a generic statement about public contracting data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30%, and the description adds zero parameter-level meaning. With 20 parameters, including required date fields, modalidade, pagination aliases, formato, and filters, the agent receives no help understanding undocumented parameters or resolving the duplicated page/pagina/pageSize fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Consulta dados públicos de contratações públicas'. It is understandable, but it does not differentiate this from sibling tools like compras_listar_modulo_contratos_1_consultar_contratos or pncp_obter_contratacao_completa, and it does not specify that this is the PNCP/Lei 14.133 listing/search entry point beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. With dozens of sibling procurement tools, nothing tells an agent whether to choose this tool over other contract/contracting query tools, or when to prefer a detail endpoint over this listing endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates the operation is a read/query of public data, which is a mild safety signal, but it does not mention response format, pagination, required identifier semantics, error behavior, or any access considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it wastes space repeating the endpoint path that is already encoded in the tool name. It is concise in length yet adds little substance beyond a generic statement about querying public procurement data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, no annotations, and many closely related siblings, this description is incomplete. An agent cannot reliably determine what identifies a single item, how the optional parameters affect results, or when this endpoint is the correct choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description does not compensate. Required parameters 'tipo' and 'codigo' are undocumented in both schema and description, and the description does not explain how 'codigo' relates to 'tipo' (idCompra vs numeroControlePNCPCompra).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Consulta') and a resource ('dados públicos de contratações públicas'), and references the action/endpoint for consulting contracting items. However, it mostly restates what the tool name already says and does not clarify the 'by id' semantics that distinguish this tool from its sibling without '_id'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives, such as compras_listar_modulo_contratacoes_2_consultar_itens_contratacoes_pncp_14133 or the other item-consultation endpoints. The description merely identifies the endpoint path but provides no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says the tool consults public data and names the endpoint. It does not disclose pagination behavior, response format, result limits, or the required date-window semantics, leaving the agent with only a minimal 'read-only query' impression.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and includes the endpoint path. It is efficient and free of fluff, though the phrasing is slightly awkward and repeats 'contratações'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 25 mostly undocumented parameters, no output schema, no annotations, and a large sibling set, this one-sentence description is far from sufficient. It omits required inputs, response shape, pagination behavior, and any selection criteria to differentiate among the many related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description adds no parameter-level meaning. It does not explain the required date range format, filter fields, or pagination aliases; most parameters such as codigoNCM, situacaoCompraItem, and orgaoEntidadeCnpj remain opaque in both the description and the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('consultar itens contratacoes pncp') and a specific resource (items from PNCP public contracts), and it includes the unique endpoint path, which helps distinguish it from sibling tools like 'consultar_contratacoes' and 'consultar_resultado_itens'. However, it does not explicitly clarify whether this is a list/search operation or how it differs from the by-id sibling 'consultar_itens_contratacoes_pncp_14133_id'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or sibling tools, so the agent must infer usage entirely from the name and path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are None, so the description carries the full burden of behavioral disclosure. It conveys only that the operation is a read ('consulta') over 'dados públicos' (public data), which weakly implies no auth and non-mutating behavior. It says nothing about required date-range filtering, pagination behavior, volume of results, or response shape—significant gaps for a listing endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no waste, which is structurally clean. However, the leading clause 'Consulta dados públicos de contratações públicas' is generic filler that restates the domain rather than adding value, and the rest largely repeats the tool name. The endpoint path is the only genuinely informative element.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool—25 parameters, 2 required, 20% schema coverage, no annotations, and no output schema—yet the description is a single sentence. It omits the meaning of the required date range, filter semantics, pagination/aliasing behavior, and result expectations. Inadequate for an agent to invoke it correctly in most realistic scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (5 of 25 parameters documented), so the description was expected to compensate, but it provides zero parameter context. The agent gets no help understanding the two required date parameters, the many filter fields (niFornecedor, orgaoEntidadeCnpj, valorTotalHomologadoInicial, etc.), or the duplicated pagination aliases. The description adds no meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('consulta dados públicos... consultar resultado itens contratacoes pncp') and adds the endpoint path, which gives the agent a concrete handle. However, the core phrase is essentially a direct restatement of the tool name, and the generic opening clause applies to nearly every sibling tool. It does not semantically explain what 'resultado itens contratacoes' means or how it differs from the item-list and item-result-by-id siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives. The description never mentions the _id sibling for retrieving a single result, the item-listing sibling (modulo 2), or any condition that would select this route. With over 100 sibling tools, the complete absence of exclusions leaves the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states that the data is public, which implies a read-only, safe operation, but it says nothing about required date-range handling, pagination behavior, response format options, rate limits, or the effect of parameters like auto_paginar and limite_resultados.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. It front-loads the general purpose and gives the concrete endpoint path. It is concise, though the phrase 'ação consultar pregoes no caminho...' partially restates information already encoded in the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters, two required date parameters, multiple pagination aliases, an output format switch, and no output schema or annotations, this description is far too thin. It does not explain the required date range, how to paginate, what filters exist, or what kind of result to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 31%, and the description adds no parameter-level meaning whatsoever. With 16 parameters, including duplicated pagination fields and required date fields, the description failing to explain any of them leaves the agent without adequate guidance beyond the sparse schema hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly conveys the action ('Consulta dados públicos de licitações e compras legadas') and identifies the specific resource ('pregoes') plus the endpoint path. It is clear about what the tool targets, but it does not explicitly differentiate this from closely related siblings such as consultar_pregoes_id or other legacy modules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many related legacy and PNCP tools. There is no mention of when it should be preferred, when it should not be used, or how it differs from the ID-based pregão variant. The context that it covers public legacy data is implicit only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It reveals only that this is a read ('Consulta') of 'dados públicos', weakly implying no authentication, but says nothing about pagination behavior, result limits, response format, or downstream effects. For a data-query tool this is thin disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is easy to scan, but the clause 'ação consultar material unidade fornecimento no caminho /modulo-material/6_consultarMaterialUnidadeFornecimento' is redundant with the tool name. That redundancy consumes space that could have clarified parameters or usage, though nothing else is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, zero required fields, no annotations, and no output schema, a one-line purpose statement is far from sufficient. An agent cannot determine which pagination parameter to use, whether filters like codigoPdm are meaningful, or what a successful response contains. The description covers only the 'what' and not the 'how' of invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 27% and the tool description adds nothing about parameters. It does not clarify the six near-duplicate pagination parameters (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina), nor the meaning or optionality of codigoPdm and statusUnidadeFornecimentoPdm. With low schema coverage and zero compensation in the description, parameter semantics are effectively absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta') and resource ('dados públicos de materiais para compras públicas; ação consultar material unidade fornecimento') and names the endpoint path. This is enough to tell it apart from the material-module siblings (grupo, classe, item, natureza despesa, características) by its 'unidade fornecimento' focus. However, the second half largely restates the tool name, so it is clear but not exemplary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the six other material-module siblings, nor any exclusion criteria or alternative tool names. Usage context is only implied by the module number and resource name in the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description should carry the burden of behavioral disclosure. It only says it consults public data; it does not mention pagination behavior, the fact that 'auto_paginar' can traverse pages, the 'formato' response options (normalizado/original), filtering semantics, or any rate-limit/error behavior. The schema does contain some hints like default pagination and auto_paginar, but the description itself reveals nothing about operational behavior beyond 'public data', which is thin for a 19-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose, so it is concise. However, it includes the endpoint path verbatim ('/modulo-pesquisa-preco/3_consultarServico') which is redundant with the tool name and does little to help an agent understand semantics. It is not verbose, but its brevity is under-specification rather than efficient information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 19 parameters, only 1 required, no output schema, no annotations, and low parameter coverage, the description is far from complete. It does not explain what data is returned, how to paginate, what filters are available, what 'normalizado' vs 'original' means, or how it relates to the sibling 'servico_detalhe' and CSV tools. An agent would struggle to invoke it correctly beyond providing the required codigoItemCatalogo.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 26%, and the description adds no parameter semantics at all. Many parameters (page, pageSize, tamanhoPagina, poder, esfera, estado, codigoUasg, codigoMunicipio, dataCompraInicio, dataCompraFim, idCompra, dataResultado) are undocumented in both the schema and the description. The description does not clarify the meaning of codigoItemCatalogo, which is required, nor the duplicate pagination fields (page vs pagina, pageSize vs tamanhoPagina). With such low schema coverage, the description needed to compensate but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it consults public price research data via the 'consultar servico' action at the endpoint /modulo-pesquisa-preco/3_consultarServico. It identifies a specific resource (services price research) and the endpoint path, but the phrasing 'ação consultar servico no caminho' is somewhat technical and the description does not clearly distinguish it from sibling tools like compras_listar_modulo_pesquisa_preco_4_consultar_servico_detalhe, which also deals with services. An agent could infer it lists/consults service records, but the distinction from the 'detalhe' variant is not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the alternative 'consultar_servico_detalhe' or the CSV variant 'consultar_servico_csv'. The description implies it is for consulting public service price data, but with 19 parameters and many sibling tools, an agent would need more explicit direction about use cases, e.g., when to use this list/search endpoint vs. the detail endpoint. There is no stated when-not-to-use or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only says the data is 'públicos' and that this is a 'consulta', implying a read operation, but it does not disclose output shape, pagination behavior (auto_paginar/limite_resultados), date filtering, or CSV formatting. This is more than a tautology but far from transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the general purpose, but the second clause merely restates the endpoint already encoded in the tool name. It is concise but does not use the available space to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema and no annotations, this description is inadequate. An agent is given no sense of what the response contains, which optional filters matter, or how pagination and CSV output work. The bare endpoint reference leaves almost all operational decisions to guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 42%, and the description adds nothing about any of the 12 parameters. It does not clarify the duplicated pagination parameters, date formats, or the meaning of codigoItemCatalogo and limite_resultados. With coverage below 50%, the description must compensate, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action—'Consulta dados públicos de pesquisa de preços; ação consultar servico detalhe csv'—and names the exact endpoint. This is enough to identify it as the CSV service-detail variant of the price-research module and to distinguish it from the non-CSV sibling 'compras_listar_modulo_pesquisa_preco_4_consultar_servico_detalhe'. It stops short of a 5 because the meaning of 'servico detalhe' and the CSV return format are only implicit in the tool name and path, not explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The description never tells an agent to prefer this tool over the sibling CSV endpoints, the non-CSV detail endpoint, or the service-list endpoint, and it mentions no prerequisites or filtering context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it adds little: 'dados públicos' implies an unauthenticated read and 'consulta' implies non-mutating behavior. Critically, the tool's signature behavior — returning CSV-format detail data — is never disclosed in the description, only in the name and path. Nothing is said about pagination, response envelope, or the normalizado/original format switch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entry is a single compact sentence with no filler, but its brevity is under-specification rather than compression: the sentence mostly restates components of the tool name (pgc, detalhe, csv, the path) rather than adding meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no annotations, no output schema, and a large sibling cluster of PGC detail/catalogo/agregacao variants, a single generic sentence is inadequate. An agent cannot determine the CSV output behavior, the meaning of the required filters, or how this relates to compras_listar_modulo_pgc_1_consultar_pgc_detalhe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (3 of 12 parameters), so the description must compensate, but it names no parameters at all. The required fields orgao and anoPcaProjetoCompra are unexplained, and six near-duplicate pagination parameters (page/pagina/pageSize/page_size/tamanhoPagina/tamanho_pagina) are left without any hint about which take precedence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('consultar pgc detalhe csv') and gives the API path, and 'consulta dados públicos de planejamento de contratações' provides a broad subject. However, the resource is described so generically that it could apply to nearly every tool in the compras family, and the distinguishing traits — that this is the CSV variant of the PGC detail query — are only implied through the tool name and path, not stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The sibling set includes compras_listar_modulo_pgc_1_consultar_pgc_detalhe (the non-CSV equivalent) plus CSV variants for catalogo and agregacao, but the description never mentions these alternatives or the conditions that would select one over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, and it discloses almost nothing beyond 'public data.' It does not mention the normalizado/original response formats, the auto_paginar behavior, pagination semantics, or the HTTP method implied by the path. The only behavioral signal is that the data is public, which weakly implies read-only safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words and front-loads the meaningful semantic content ('Consulta dados públicos de planejamento de contratações') before the endpoint reference. However, the endpoint clause duplicates information already present in the tool name, so some of the sentence earns no additional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no annotations, no output schema, and a large sibling family, the description is substantially incomplete. It fails to explain the pgc acronym, the meaning of 'detalhe' versus related PGC endpoints, the required parameter semantics, format options, or pagination behavior. While it does identify the domain, it leaves an agent guessing on nearly every decision needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (formato, auto_paginar, limite_resultados are documented; 9 of 12 parameters are bare), which is below the 50% threshold where the description must compensate. The description does not compensate at all: it never explains the required parameters orgao and anoPcaProjetoCompra, and the six redundant pagination aliases (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina) are left completely unexplained. An agent cannot determine from either the schema or description how to construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and domain resource ('Consulta dados públicos de planejamento de contratações'), which places the tool in the procurement-planning space. However, the second clause ('ação consultar pgc detalhe no caminho...') merely restates the tool name and endpoint, and 'pgc' is never expanded. The purpose is clear at the domain level but vague about what 'detalhe' specifically returns versus the sibling catalogo/agregacao/csv variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any alternative. The description does not mention the closely related sibling compras_listar_modulo_pgc_1_1_consultar_pgc_detalhe_csv (same detail data, CSV format), compras_listar_modulo_pgc_2_consultar_pgc_detalhe_catalogo, or compras_listar_modulo_pgc_3_consultar_pgc_agregacao, nor any conditions that would select one over the other. An agent must infer usage solely from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says it consults public data and gives the endpoint path; it does not disclose pagination behavior implied by the 'page', 'pagina', and 'auto_paginar' parameters, whether the result is normalized or raw, or any response format. The phrase 'dados públicos' suggests read-only, but that is limited compared to the behavioral details an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is redundant with the tool name and path, and it does not front-load the most useful information (what a service section is, what filters are available). The 'acao consultar secao servico no caminho...' phrasing is awkward and adds little beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no required parameters, no output schema, no annotations, and a large sibling set, the description is inadequate. An agent cannot tell what filters to use, how pagination works with both 'page' and 'pagina', what the response contains, or how this consultation relates to the other 'modulo_servico' tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43%: 'formato' and 'auto_paginar' are described in the schema, but 'page', 'pagina', 'codigoSecao', 'statusSecao', and 'limite_resultados' are not. The description adds no parameter meaning beyond the schema, and it does not clarify the odd duplication of 'page' and 'pagina'. The description mentions nothing about how 'codigoSecao' or 'statusSecao' affect the query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says the tool consults public data for public procurement services and mentions the action 'consultar secao servico' at the path /modulo-servico/1_consultarSecaoServico. This identifies a specific verb and resource (consulting a service section), but the name 'compras_listar_modulo_servico_1_consultar_secao_servico' largely repeats the description, and the description does not say what a 'secao servico' is or how this differs from the sibling service-section tools (e.g., divisao, grupo, classe, sub_classe, item).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'dados públicos de serviços para compras públicas' but provides no guidance on when to choose this tool over 'compras_listar_modulo_servico_2_consultar_divisao_servico' or other service hierarchy tools. There are no exclusions, prerequisites, or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description carries the full burden. It only says the data are public and gives the endpoint path; it does not disclose pagination behavior, response format, required or meaningful filters, authentication needs, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and contains no filler; the endpoint path is a useful operational detail. However, the brevity comes at the cost of substantive guidance, so it is concise without being complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 0 required parameters, no output schema, and no annotations, a one-sentence description is highly insufficient. It does not explain what a divisão de serviço is, what each filter selects, or how pagination and auto-pagination behave, making correct invocation difficult for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, with three parameters explained in the schema and five undocumented. The description adds no meaning for parameters like codigoSecao, codigoDivisao, statusDivisao, page, or pagina, and therefore fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action, 'consultar divisao servico', and a specific resource, 'divisao servico', placing it in the context of public procurement data. It is distinguishable from sibling service-module tools by its resource level, though the description does not explicitly contrast it with related tools like secao/grupo/classe servico.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as compras_listar_modulo_servico_1_consultar_secao_servico or the other service hierarchy endpoints. The phrase 'dados públicos de serviços para compras públicas' is broad context but does not state conditions, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the full burden of behavioral disclosure. It states that data is public and that the action is 'consultar', indicating a read-only operation, but it does not describe pagination, default response format, auto-pagination behavior, or whether filters like codigoClasse/codigoSubclasse are required. Some behavior is implicit in the schema defaults, but the description itself adds little beyond labeling this a public-data consultation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and reasonably concise, but it is somewhat cluttered by internally repeating 'consulta dados públicos de serviços... ação consultar sub classe servico'. The key endpoint path is included, which is useful, but the sentence could be tighter and more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no required parameters, no output schema, and no behavioral annotations. The description only identifies the endpoint and says data is public. It is missing essential context for correct invocation: which parameters are mutually related, whether subclass consultation requires a class code, how pagination works, and what the response represents. For a moderately complex look-up tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%: formato, auto_paginar, and limite_resultados have descriptions, but page, pagina, codigoClasse, codigoSubclasse, and statusSubclasse have only names and types. The tool description does not compensate by explaining these parameters or their relationships. An agent would not know what codigoClasse versus codigoSubclasse means or how they filter the returned service subclasses.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says the tool queries public data for public procurement services, specifically the 'consultar sub classe servico' action at path /modulo-servico/5_consultarSubClasseServico. This identifies the resource (subclass of service) and the operation (consult/list). However, it does not explain what a 'sub classe servico' is or how it differs from sibling tools like compras_listar_modulo_servico_4_consultar_classe_servico and compras_listar_modulo_servico_6_consultar_item_servico, so differentiation relies on the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternatives are mentioned. The description provides no context about typical use cases, such as filtering services by class code or subclass code, nor does it name sibling tools to avoid confusion. It only states the endpoint path, which does not help an agent choose among the many modulo_servico siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, and it only offers 'dados públicos' as a mild read-only/public-data signal. It does not disclose pagination defaults, how the hierarchical code filters (codigoSecao through codigoServico) combine, whether an empty query returns everything or nothing, or what the response shape is. For an 18-parameter tool this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is compact and front-loads the resource before the path, with no filler words. However, the brevity reflects under-specification rather than careful editing, so it does not earn credit for being a well-crafted summary of useful behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool: 18 parameters with 0 required, 17% schema description coverage, no annotations, and no output schema. The one-line description leaves the agent guessing at the CPC hierarchy semantics, which filters are valid or mutually exclusive, pagination alias behavior, and result limits. The description is far from sufficient to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only formato, auto_paginar, and limite_resultados are described), so the description needed to compensate by explaining the filter codes and pagination aliases. It supplies none: codigoCpc, codigoServico, codigoSecao/Divisao/Grupo/Classe/Subclasse, statusServico, and exclusivoCentralCompras are left entirely undefined, and the duplicated page/pageSize/tamanhoPagina aliases are never clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Consulta') and resource ('dados públicos de serviços para compras públicas'), and identifies the exact action as 'consultar item servico' at the path /modulo-servico/6_consultarItemServico. This is clear enough for an agent to know it queries service-item data, but the phrasing largely restates the tool name and never explicitly distinguishes this endpoint from the sibling service-catalog tools (secao, divisao, grupo, classe, subclasse, und_medida).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not explain when to prefer this endpoint over compras_listar_modulo_servico_1..5/7/8, nor when the pesquisa_preco service endpoints would be more appropriate. There are no exclusions, prerequisites, or mentions of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must carry the behavioral burden. It only says the data is public and gives the endpoint; it does not state that output is CSV, how pagination/auto_paginar behaves, or any filtering semantics. Therefore 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the main purpose, and avoids filler. It is efficiently structured, though the path/action repeats what the tool name already signals. Score 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with no output schema and no annotations, a single sentence identifying domain and path is inadequate. An agent cannot determine return format, pagination behavior, or meaning of most parameters. Score 1.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 27%, and the description mentions no parameters. It does not explain required statusOrgao, the duplicate page/pagina fields, or the filter fields like codigoOrgao/cnpjCpfOrgao. With low coverage and no compensation, this is 1.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Consulta dados públicos de órgãos e unidades administrativas') and identifies the specific endpoint action/path. It does not explicitly differentiate from the sibling compras_listar_modulo_uasg_2_consultar_orgao beyond the CSV suffix/path. Overall the resource and verb are clear, so 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage conditions, prerequisites, or exclusions are provided. The description gives no guidance on when to prefer this CSV endpoint over compras_listar_modulo_uasg_2_consultar_orgao or the UASG CSV variant. The only context is that the data is public and queryable, so 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says 'consulta' and 'públicos', which implies a read-only, non-sensitive operation. It does not explain whether the response aggregates multiple resource types, is paginated, can be large, or requires all four identifiers to resolve a valid ata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant phrasing. It is economical, though its brevity contributes to the lack of specificity rather than solving it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four required parameters, no annotations, and a very large sibling family, this one-sentence description is insufficient for an agent to select and invoke it confidently. The presence of an output schema helps with return shape, but the missing parameter semantics, behavioral detail, and sibling differentiation leave critical decisions to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain cnpj, ano, sequencial_contratacao, and sequencial_ata, but it does not. The parameter names are partly self-explanatory and the phrase 'relacionados a uma ata PNCP' provides domain context, yet no actual semantic detail about how the identifiers combine is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
A description identifies a query operation and ties it to a PNCP ata, but 'recursos públicos' is vague and does not clarify that this is the complete-ata endpoint or which specific resources are included. It also does not distinguish the tool from the many sibling ata-related endpoints, such as pncp_obter_orgaos_compras_atas_arquivos_por_* or pncp_obter_orgaos_compras_atas_contratos_por_*.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling alternatives. The description neither states the intended use case, such as retrieving all related data for one ata, nor excludes more targeted endpoints like ata files, contracts, participants, or history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only indicates a read operation but does not disclose whether the response aggregates all public resources related to the contracting, how the data is structured, or whether pagination or other constraints apply. 'Consulta' implies a read, but little else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words and the operation is front-loaded. However, the brevity contributes to the vagueness; it reads as under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, which reduces the need to document return values, the description still fails to explain what 'completa' adds over the many resource-specific sibling endpoints or what 'recursos públicos' actually includes. With no annotations and a large, confusing sibling family, this is not enough context for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the role and format of cnpj, ano, and sequencial_contratacao. It only says the tool relates to 'uma contratação PNCP,' which weakly implies the key triple, but it does not explain formats, field relationships, or how the sequential number is obtained. The description adds minimal semantic value beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a query operation ('Consulta') and a resource ('recursos públicos relacionados a uma contratação PNCP'), so it is not a tautology. However, 'recursos públicos' is ambiguous—it could mean public files, public data, or public funds—and the description does nothing to distinguish this endpoint from the many siblings that also retrieve PNCP contracting-related resources by cnpj/ano/sequencial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The description does not mention that this 'complete' endpoint should be preferred over resource-specific siblings, nor does it state exclusions or prerequisites. An agent gets no routing support in a large family of similar PNCP endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only indicates a read-only query ('Consulta') and says nothing about what the returned 'recursos públicos' include, whether the full contract object is returned, any authorization requirements, rate limits, or pagination behavior. This adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, which is concise. However, it is under-specified rather than effectively informative, so the brevity comes at the cost of clarity and does not earn its place as a useful definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters, no annotations, and a large sibling set with very similar names, the description is inadequate. It does not clarify how the parameters map to a contract, what data will be returned, or how this tool differs from related tools like pncp_obter_contratacao_completa or pncp_obter_orgaos_contratos_por_cnpj_ano_sequencial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never references cnpj, ano, or sequencial_contrato or explains how they identify the contract. Although the parameter names are somewhat self-explanatory, the description fails to compensate for the missing schema documentation, providing no additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb (Consulta) and a general object (recursos públicos relacionados a um contrato PNCP), which conveys a read/query action. However, 'recursos públicos' is ambiguous and does not make clear this is the complete-contract retrieval tool, nor does it distinguish it from siblings like pncp_obter_orgaos_contratos_por_cnpj_ano_sequencial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling contract-related tools. The description mentions no alternatives, exclusions, or distinguishing conditions, leaving an agent to guess which of the numerous overlapping PNCP tools is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It indicates a read-only public query ('Consulta dados públicos') and gives the path, but it does not disclose response contents, pagination behavior, format handling, or any restrictions. It adds little beyond what the name and schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the path expression is useful. It is concise, though the generic opening wastes a little of the front-loaded space that could have named the actual resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no output schema and no annotations, this description is too thin: it does not say what the returned data represents, which result type to expect, or how the many pagination parameters relate to fetching all parties involved. The sibling list is large and the description offers no differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The required path parameters are already described in the schema (cnpj, anoCompra, sequencialCompra, sequencialAta), and the description only restates their composition in the URL. Since schema coverage is only 54%, the missing pagination-parameter semantics are not compensated for by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it consults public procurement data and provides the exact endpoint path, but the resource it names is generic ('compras públicas, itens, resultados e arquivos') and never explicitly says 'partes envolvidas' except in the path. This does not clearly distinguish it from the many sibling ata/archive/contract tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings such as pncp_obter_orgaos_compras_atas_por_cnpj_anocompra_sequencialcompra_sequencialata or pncp_obter_parte_envolvida_ata. The only usage hint is the endpoint path, which implies route parameters but does not explain selection conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does establish a read-only public-data operation via 'Consulta dados públicos' and the verb 'consultar', which is useful. But it says nothing about pagination behavior despite 9 of 12 parameters being pagination-related, nothing about auto_paginar walking pages or limite_resultados truncating aggregates, and nothing about what the history response contains or whether it returns multiple versions of a purchase record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the endpoint path front-loaded, which is efficient. But the limited space is partially wasted on the generic phrase 'compras públicas, itens, resultados e arquivos', which adds noise rather than precision, and there is no structural separation between what the tool returns and which endpoint it maps to. It is compact but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has high complexity: 12 parameters, no annotations, no output schema, and roughly 50 sibling tools with overlapping scope. Against that backdrop, the one-sentence description is wholly inadequate. An agent lacks the information to select the right pagination parameter, to know whether the history endpoint returns a list of record versions, and to distinguish this call from the quantidade, itens, and arquivos siblings. The description is far from complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate for the other 75% of parameters. It does add meaning to the three required path parameters by embedding them in the endpoint path, which is real value. However, it gives no clarification for the six pagination aliases (page/pagina, pageSize/page_size/tamanhoPagina/tamanho_pagina), leaving an agent to guess whether they are synonyms or distinct behaviors, and it does not explain when to set auto_paginar or formato.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb ('Consulta'), a resource (compras públicas), and the full endpoint path /v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/historico, which disambiguates the required parameters. However, the data-type list 'compras, itens, resultados e arquivos' is generic and overlaps with sibling tools like pncp_obter_orgaos_compras_itens_por_cnpj_ano_sequencial and pncp_obter_orgaos_compras_arquivos_por_cnpj_ano_sequencial, and it never explains what 'historico' actually returns, so an agent cannot tell this apart from the many related endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance whatsoever about when to use this tool versus alternatives. It does not mention the sibling pncp_obter_orgaos_compras_historico_quantidade_por_cnpj_ano_sequencial, the parent purchase endpoint, or any condition that would select this history endpoint over the itens/arquivos/atas variants. For a family with this many near-identical tools, the absence of routing guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, yet it only labels the data 'públicos' and repeats the endpoint. It does not disclose what the response contains (image records, URLs), the effect of the formato parameter, pagination, authentication needs, or the difference between the 'normalizado' and 'original' payloads — all left to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at a single sentence, but it is poorly front-loaded: the generic preamble 'Consulta dados públicos de compras públicas, itens, resultados e arquivos' leads, while the only tool-specific information (the path) trails. That preamble is redundant with the tool name and misleadingly broad for an image-list endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In a family of over 160 similar pncp_* tools, with no annotations, no output schema, and only 20% schema coverage, this single-sentence description leaves an agent without response-shape expectations, pagination behavior, or a clear basis for distinguishing the image-list tool from its per-image and results siblings. The endpoint path is the only concrete anchor provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (just the formato parameter), so the description needed to compensate, but it only mirrors parameter names as path segments. It adds that cnpj, ano, sequencial, and numeroItem are path identifiers of the purchase item, yet does not explain their meaning, format constraints, or how formato affects the response — which the schema already documents anyway.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The specific action is present in the second clause ('ação obter imagem lista') and the full endpoint path distinguishes this tool from siblings such as the per-image variant ending in _sequencialimagem. However, the opening clause 'Consulta dados públicos de compras públicas, itens, resultados e arquivos' is generic enough to describe any of the 160+ sibling tools and inaccurately implies this tool returns results and general files, which this image-list endpoint does not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over closely related siblings like pncp_obter_orgaos_compras_itens_imagem_por_cnpj_ano_sequencial_numeroitem_sequencialimagem or pncp_obter_orgaos_compras_itens_por_cnpj_ano_sequencial_numeroitem. The path template implies the call shape, but the description never states the conditions that select this tool, lists no alternatives, and gives no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Consulta dados públicos' and gives the endpoint path; it does not mention read-only behavior, response format, pagination behavior, default values, or limits, leaving the agent to infer operational details from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence and the endpoint path is valuable, front-loaded information. Minor redundancy ('dados públicos de contratos públicos') and the vague list of data types keep it from being perfectly crisp, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 12-parameter read tool with no output schema and no annotations, so the description needed to provide more operational context. It does not explain the history semantics, pagination behavior, response format, or the relationship to sibling contract/historico endpoints, leaving the agent under-equipped for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 25% schema description coverage, the description needed to compensate, but it only maps cnpj, ano, and sequencial through the path template. It adds no meaning to the pagination parameters (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina), auto_paginar, formato, or limite_resultados, and it does not say which pagination alias is preferred.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a query verb ('Consulta') and identifies the resource via the endpoint path /v1/orgaos/{cnpj}/contratos/{ano}/{sequencial}/historico, and it lists included data types (contracts, empenhos, terms, files). However, it never explains what 'historico' returns (revisions, full history, or current snapshot), and it does not distinguish this tool from the plain contract endpoint or the historico_quantidade sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of siblings such as pncp_obter_orgaos_contratos_por_cnpj_ano_sequencial or pncp_obter_orgaos_contratos_historico_quantidade_por_cnpj_ano_sequencial. The word 'historico' in the name implies the use case, but the description itself provides no selection conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses only that this is a read/query operation ('Consulta') and shows the request path; it says nothing about response shape, pagination, error or not-found behavior, authentication needs, or the meaning of the 'formato' response option. For a data-retrieval tool with zero annotation coverage, this is thin 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence and the path template is genuinely useful. However, it contains wasted words: 'dados públicos de contratos públicos' is redundant, and the 'empenhos, termos e arquivos' clause is irrelevant noise for this specific endpoint. It is short but not tightly purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (4 required), no annotations, and no output schema, the description leaves critical gaps: no differentiation from the sibling list endpoint, no parameter semantics for four required fields, and no hint of the response format. The only substantive content is the URL template, which is insufficient context for an agent to invoke this tool confidently over its near-identical sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% — only 'formato' has an explanatory description. The tool description does not explain cnpj, ano, sequencialContrato, or sequencialInstrumentoCobranca; it merely echoes them inside the URL template, relying on the Portuguese parameter names to carry the meaning. Since coverage is low, the description should compensate, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('consultar') and resource ('instrumento cobranca') and includes the complete URL path, so an agent can tell this targets a collection-instrument sub-resource of a contract. However, the lead-in clause claims it consults 'empenhos, termos e arquivos' (commitments, terms, and files), which are not the resource of this endpoint — that boilerplate appears copied from a broader contract endpoint and muddies what this tool actually returns. It also does not differentiate this single-instrument variant from the sibling list endpoint pncp_obter_orgaos_contratos_instrumentocobranca_por_cnpj_ano_sequencialcontrato.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The close sibling pncp_obter_orgaos_contratos_instrumentocobranca_por_cnpj_ano_sequencialcontrato retrieves the same resource family (without the sequencialInstrumentoCobranca), and this tool is clearly the item-level lookup, but the description never states that distinction or any when/when-not conditions. Usage must be entirely inferred from the path shape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 conveys that the data is public and the operation is a consult/read, but it says nothing about pagination behavior, output shape, result limits, or whether the response is aggregated. This is minimal behavioral disclosure beyond the basic read intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the second clause largely restates the tool name and endpoint path in an awkward way. It could be more concise and clearer by directly stating what the consolidated units data represents. The path information is useful but not well integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 11 parameters, no annotations, and no output schema, yet the description provides no information about pagination, result contents, or the meaning of 'consolidado/unidades'. An agent cannot reliably anticipate the response or choose between the many pagination parameters. The description is far too sparse for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 27%, and the description does not explain the meanings or relationships of cnpj, ano, page, pagina, pageSize, or the pagination aliases. The endpoint path echoes {cnpj} and {ano} but adds no semantic detail such as formats, defaults, or constraints. With 11 parameters and low schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation as consulting public annual procurement plan data and includes the exact endpoint path with cnpj, ano, and unidades. It is distinguishable from sibling tools like pncp_obter_orgaos_pca_consolidado_por_cnpj_ano because it names the 'consolidado/unidades' path. However, it does not explain what 'unidades' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as the consolidated PCA endpoint, the CSV variant, or the sequential variants. It only says it consults public data, leaving selection to inference from the tool name. No exclusions or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states that the action is a 'consulta' (consultation), which implies a read operation, but it does not disclose required identifier relationships, possible errors, whether the 'codigo' or 'idCompraItem' inputs are validated, or what the response contains. The endpoint path is repeated but adds no behavior beyond a URL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and reasonably short, but it wastes space by embedding the full endpoint path and repeating the tool name almost verbatim. It is not misleading but it is mostly a restatement of the name plus a URL.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should explain what a 'resultado item' is, how to construct the required 'tipo' and 'codigo' pair, and what the response represents. It does none of this. The context of many sibling tools with similar names makes this lack of differentiation costly: an agent cannot reliably distinguish this from the sibling without the id (compras_listar_modulo_contratacoes_3_consultar_resultado_itens_contratacoes_pncp_14133) or from the item-without-result variant (2_1).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%, so the description must compensate for the undocumented parâmetros. It does not: the description mentions no parameter meanings, formats, or dependencies. The schema already provides enum definitions for 'tipo' and 'formato' and a date format for 'dataAtualizacaoPncp', but the crucial relation between 'tipo' and 'codigo' (e.g., which code format is expected for each tipo) is left unexplained. Because the schema covers two of five parameters with descriptions and all have structural definitions, this is a low 3 rather than a 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (public contracting data) and the specific action (consultar resultado itens contratacoes pncp 14133 id) with an endpoint path, so an agent can tell it is a query/consultation tool. However, it does not explain what 'resultado itens contratacoes' means or what data is returned, and it does not distinguish it from closely named siblings such as compras_listar_modulo_contratacoes_2_1_consultar_itens_contratacoes_pncp_14133_id or compras_listar_modulo_contratacoes_3_consultar_resultado_itens_contratacoes_pncp_14133.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. The description does not mention that this is the 'by id' variant, that it should be used after obtaining an id from a list operation, or when to use the non-id sibling. The 'id' in the name and path is implicit but never explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only says it queries public data and gives the path; it does not mention that this is a read-only operation, what data is returned, whether historical/legacy data is normalized, or how the 'formato' parameter affects the payload. These are meaningful gaps given that a mutation-like behavior cannot be ruled out from the description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the formatting is awkward: the path uses mixed casing ('3.1_consultarPregoes_Id') and is presented in a way that reads like raw metadata rather than a polished explanation. It is not verbose, but it also does not use its brevity to add meaningful guidance, so it is merely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of many similar legacy-module siblings, the description should at minimum clarify that this is the individual pregão query, who/what the required id refers to, and what the response contains. It does none of those things, and there is no output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'id_compra' as a required string but gives it no description, so the definition itself does not clarify it. 'formato' has an enum and default in the schema, and 'dt_alteracao' has a date format hint, which covers meaning reasonably. Overall the description adds no parameter-level meaning, and since schema coverage is only 67%, the undocumented 'id_compra' remains ambiguous beyond what its name suggests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it consults public legacy bidding/purchase data via 'consultar pregoes id' on the path '/modulo-legado/3.1_consultarPregoes_Id', which makes the general purpose clear. However, it does not explain what makes this tool distinct from its siblings, especially the closely related 'compras_listar_modulo_legado_3_consultar_pregoes' and the item-level 'consultar_itens_pregoes_id', so the agent still has to infer the exact scope from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool instead of the sibling tools. The name and schema imply it is for looking up a single pregão by id, but the description does not state that, nor does it contrast with the collection endpoint or the related items endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that it consults public data and names the endpoint path. It does not disclose output format, pagination behavior, CSV characteristics, or any other operational caveats that the agent should know before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action, but it wastes its second clause re-stating the endpoint path that is already in the tool name. It is concise but under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 21 parameters, many redundant pagination options, and no annotations or output schema, the description is far too thin. It does not clarify which parameters are mutually exclusive, whether this CSV variant returns a file or JSON, or how it differs from the sibling non-CSV query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 24%, but the schema itself uses descriptive names (codigoItemCatalogo, codigoPdm, formato, auto_paginar, limite_resultados) and a few parameters already have descriptions. The tool description adds nothing about how parameters relate to the query. Given the schema provides moderate self-documentation, a baseline 3 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it queries public price research data and mentions the specific action/path, but it doesn't clearly explain what this tool returns or how it differs from the closely related sibling 'compras_listar_modulo_pesquisa_preco_1_consultar_material' (non-CSV) or the '_detalhe_csv' variants. It identifies a resource but not its distinctive output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this CSV variant over the non-CSV price research material endpoint, nor when to use the 'detalhe' counterparts. With a huge sibling list, an agent gets no help selecting among similar options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior itself. It only says 'consulta dados públicos' and mentions the CSV action, but does not explain pagination behavior, output format, response size, or whether results are limited or aggregated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the general purpose, but its brevity comes from omitting essential details rather than from tight but complete writing. It earns a pass for no wasted words, but not more.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 19 parameters, no annotations, no output schema, and only 26% schema coverage, the description is far from viable. It does not explain required inputs, filter semantics, pagination controls, or the CSV response behavior, leaving an agent with little reliable guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 26%, and the description adds no parameter-level context. The required parameter 'codigoItemCatalogo' is entirely unexplained, and the many pagination and filter parameters are left to the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: it consults public price-research data via a service CSV endpoint, and names the exact path. It is distinguishable as the CSV variant of the service query, though it does not explicitly differentiate from the closely related non-CSV sibling 'consultar_servico'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over the non-CSV sibling or the 'servico_detalhe_csv' alternative. The description implies general usage for querying service price data, but gives no conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention 'dados públicos' and the CSV endpoint, but it does not disclose pagination behavior, the meaning of the CSV/aggregation output, whether formato changes the response shape significantly, or what auto_paginar does in terms of making multiple calls. The description is mostly a restatement of the path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single reasonably concise sentence, but it is awkwardly structured, mixing a human-readable purpose with an endpoint path and action name. It is neither particularly well front-loaded nor does it provide strong additional signal beyond the name and path.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description is incomplete. It does not clarify the meaning of 'agregação CSV', how pagination works, how auto_paginar behaves, or what the normalized versus original formats mean in practice. The agent would likely need to inspect schemas or make exploratory calls to safely use the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 43%, and the description only mentions 'orgao' and 'ano' implicitly via 'planejamento de contratações' without explaining any parameter semantics. However, three parameters (formato, auto_paginar, limite_resultados) already have inline descriptions in the schema, and the remaining parameters (orgao, ano, page, pagina) have names that are reasonably self-explanatory. The description adds marginal value, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('consulta dados públicos de planejamento de contratações; ação consultar pgc agregacao csv'), so it is not a bare tautology. However, it does not explain what 'agregação' aggregates by (e.g., orgão, ano, UASG, item), making it hard to distinguish from sibling tools like consultar_pgc_detalhe or consultar_pgc_agregacao without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives, such as compras_listar_modulo_pgc_3_consultar_pgc_agregacao or the other PGC CSV variants. It only mentions the endpoint path, not the intended use case or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden, and it only conveys that this is a query of public data. It does not disclose pagination behavior (despite six pagination parameters), auto-pagination semantics, the 'atas' domain meaning (registro de preços records in PNCP context), or what the response contains. The read-only nature is only implied by the word 'consulta'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence and the path info is front-loaded in the second clause. However, the first clause is reusable boilerplate that wastes space without adding discriminating value, so it is not as tight as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 12 parameters, no annotations, no output schema, and roughly 150 siblings including several ata-specific endpoints. The one-line description is grossly inadequate for that context: an agent cannot determine which pagination parameter to use, whether this returns a list or a single item, or how the 'atas' concept relates to the other ata sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (3 of 12 parameters described), so the description must compensate, but it adds nothing about any parameter. It does implicitly document the three required path parameters (cnpj, anoCompra, sequencialCompra) by showing them in the URL, which is marginal value, but the confusing page/pagina/pageSize/page_size/tamanhoPagina/tamanho_pagina alias cluster remains entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('ação consultar atas') and the exact endpoint path (/v1/orgaos/{cnpj}/compras/{anoCompra}/{sequencialCompra}/atas), which tells the agent this returns atas for a given purchase. It is clear but does not explicitly differentiate from the near-identical sibling pncp_obter_orgaos_compras_atas_por_cnpj_anocompra_sequencialcompra_sequencialata, and the opening clause ('compras públicas, itens, resultados e arquivos') is generic boilerplate that somewhat muddies the specific resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 its close siblings, such as the variant that requires sequencialata, or the arquivos/contratos/partesenvolvidas ata endpoints. The path implies it is the list-level atas endpoint, but the description never states this selection criterion or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it discloses only 'Consulta dados públicos' and the endpoint path. It is silent on response shape, pagination semantics, what formato normalizado vs original changes, whether auto_paginar chains multiple requests, and how the five pagination parameter variants relate. For a read tool with zero annotation scaffold this is thin, though not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no outright waste, but the prime front-loaded position is occupied by generic boilerplate ('contratos públicos, empenhos, termos e arquivos') that blurs scope. The only specific information, the endpoint path, is relegated to the trailing clause. Leading with the path and the specific resource would be clearer without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, 25% schema coverage, no output schema, and no annotations, the description must carry heavy weight but delivers only the endpoint path and a vague data-type list. Missing are the contents of a 'contratação' payload, which pagination arguments to pass, how anoContratacao/sequencialContratacao relate to the identifiers used by sibling tools, and expected output. Substantially under-specified for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (formato, auto_paginar, limite_resultados are documented). The description compensates partially by encoding the path template, which tells the agent that cnpj, anoContratacao, and sequencialContratacao are resource identifiers. However, it offers no help on the confusing duplicate pagination parameters (page, pagina, pageSize, tamanhoPagina, page_size, tamanho_pagina) and doesn't explain why pagina is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the verb ('Consulta') and pins the resource to an exact endpoint path, '/v1/orgaos/{cnpj}/contratos/contratacao/{anoContratacao}/{sequencialContratacao}', which is genuinely useful. However, the opening clause claims the tool covers 'contratos públicos, empenhos, termos e arquivos' — a scope far broader than the endpoint suggests — and never explains what 'contratação' data is or how it differs from sibling tools like pncp_obter_orgaos_contratos_por_cnpj_ano_sequencial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no alternatives named. Given a sibling list full of overlapping endpoints (contratos, empenhos, termos, arquivos, contratação), the agent is left to infer the tool's role solely from the path parameters anoContratacao/sequencialContratacao. The only usage signal is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states that the data is public and reveals the endpoint path; it does not clarify that the response is a simple count, that it is a read-only operation, or how the 'formato' parameter changes the response. The broad claim that it queries 'empenhos, termos e arquivos' is actually behaviorally misleading, since this endpoint only returns the quantity of terms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single run-on sentence with redundant wording ('públicos' appears twice in 'dados públicos de contratos públicos') and leads with a vague generic clause before reaching the specific action. The precise purpose is buried after a semicolon rather than front-loaded, forcing the agent to parse an inaccurate preface to find the useful endpoint information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, no annotations, and a large sibling family, the description is under-equipped. It does not explain what the quantity response represents, what 'termos' are in this domain (contract amendments), or which of the many similar pncp_obter_orgaos_contratos_* endpoints this one should be preferred over. An agent would need significant inference from the tool name alone to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% — only 'formato' is documented in the schema. The description must compensate for cnpj, ano, and sequencial, but it merely echoes them inside the path without explaining semantics (e.g., that sequencial is the contract sequential number, what CNPJ format is accepted, or valid year ranges). The path mapping is helpful but falls short of defining each parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The second clause states a specific action with a concrete resource: 'ação consultar quantidade termos contrato no caminho /v1/orgaos/{cnpj}/contratos/{ano}/{sequencial}/termos/quantidade'. The endpoint path unambiguously identifies the resource and scope, distinguishing it from siblings like the terms-list or term-files endpoints. However, the opening clause 'Consulta dados públicos de contratos públicos, empenhos, termos e arquivos' is a generic umbrella statement that lists data types this endpoint does NOT return, which slightly muddies the clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description never names siblings such as pncp_obter_orgaos_contratos_termos_por_cnpj_ano_sequencial (term list) or pncp_obter_orgaos_contratos_arquivos_quantidade_por_cnpj_ano_sequencial (file count), nor does it state the key routing rule: use this when only a count of contract terms is needed rather than the terms themselves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, but it only discloses that the data is public. It says nothing about pagination behavior despite six pagination-related parameters in the schema, nor about result format, aggregation, or rate/limit constraints, and there is no output schema to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loads the resource and API path, which is structurally clean. However, for a tool with 16 parameters and no annotations, the brevity reads as under-specification rather than disciplined conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters, no annotations, and no output schema, this one-sentence description leaves too much to inference: what the returned records look like, how the page/pageSize aliases behave, and what filters are meaningful. An agent could not confidently construct a correct call from this text alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 44%, below the 50% threshold, so the description must compensate for the undocumented parameters, but it adds zero parameter-level meaning. The required date-range filters (dataVigenciaInicialMin/Max) and the duplicated pagination aliases remain unexplained in the free text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Consulta dados públicos de atas de registro de preços') and even states the API path (/modulo-arp/1_consultarARP), so an agent can tell this is the ARP listing operation. It differentiates from the by-ID and item-level siblings by naming the resource as price registration records, though it does not explicitly contrast itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool versus the many related siblings, such as compras_listar_modulo_arp_1_1_consultar_arp_id (by ID) or compras_listar_modulo_arp_1_2_consultar_arp_fim_vigencia (by end of validity). The 'dados públicos' phrase hints at a scope but provides no exclusions, prerequisites, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. It only implies a read-only, publicly accessible operation through 'Consulta' and 'dados públicos', but says nothing about pagination, response shape, error behavior, or how the tipo values alter the call. The value added beyond the tool name is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the second clause redundantly restates the tool name before adding the endpoint path. The phrase 'contratações públicas' appears twice, and while the path is useful, it could have been integrated more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, 50% parameter coverage, and a large sibling set, the description leaves too much unspecified: the meaning of the required parameters, the difference from the non-_id variant, and the return format. An agent cannot safely invoke this tool on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, covering only formato and dataAtualizacaoPncp. The two required parameters, tipo and codigo, are undocumented in the schema, and the description names no parameters at all. An agent cannot infer what values tipo accepts or what format codigo requires.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta') and resource ('dados públicos de contratações públicas'), giving a clear purpose. However, the second clause ('ação consultar contratacoes pncp 14133 id') merely restates the tool name and provides no differentiation from the sibling without the '_id' suffix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus its near-identical sibling compras_listar_modulo_contratacoes_1_consultar_contratacoes_pncp_14133 or the related _itens_ variants. The intended lookup-by-id usage is only implied by the tool name and required parameters, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, yet it only states that the data is public and gives the endpoint path. It does not disclose pagination behavior (page/pageSize, auto_paginar), result limiting (limite_resultados), the response format toggle (formato), or the meaning of the mandatory date filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with the core purpose front-loaded before the path detail. It loses a point only for mild redundancy ('dados públicos de contratos públicos') and for devoting half the sentence to a path that adds little semantic value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 20-parameter tool with no annotations and no output schema, yet the description is one thin sentence. Missing are required-filter semantics, pagination and results behavior, routing guidance versus the ID/end-of-vigencia siblings, and any sense of what the response contains — all of which an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (5 of 20 parameters documented), well below the 50% threshold, so the description should compensate by explaining key parameters. It does not: no mention of the required codigoOrgao, the required date range, or any of the many optional filters such as numeroContrato or niFornecedor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta') and resource ('dados públicos de contratos públicos'), and it names the API path. However, it does not differentiate this listing tool from the closely related siblings compras_listar_modulo_contratos_1_1_consultar_contratos_id and compras_listar_modulo_contratos_1_2_consultar_contratos_fim_vigencia, so an agent cannot distinguish variants from the text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 — there is no mention of the ID-specific variant, the fim_vigencia variant, or item-level contract tools. The only hint comes indirectly from the required parameters (codigoOrgao plus date range), which imply a filtered list search, but the description itself provides no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral burden, but it only establishes that the data is public and the operation is a read, and it repeats the endpoint. It discloses nothing about pagination or auto_paginar behavior, the 'normalizado' vs 'original' response formats, or result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single compact sentence with no filler, which is structurally clean. However, the latter clause ('ação consultar itens pregoes no caminho /modulo-legado/4_consultarItensPregoes') largely re-states information already encoded in the tool name, and the most decision-relevant facts are absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter tool with duplicated pagination aliases (page/pagina, pageSize/page_size/tamanhoPagina/tamanho_pagina), no annotations, and no output schema, a single generic sentence is not enough. An agent gets no guidance on which parameter group to use, what the date range scopes, or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 36%, so the description should compensate for the nine undocumented parameters, yet it explains none of them. The schema itself documents the required date formats and a few options (formato, auto_paginar, limite_resultados), while the description adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (consultar/consulta) and resource (itens pregoes from legacy licitações/compras data) and identifies the endpoint path. It does not, however, differentiate this list-style tool from its close sibling compras_listar_modulo_legado_4_1_consultar_itens_pregoes_id, so it lacks the sibling distinction needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the _id sibling variant, when not to use it, or what conditions (e.g., having a date range) select it. An agent must infer usage entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only reveals that the data is 'público' (public) and discloses the endpoint path. It says nothing about pagination semantics, the auto-paginar behavior, response format, or how filters combine — critical traits for a listing endpoint with 20 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with the verb and path front-loaded. However, it is internally redundant — 'consulta' appears twice ('Consulta... ação consultar') and 'compras' appears twice — and the generic first clause adds little beyond the more specific second clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 20 parameters, no output schema, and no annotations, this two-clause description is materially incomplete. It omits the required year parameter (dt_ano_aviso), the pagination contract, and any indication of what the response contains, so an agent cannot reliably construct a correct call from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 35% (7 of 20 parameters have descriptions), below the 50% threshold, so the description must compensate for the undocumented parameters. It does not mention a single parameter, leaving the required dt_ano_aviso and the duplicated pagination families (page/pagina, pageSize/page_size, tamanhoPagina/tamanho_pagina) unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('consulta'), resource ('dados públicos de licitações e compras legadas'), and a scoped action ('consultar compras sem licitacao') with the API path for disambiguation. This distinguishes it from the licitação, pregão, and item-level sibling tools. It stops short of a 5 because it never explicitly contrasts with the by-ID sibling (modulo_legado_5_1_consultar_compra_sem_licitacao_id), so the list-vs-detail distinction must be inferred from the tool name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any of its many siblings. There are no stated conditions, exclusions, or alternative tool names, so an agent must infer selection purely from the tool name and the path embedded in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions that the data is 'públicos' and the action is a consulta, implying a read operation, but it does not disclose pagination behavior, response format, whether filters are required, or any limits. The schema indicates pagination has two distinct parameters (page and pagina), suggesting behavioral ambiguity that the description does not clarify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is not front-loaded with the most decision-relevant information: it mixes the generic domain phrase with the specific action and path. It earns its place for stating the endpoint, but it lacks scoping information that would help an agent choose it among many sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no annotations, no output schema, and a large sibling family, this description is incomplete. It does not explain how to structure a query, whether codigoClasse/codigoGrupo are required in practice, what the response contains, or how pagination works. An agent cannot confidently invoke it correctly based on this text alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% and the description does not compensate. The description does not explain codigoGrupo, codigoClasse, statusClasse, or the distinction between page and pagina. The schema documents formato and auto_paginar and limite_resultados, but six parameters remain undocumented, and the description adds no semantic value for them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Consulta dados públicos de materiais para compras públicas' and specifies the action 'consultar classe material' with the endpoint path. It is distinguishable from sibling material tools because it explicitly names the classe material action and its path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the sibling material tools like compras_listar_modulo_material_1_consultar_grupo_material or compras_listar_modulo_material_4_consultar_item_material. The endpoint path is provided but no context, filtering strategy, or alternative routing is described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It signals a read-only public query through 'consulta dados públicos', but says nothing about pagination behavior, response shape, output normalization, rate limits, or how the optional filters affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with no filler, and the endpoint path is included usefully. It is efficient, although the action phrase partly restates the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no output schema, no annotations, and low schema description coverage, this description is far from complete. It provides a basic purpose and endpoint path, but an agent cannot meaningfully filter, paginate, or interpret results from this information alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 21%, and the description adds no parameter meaning at all. Key filters like codigoPdm, statusPdm, codigoGrupo, and codigoClasse are undocumented, so an agent cannot infer what data each parameter selects from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'consulta dados públicos de materiais para compras públicas' and identifies the exact API action/path. However, 'pdm material' is left unexplained and the description does not distinguish this tool from sibling material tools such as consultar_item_material or consultar_grupo_material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of the many related material, grupo, classe, or item endpoints. No alternatives, exclusions, or intended use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not disclose pagination defaults, the behavior of the many duplicate pagination parameters, whether filters are required, or what the normalized vs original response formats entail. With no annotations and a 12-parameter schema, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and reasonably compact, but it front-loads the repeated module name and path, which add little value, and it lacks structured detail about filters or output. It is not verbose, but it is not optimally organized for agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters, no output schema, no annotations, and many sibling tools, the description is incomplete. It fails to clarify which parameters are meaningful, how pagination works across the duplicate page/pageSize fields, and what the response contains, so an agent cannot reliably invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description adds almost no parameter meaning beyond naming the endpoint operation. The description mentions 'material natureza despesa' but does not explain codigoNaturezaDespesa, statusNaturezaDespesa, or the pagination parameters, leaving the agent to guess which of the duplicated page parameters to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta') and resource ('dados públicos de materiais para compras públicas') and identifies the operation 'consultar material natureza despesa' with its API path. However, it doesn't differentiate itself from the many sibling material/despesa tools, and the operation name is oblique enough that an agent may not understand exactly what data is returned without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus siblings such as compras_listar_modulo_material_4_consultar_item_material or compras_listar_modulo_servico_8_consultar_natureza_despesa_servico. It only identifies the path, so an agent cannot determine selection criteria from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 that this is a read action on public data, which is useful, but it says nothing about pagination behavior, auto-pagination semantics, result limits, output format behavior, or how the multiple page-related parameters interact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, compact and reasonably front-loaded with the core purpose. The path is a useful concrete anchor, though the clause 'ação consultar material caracteristicas' partly repeats what the name already encodes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no output schema, and no annotations, this description is too thin. An agent cannot determine pagination conventions, how to filter by codigoItem, what the normalized versus original response distinction means in practice, or what the returned data will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30%, and the description adds no parameter-level meaning. With ten parameters including duplicated pagination fields (page/pagina, pageSize/page_size, tamanhoPagina/tamanho_pagina), the description fails to compensate for the schema's sparse documentation or clarify which parameters should actually be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (consultar) and resource (material characteristics for public procurement), and even provides the API path. It is distinguishable from sibling material-module tools by the explicit 'caracteristicas' focus, though it does not explicitly contrast itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of related material modules (e.g., item material, grupo material, classe material) or other listing tools. The description only states what it does, not when it should be selected or what filters/parameters are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses almost nothing beyond 'public data' and the path. It does not state the CSV response format, pagination behavior, what the formato parameter affects, or any other runtime characteristics. The description is accurate but not contradictory to annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and the purpose is front-loaded. But the second clause repeats the action name and endpoint path already contained in the tool name, making it partially redundant rather than adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 12-parameter tool with no annotations, no output schema, and many closely related siblings in the same module. A one-sentence description cannot cover what an agent needs: which pagination parameter to use, what the CSV output looks like, or how this differs from the non-CSV variant. The description is materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 42% (5 of 12 params documented), leaving page/pagina/pageSize/page_size/tamanhoPagina/tamanho_pagina and codigoItemCatalogo undocumented. The description adds zero parameter semantics and does not compensate for this gap, which is especially problematic given the three duplicate pagination parameter groups.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Consulta) and a resource (dados públicos de pesquisa de preços / material detalhe csv) and gives the exact endpoint path. However, it largely restates the tool name and doesn't explicitly clarify that this is the CSV-output variant versus the non-CSV sibling (compras_listar_modulo_pesquisa_preco_2_consultar_material_detalhe), so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description never tells the agent when to prefer this tool over the non-CSV detail variant, the base material tool, or the serviço equivalents — the naming convention alone must carry that routing burden.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only conveys that the operation queries public data and involves a CSV endpoint. It does not mention pagination behavior, the required statusUasg parameter, output format options like normalizado vs original, or whether the result is truly CSV rather than a JSON envelope. These are material gaps for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with the main purpose front-loaded and no filler. The second clause restates the endpoint path that is already visible in the tool name, which is mildly redundant, but the overall structure is compact and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no annotations, no output schema, and many near-identical siblings, this one-line description is far from complete. It omits the required filter, response format semantics, pagination behavior, and any differentiation from the non-CSV UASG sibling. An agent cannot reliably select and invoke this tool correctly based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (3 of 12 parameters have descriptions), so the tool description must compensate, but it does not. It gives no explanation of filters such as siglaUf, codigoUasg, cnpjCpfOrgao, cnpjCpfOrgaoSuperior, cnpjCpfOrgaoVinculado, or the required statusUasg. The only domain hint is that the data concerns órgãos and unidades administrativas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description has a clear verb and resource: 'Consulta dados públicos de órgãos e unidades administrativas' tells the agent this is a read-only query about agencies and administrative units. It also names the endpoint path, but it does not explicitly differentiate this CSV variant from the sibling compras_listar_modulo_uasg_1_consultar_uasg, so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool instead of the many related siblings such as compras_listar_modulo_uasg_1_consultar_uasg or compras_listar_modulo_uasg_2_1_consultar_orgao_csv. It does not state that this is the CSV-export destination, nor does it mention any alternative. Usage must be inferred entirely from the tool name and endpoint path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 reveals that the data is public and that the action lists records, but it does not explain pagination, response format, default/optional filtering behavior, or anything about the returned payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the main purpose and endpoint, with no wasted words. However, it is under-specified, so the brevity reflects omission rather than efficient completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, and with only a 33% schema-description coverage, this sparse description leaves the agent without information about response shape, pagination, or filter behavior. For a simple list endpoint it is barely adequate but missing meaningful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one of the three parameters (formato) has a schema description, so description-level coverage is low. The tool description adds no meaning for statusAtivo or tipoAmparoLegalId, and the property names alone are not enough to explain valid values or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('listar registros') and the target resource ('amparos legais') with its API path, so an agent can see this is a list operation. It does not explicitly contrast with pncp_obter_amparos_legais_por_id, but the path and 'listar' make the distinction largely inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this list endpoint versus the sibling pncp_obter_amparos_legais_por_id, nor any mention of appropriate use cases or exclusions. The usage is only implied by the verb 'listar'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and adds only that the data is 'público' (public/read-only) and the endpoint path. It discloses nothing about list behavior — whether zero params returns the entire dataset, pagination, response format, or rate/volume limits — which is especially costly given there is no output schema to fall back on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and reasonably short, but the two clauses are redundant: 'modalidades e critérios de julgamento' is restated by 'obter criterios julgamento por modalidade.' The path detail is useful but appears at the end instead of front-loading the scoping constraint, and the Portuguese phrasing is somewhat awkward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with all-optional parameters, no output schema, and a near-identical get-by-id sibling, the description omits critical details: no-argument behavior, the meaning of the criterioJulgamentoId filter, response contents, and how to choose between this and pncp_obter_modalidade_criterio_julgamento_por_modalidadeid_criteriojulgamentoid. An agent cannot fully determine correct invocation from this text alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. The phrase 'obter criterios julgamento por modalidade' clarifies that modalidadeId acts as a filter, but criterioJulgamentoId is never explained, and the only documented parameter (formato) is described solely in the schema enum. Two of three parameters remain under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta dados públicos') and resource (modalidades e critérios de julgamento), and the second clause pins the action to 'obter criterios julgamento por modalidade' with the path /v1/modalidade-criterio-julgamento. This makes it distinguishable from the other listers (pncp_listar_modalidades, pncp_listar_criterios_julgamentos), which target separate datasets. However, the first clause is slightly ambiguous and could be read as listing two independent datasets rather than their association.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 list endpoint versus the nearly identical sibling pncp_obter_modalidade_criterio_julgamento_por_modalidadeid_criteriojulgamentoid. The description also fails to note that all parameters are optional filters, so an agent cannot tell whether calling with no arguments returns the full set or whether the get-by-id sibling is the better choice for a targeted lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure, but it only states that the tool consults public purchase documents and exposes the endpoint path. It does not clarify that the result is a list of files, whether pagination applies, or what 'normalizado' versus 'original' means for the response; the phrase 'itens, resultados e arquivos' may even overstate what this endpoint returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and contains a useful endpoint path, but the first clause is generic and low-value. The key action and resource appear only after a vague lead-in, making the structure less effective than a single crisp sentence stating exactly what is returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, no annotations, and many near-twin sibling tools, the description is insufficient. It omits the response shape, pagination behavior, format semantics, and any distinction from the quantity or specific-document variants, so an agent would have to guess at important invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the tool description does not compensate for the gap. It implicitly maps cnpj, ano, and sequencial to URL path parameters, but the pagination aliases, page/pageSize variants, formato, auto_paginar, and limite_resultados are left unexplained, so an agent cannot confidently choose parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('consultar informacoes documentos compra') and includes the exact endpoint path /v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/arquivos, so an agent can identify the resource. However, the opening phrase 'dados públicos de compras públicas, itens, resultados e arquivos' is broad and does not explicitly differentiate this tool from the many sibling arquivos, item, and quantity endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of closely related siblings such as pncp_obter_orgaos_compras_arquivos_quantidade_por_cnpj_ano_sequencial or pncp_obter_orgaos_compras_arquivos_por_cnpj_ano_sequencial_sequencialdocumento. The description gives neither usage conditions nor exclusions, leaving the agent to infer selection purely from names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only says 'Consulta dados públicos' and restates the endpoint. It does not clarify the response shape, that the result is purely a quantity, or how the `formato` option affects the returned data. It is not contradictory, but it is too minimal to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and readable, but the leading clause about 'compras públicas, itens, resultados e arquivos' is broad and low-value. The more useful endpoint information appears after a semicolon, so the structure is acceptable but not tightly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the call returns and when it applies. It provides only a generic consultation phrase and the endpoint, leaving the return value and the distinction from neighboring quantity/list endpoints under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description does not compensate. The path repeats `cnpj`, `ano`, and `sequencial` as URL segments but adds no meaningful guidance about CNPJ format, year bounds, or what 'sequencial' refers to. Only `formato` has a schema-level description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action—consulting the quantity of purchase document files—and gives the exact endpoint path `/v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/arquivos/quantidade`, which distinguishes it from sibling file-list and file-detail endpoints. The opening phrase is generic, but the path and 'quantidade' make the resource and operation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool instead of the many sibling alternatives, such as the file-list endpoint or the specific-file endpoint. The agent must infer from the name and path that this is the count operation, with no stated conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the behavioral burden. It indicates a public read operation ('Consulta dados públicos') but does not disclose pagination behavior, whether results are file metadata or contents, or any other side effects. This leaves the agent guessing about what a call actually returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and includes the useful endpoint path, but the opening clause is redundant with the more specific path clause. It could be tightened to state the resource and endpoint without the generic preamble.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, and no annotations, the description is under-specified. It provides the path but omits response shape, pagination semantics, and the distinction from the per-document file sibling. An agent would need external knowledge to invoke optional parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 23%, with just three of thirteen parameters described. The description compensates partially by embedding the four required parameters in the URL template (cnpj, anoCompra, sequencialCompra, sequencialAta), which clarifies their path roles. But it offers no help for the nine optional pagination-related parameters (e.g., page, pagina, pageSize, tamanho_pagina, auto_paginar), leaving ambiguous which to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Consulta' and identifies the resource as 'informacoes documentos ata' with an explicit REST path ending in /atas/{sequencialAta}/arquivos. This makes the tool's core function—fetching file information for a specific ata—reasonably clear. However, the opening phrase 'compras públicas, itens, resultados e arquivos' is broad and could describe many sibling tools, so it doesn't sharpen the purpose further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over siblings such as pncp_obter_orgaos_compras_atas_arquivos_por_cnpj_anocompra_sequencialcompra_sequencialata_sequencialdocumento. The description does not state whether this endpoint lists all files of an ata or how pagination should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only says 'consulta' (read), but does not describe the return format (file blob vs. metadata), authentication needs, error behavior, or the effect of the formato parameter. For a tool with six parameters and no annotation coverage, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and ends with a precise endpoint template, but the opening clause is generic filler that restates the broad domain without earning its place. The structure places the generic statement first and the specific action second, which is less effective than leading with the file-consultation purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, low schema coverage, and a large family of highly similar file/ata/contrato endpoints, the description lacks essential context. It never explains what a returned 'arquivo' looks like, how to obtain sequencialDocumento, or what formato='normalizado' vs. 'original' changes in the response. The endpoint path is the only concrete contextual information present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only formato is described), so the description must compensate for the five required path parameters. The endpoint template does help by showing the hierarchy orgao → compra → ata → arquivo and mapping each URL placeholder to a parameter. But it does not explain formats, constraints, or relationship semantics beyond the URL, and it does not mention formato at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description's second clause states 'ação consultar arquivo no caminho /v1/orgaos/.../arquivos/{sequencialDocumento}', which names a specific verb and resource (consulting a file) with the full endpoint path. The final path segment distinguishes this from sibling file-list and count endpoints. However, the opening clause is generic — 'compras públicas, itens, resultados e arquivos' — and could describe many sibling tools, weakening precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description does not mention that a sibling endpoint lists files for an ata (pncp_obter_orgaos_compras_atas_arquivos_por_cnpj_anocompra_sequencialcompra_sequencialata) or that sequencialDocumento must first be discovered from that list. The path implies a specific-file lookup, but the condition for using it is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states that public data is consulted and names the endpoint, adding no information about pagination behavior, response format, authentication needs, or what fields the returned items contain. The mention of 'itens, resultados e arquivos' is broad and unverified relative to the items endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loads the endpoint, which is good. However, it contains awkward auto-generated filler ('ação consultar pesquisar compra item') and redundant phrasing that consumes space without adding information. It is concise but not tightly written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no output schema, no annotations, and a large sibling family, the description is too thin to support correct invocation. It omits pagination semantics, response shape, and any clarification of the difference between the three pagination parameter naming styles. The agent would need to inspect sibling tools or external API docs to use this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate for the nine undocumented parameters. It only implicitly maps cnpj, ano, and sequencial via the path template, which is helpful for the required parameters. However, it says nothing about pagination parameters (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina) or how auto_paginar and limite_resultados interact, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Consulta') and a concrete resource: procurement items for a given CNPJ, year and sequential number, with the endpoint path spelled out (/v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/itens). It is clear that this tool returns items of a specific purchase. However, it does not explicitly distinguish itself from closely related siblings such as pncp_obter_orgaos_compras_itens_quantidade_por_cnpj_ano_sequencial or the per-item variant, leaving some differentiation to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the many sibling tools for purchases, items, quantities, or results. With over 200 siblings, an agent receives no routing help beyond the endpoint path. There is no mention of prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It does not describe what the response contains, whether 'quantidade' is a count or a list, whether pagination applies, or any access constraints. Saying 'dados públicos' and repeating the path adds little behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes a precise endpoint path, which is useful. However, the opening clause 'Consulta dados públicos de compras públicas, itens, resultados e arquivos' is generic and not fully accurate, and the specific purpose could be more clearly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and many closely related sibling tools, the description is insufficient for confident invocation. It lacks information about return shape, how the quantity is calculated, parameter constraints, and when this endpoint should be preferred over similar ones.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only 'formato' documented. The description does not explain the meaning, format, or constraints of cnpj, ano, or sequencial beyond showing them as path placeholders, so the agent must infer their semantics from the tool name and URL pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does state a specific action ('ação consultar compra item quantidade') and gives the exact endpoint path /v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/itens/quantidade, so an agent can infer it returns the quantity of purchase items for a given organization, year, and sequence. However, the opening phrase 'dados públicos de compras públicas, itens, resultados e arquivos' is overly broad and does not differentiate this tool from the many sibling item/quantidade endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as pncp_obter_orgaos_compras_itens_por_cnpj_ano_sequencial or other quantidade endpoints. The description only restates the endpoint and gives no selection criteria, exclusions, or context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only adds 'dados públicos' and the endpoint path. It does not mention that this is likely a list/collection endpoint, how pagination works, what the response shape is, or whether auto_paginar changes traversal behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first clause is padded and repetitive ('dados públicos de contratos públicos') and lists resources the endpoint does not actually fetch. The more useful endpoint information is in the second clause, so it is not ideally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no output schema, and no annotations, the description is incomplete. It gives the endpoint and action but omits pagination behavior, format options, response shape, and differentiation from the sibling empenho-detail endpoint, leaving an agent to infer most operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description needed to compensate, but it does not. The path clarifies that cnpj, ano, and sequencial identify a contract, yet the many pagination parameters (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina, limite_resultados) receive no explanation and could easily be confused.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'ação consultar empenhos do contrato', and includes the endpoint path, which clearly points to contract empenhos. However, the opening phrase lists contracts, empenhos, terms, and files generally, which slightly muddies the scope and could mislead an agent into thinking the endpoint returns more than empenhos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 its many siblings, such as the more specific pncp_obter_orgaos_contratos_empenhos_por_cnpj_ano_sequencial_sequencialempenho endpoint. Usage context is only implicit from the path and name, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does indicate a read-only public-data query ('consulta dados públicos'), but it does not clarify what the response contains, whether it returns a list or a single item, or any limitations. The broad reference to contracts, empenhos, termos, and arquivos is potentially misleading because this endpoint is specifically about instrumentos de cobrança.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and not overly long, but it wastes words with 'dados públicos de contratos públicos' and includes an unnecessary resource list before the actual endpoint action. It is compact enough but not tightly structured or fully front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and many closely related sibling tools, the description leaves out essential context: what the returned data looks like, whether this is a list endpoint, and which sibling to use for a specific collection instrument. The endpoint path alone is insufficient for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate for the undocumented required parameters. It only places cnpj, ano, and sequencialContrato into the path template without explaining their meaning or formats. The formato parameter has an enum but no useful semantic detail beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('consultar instrumentos cobranca') and gives the exact endpoint path, so an agent can identify the resource and operation. However, the opening phrase lists 'contratos públicos, empenhos, termos e arquivos,' which are broader topics than this endpoint actually covers, and it does not differentiate this tool from the closely related sibling that fetches a single collection instrument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It does not mention the sibling tool for fetching a specific 'sequencialinstrumentocobranca', nor does it state whether this returns all collection instruments for a contract. The only context is the endpoint path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden, but it only states that the action is a read/consult operation on public data. It does not disclose response format, pagination behavior, file-type specifics, or any operational constraints. The word 'Consulta' implies read-only, but little else is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes the valuable endpoint path, but it is somewhat redundant and awkward ('dados públicos de contratos públicos'; 'ação consultar informacoes documentos termo contrato'). It could be tightened to state clearly that this retrieves files associated with a specific contract term.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, no annotations, and a large sibling set, the description is incomplete. It does not describe expected return values, pagination defaults, supported formats, or how this endpoint relates to the many similar file/term/contract tools. Agents would need to infer most operational details from the tool name and path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 23%, so the description must compensate, but it only echoes four path parameters without explaining their meaning or value ranges. It adds no information about pagination parameters like page, pageSize, tamanhoPagina, auto_paginar, or limite_resultados, leaving most of the 13 parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Consulta dados públicos') and identifies the exact resource via the endpoint path /v1/orgaos/{cnpj}/contratos/{ano}/{sequencial}/termos/{sequencialTermo}/arquivos. However, the opening phrase mentions 'contratos públicos, empenhos, termos e arquivos' too broadly, and it does not explicitly differentiate this file-list endpoint from sibling file-detail tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of related sibling tools for specific document retrieval or other file operations. The endpoint path implies the resource, but no explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to rely on, and the description does not disclose behavioral traits such as read-only behavior, pagination semantics, response format, or whether all terms are returned at once. The mention of 'dados públicos' is minimal context, and the broad item list even conflicts with the narrower 'termos' path shown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and includes a useful endpoint path, but it contains redundancy such as 'dados públicos de contratos públicos' and lists 'empenhos, termos e arquivos' even though the action is specifically about contract terms. It could be tighter and more focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain what the response contains, how pagination works, or how this endpoint relates to the many sibling term/file endpoints, leaving substantial ambiguity for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description does not compensate by explaining the key parameters cnpj, ano, or sequencial. The endpoint path implies their roles, but the many pagination parameters are left entirely unexplained, and the description adds no parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('consultar termos contrato') and provides the endpoint path, which clearly identifies the resource and distinguishes it from generic contract queries. However, the opening clause mentions 'contratos públicos, empenhos, termos e arquivos' in a broad list, which muddies the specific scope of this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus closely related sibling tools, such as term-specific or file-specific variants. It does not state what this tool returns that others do not, or when a user should prefer the quantity endpoint or the sequential-term endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden. It says 'consulta' (query/read), which implies a non-destructive operation, and mentions 'dados públicos', but doesn't disclose what the quantity response actually looks like (e.g., a number, a JSON wrapper), pagination, or any rate/access considerations. No annotation contradiction, but the description adds minimal behavior information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, and it front-loads the general query intent. However, it wastes some space restating the path that is already visible in the tool name and schema, and it doesn't use the remaining space to add distinguishing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling set and the lack of an output schema and annotations, the description is incomplete. An agent needs to know what a 'quantidade' response contains, how to interpret it, and which sibling to use when a document count is not what is needed. The description only parrots the endpoint path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate for the undocumented parameters. It does identify in the path that 'cnpj', 'ano', and 'sequencial' identify an IRP document, but it doesn't explain their formats (e.g., CNPJ mask, year bounds). The optional 'formato' parameter has its own enum description in the schema, so the main gap is the three required parameters, which get only implicit meaning from the path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta dados públicos...') and the exact API path, which includes the resource ('intenções de registro de preços') and the operation ('quantidade'). This makes the tool's purpose clear: to query the file count for an IRP document. However, it doesn't explicitly distinguish it from its sibling 'pncp_obter_orgaos_irp_arquivos_por_cnpj_ano_sequencial', relying heavily on the name for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when this tool should be used instead of the many related siblings (e.g., the file list endpoint, the file-by-document endpoint, or the non-quantity IRP endpoints). The description merely repeats the operation path without explaining context or exclusions, so an agent cannot confidently choose between this and similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states that the data is public and that this is a consult operation, but it does not mention pagination, response format, authentication needs, rate limits, or what happens for invalid CNPJs. For a tool with no output schema and no annotation safety hints, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the main action, but it is somewhat clumsy and redundant, repeating 'consulta' and mixing a broad statement about public data with a path-specific action. It earns no waste but is not a polished, high-quality definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is incomplete: it does not describe the shape of the returned units, whether results are paginated, or any constraints on the CNPJ input. The sibling set is large and similar, so more contextual detail is needed to let an agent select and invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with 'formato' already documented in the schema and 'cnpj' left undocumented. The description adds only minimal meaning by embedding 'cnpj' in the path, but it does not explain the CNPJ format, accepted values, or how 'formato' affects the response. It does not compensate for the schema's missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Consulta') and identifies the resource as 'unidades' associated with an 'orgao' via the path /v1/orgaos/{cnpj}/unidades. It is somewhat broad because 'dados públicos de órgãos e unidades públicas' could suggest both organs and units, but the endpoint path clarifies the actual purpose and distinguishes it from sibling tools that target specific units.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance and names no alternatives. It does not differentiate this tool from closely related siblings like pncp_obter_orgaos_unidades_por_cnpj_codigounidade or pncp_obter_orgaos_por_cnpj beyond the path itself. Usage context is left entirely to inference from the name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'consulta dados públicos' signals a read-only operation on public data, which is a relevant behavioral trait. However, with no annotations provided, the description carries the full burden and does not disclose response format, error behavior, or how dataAtualizacao affects results, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and front-loads the main action before giving the endpoint path. It is compact but omits useful context that could have been added without much bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of operational context. It leaves unclear what value to pass for numeroControlePncpAta, what an ARP item ID is, what the response contains, and how this endpoint differs from the non-_id variant, making it incomplete for a tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameter, and the schema covers only formato and dataAtualizacao (67% coverage). The required numeroControlePncpAta is left completely undocumented, and the description does not compensate for this gap or clarify how the input maps to the endpoint's 'ARPItem_Id' concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('consulta') and resource ('dados públicos de atas de registro de preços'), which narrows the scope to public price-registration data. However, it does not explain what 'arpitem id' refers to or that the required parameter numeroControlePncpAta is the ATA control number, and it only distinguishes itself from the sibling 'compras_listar_modulo_arp_2_consultar_arpitem' through the 'id' in the name and path rather than a clear semantic statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives like 'compras_listar_modulo_arp_2_consultar_arpitem' or other ARP-item endpoints. The description gives no use-case context, exclusions, or mention of when the _id variant is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; it only says the data is 'públicos' (public) and that it is a consultation. It fails to disclose pagination behavior, the meaning of the required 'ativo' flag, response normalization, or any limits, leaving important behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The second clause is slightly redundant ('ação consultar fornecedor') but adds the useful endpoint path, so there is no material waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 15 parameters, one required boolean, no annotations, and no output schema, a two-clause description is not enough. An agent still cannot determine how to construct a valid request or what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description explains no parameters. It does not clarify the key filter fields (cpf/cnpj), the required 'ativo' boolean, or the pagination variants, so it adds essentially no parameter meaning beyond the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Consulta dados públicos de fornecedores' and gives the endpoint path. It distinguishes from the many sibling tools by naming the fornecedor domain and the specific action/path, though it could state what data fields are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus the large set of sibling consultation tools. It does not mention required inputs, use cases, or exclusions, so an agent cannot tell when to choose this over related supplier, contract, or PNCP endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It implies a read-only operation and mentions that the data is public, but it does not disclose pagination behavior, response format, auto-pagination, result limits, or how period filtering behaves. The schema hints at paging, but the description itself adds little 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler and includes the relevant endpoint path. It is efficient, though it sacrifices useful detail and is not structured into actionable sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no annotations, and no output schema, this description is far too thin to guide correct invocation. It does not explain required versus optional inputs beyond what the schema already says, nor does it describe the expected response or how to handle pagination alternatives. The minimal information is present, but significant gaps remain for a complex API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 27%, and most parameters (ano, mes, page, pagina, pageSize, page_size, etc.) have no semantic explanation. The description only says 'por periodo', which vaguely connects to the year/month parameters, but it does not compensate for the large number of undocumented pagination and formatting parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('consulta') and resource ('dados públicos de indicadores de compras públicas'), and identifies the operation as consulting indicators by period. It also names the API path, which adds precision. However, it does not explicitly contrast itself with sibling tools like compras_consultar_indicadores_consolidados, so differentiation is left mostly to the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the consolidated indicators sibling or other indicator-related tools. The description only restates the operation and path, without saying when this period-based variant is appropriate or when it is not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Não há annotations e a descrição carrega todo o peso. Ela informa que os dados são públicos e que é uma consulta, mas não detalha formato da resposta, paginação, autenticação, limites ou outros comportamentos relevantes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Descrição em uma frase única, sem redundância e com o caminho incluído. É compacta, ainda que não estruture separadamente uso, parâmetros e comportamento.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sem output schema, sem annotations e com quatro parâmetros, a descrição é curta demais para orientar uma chamada correta. Faltam explicação dos identificadores, relação com as ferramentas irmãs e comportamento esperado.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
A descrição não comenta nenhum parâmetro. O schema cobre apenas 50% das propriedades (formato e dt_alteracao), deixando id_compra e id_compra_item sem descrição; a descrição do tool não compensa essa lacuna.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
O texto indica verbo 'consulta', recurso 'itens pregoes id' e domínio 'licitações e compras legadas', o que permite saber que é uma consulta de itens de pregão por identificador. No entanto, não diferencia explicitamente esta ferramenta de irmãs como compras_listar_modulo_legado_4_consultar_itens_pregoes ou compras_listar_modulo_legado_3_1_consultar_pregoes_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Não há orientação sobre quando usar esta ferramenta em vez das alternativas, nem sobre pré-requisitos ou exclusões. O caminho e o sufixo 'Id' sugerem o uso para consulta pontual, mas isso fica implícito.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does indicate a read-only 'consulta' of public data, which is helpful, but it says nothing about response behavior, result shape, pagination, required identifier semantics, or any other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler, and it front-loads the main purpose before giving the endpoint path. It is concise, though it sacrifices useful detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, no annotations, and a very large sibling-tool list, this minimal description is not enough for confident tool selection or correct invocation. It does not explain what the returned item data contains or when this tool should be preferred over the many similar legacy-module endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with id_compra and id_compra_item undocumented, and the description adds no parameter-level meaning. The endpoint wording hints at an 'id' concept, but it does not clarify which ID is required or how optional parameters like dt_alteracao and formato affect the query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('consultar itens compras sem licitacao id') and the resource ('dados públicos de licitações e compras legadas'), also naming the endpoint path. It is clearer than the tool name alone, but it does not explicitly differentiate this tool from closely related sibling tools such as compras_listar_modulo_legado_6_consultar_compra_itens_sem_licitacao.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this ID-based item query versus the list variant or other legacy-module tools. There are no conditions, exclusions, or mentions of alternatives, so an agent must infer usage from the name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does convey a read-only, no-auth profile via 'dados públicos' and 'consulta', which is useful. But it discloses nothing about pagination behavior (despite four pagination parameter families in the schema), the auto_paginar behavior, the 'formato' response modes (normalizado vs original), result volume, or response shape. For a read tool with zero annotation coverage, this is under-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the verb and ending in a concrete API path. It loses a point for internal redundancy: 'Consulta dados públicos de materiais' is essentially restated by 'ação consultar item material' within the same breath, where the second clause could have carried richer information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool — 17 optional parameters, no annotations, no output schema, and a sibling list containing six other material-module tools. The description doesn't explain where 'item material' sits in the catalog hierarchy (grupo → classe → pdm → item), which parameters work together, or what the response contains. An agent cannot reliably distinguish or correctly invoke this tool from the definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18% (3 of 17 parameters documented), well below the 50% threshold, so the description needed to compensate — and it adds zero parameter meaning. Some names are self-explanatory (codigoItem, codigo_ncm, descricaoItem), but the description gives no help with the confusing duplicated pagination groups (page/pagina, pageSize/page_size/tamanhoPagina/tamanho_pagina) or with which filters are the primary lookup keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('consultar') attached to a specific resource ('item material') and pinpoints the exact endpoint (/modulo-material/4_consultarItemMaterial). This is enough to distinguish it from the material-module siblings that query different objects (grupo, classe, pdm, natureza de despesa). It doesn't earn a 5 because the opening clause 'Consulta dados públicos de materiais para compras públicas' is generic to the whole module and repeats the domain context found in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to select this tool over its many siblings. It doesn't state a condition such as 'use when looking up a specific material item by code' nor contrast it with compras_listar_modulo_material_3_consultar_pdm_material or compras_listar_modulo_material_2_consultar_classe_material. The intended usage is only inferable from the name and path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and contributes only that the data is 'público' (public), implying a read-only, unauthenticated query. It does not disclose pagination behavior despite six pagination-related parameters, the formato normalizado/original transformation, auto_paginar looping semantics, or the meaning of dataResultado and limite_resultados. For a 21-parameter query tool this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficiently front-loaded, stating the purpose before the endpoint, with zero filler words. The brevity is a genuine strength, though it comes at the cost of completeness, which is captured in contextual_completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, 21 parameters, and seven closely related pesquisa_preco sibling tools, a one-sentence description is far from sufficient. An agent cannot determine which optional filters combine with tipo/codigo, which pagination parameter to use, or how this listing relates to the CSV and detalhe variants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 24%, and the description compensates for none of the remaining 76% — it mentions zero parameters. The required pair tipo/codigo is left undocumented beyond the raw enum labels (codigoItemCatalogo, codigoPdm), and the redundant pagination aliases (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina) are never disambiguated. An agent gets no help deciding what to pass or which alias is canonical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Consulta) and resource (dados públicos de pesquisa de preços, material) and pins the action to a concrete endpoint path (/modulo-pesquisa-preco/1_consultarMaterial). It is clear at a high level what the tool does. However, it does not explicitly differentiate this tool from its CSV sibling (1_1_consultar_material_csv) or the detalhe variant (2_consultar_material_detalhe), so the agent must infer distinctions from the name and path alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 JSON list endpoint versus the CSV variant (modulo_pesquisa_preco_1_1_consultar_material_csv) or the material-detail endpoints (modulo_pesquisa_preco_2_consultar_material_detalhe). The description restates only the purpose and offers no exclusions, prerequisites, or selection criteria, leaving the agent to guess which tool fits the task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It adds some value by noting the data is 'dados públicos' (public, suggesting no special access) and exposing the endpoint path, but it says nothing about pagination behavior, result limits, response format, or the unusual duplicate pagination parameters (page/pageSize vs. pagina/tamanhoPagina). For a read tool with 12 parameters and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core purpose before giving the endpoint path. Every clause earns its place; the only redundancy is that the name and description both contain 'consultar servico detalhe', which is minor and acceptable in this context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 12-parameter tool with a required but undocumented 'codigoItemCatalogo', no output schema, no annotations, and a large family of siblings. The one-sentence description provides none of the contextual scaffolding needed — no relationship to the CSV variant, no explanation of the multiple pagination parameter sets, and no indication of expected return values. For a tool of this complexity, the description is materially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 42% (5 of 12 parameters documented), which is below the 50% threshold, so the description should compensate. It does not mention any parameters at all — notably the required 'codigoItemCatalogo' has no description in either the schema or the tool description. An agent is left to guess the meaning and format of the required input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta'), a clear resource ('dados públicos de pesquisa de preços'), and a specific action ('consultar servico detalhe') with the endpoint path. It is clear about what the tool does, though it does not explicitly differentiate itself from the CSV sibling or the base service-list tool, relying on the name for that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that the CSV variant (compras_listar_modulo_pesquisa_preco_4_1_consultar_servico_detalhe_csv) exists for raw data, nor when the base list tool (…_3_consultar_servico) should be preferred. An agent must infer usage context entirely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does indicate the operation is a read-only public-data consultation and includes 'csv' in the action, but it does not disclose pagination behavior, output structure, rate limits, or the meaning of formato normalizado versus original. These are significant gaps for a 12-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the domain and gives a concrete path. It avoids filler, though it is terse almost to the point of being skeletal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, no annotations, and a large sibling family, this definition is too thin. It does not describe what the returned CSV contains, how pagination or auto_paginar behaves, or when to choose the CSV variant, leaving an agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no parameter-level meaning. It does not explain anoPcaProjetoCompra, how tipo relates to codigo, or how the duplicated page/pageSize aliases should be used. Because coverage is low, the description needed to compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Consulta dados públicos de planejamento de contratações' and identifies the exact action and endpoint path. The 'csv' component helps separate it from the sibling compras_listar_modulo_pgc_2_consultar_pgc_detalhe_catalogo, though it never explains what the 'catálogo' detail actually represents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the non-CSV sibling or other PGC-related tools. There is no explicit condition, prerequisite, or alternative mentioned; the agent must infer usage from the tool name and 'csv' in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full disclosure burden. It signals a read-only query of public data ('dados públicos'), but it does not disclose pagination behavior, the confusing dual 'page'/'pagina' parameters, the meaning of 'agregacao', or response content. No annotation contradiction exists because no annotations were provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and it front-loads the purpose before the endpoint. The second clause is mildly redundant since the action and path are already encoded in the tool name, but the explicit endpoint adds routing value and the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, this description is thin. It omits how to construct a correct call (what orgao/ano accept), how pagination works, what the aggregation limit applies to, and how this differs from the CSV sibling. The endpoint path is useful, but the operational context an agent needs is largely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, and the description adds no parameter information whatsoever. The required 'orgao' and 'ano' parameters are undocumented, the redundant-looking 'page'/'pagina' pair is unexplained, and 'limite_resultados' semantics are not clarified, so the description fails to compensate for the schema's gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Consulta dados públicos de planejamento de contratações') and names the specific action ('consultar pgc agregacao'), which distinguishes it from the módulo-pgc detalhe/catálogo siblings. However, it does not differentiate it from the near-identical CSV sibling 'compras_listar_modulo_pgc_3_1_consultar_pgc_agregacao_csv', leaving the JSON-vs-CSV choice ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not contrast with the CSV variant of the same aggregation, nor with pgc_detalhe or pgc_detalhe_catalogo, and it never mentions that the 'formato' parameter or auto_paginar exist. An agent must infer selection criteria entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Sem annotations, a descrição precisa assumir o peso de revelar o comportamento. Ela informa que se trata de consulta a dados públicos, o que sugere operação somente leitura, mas não explica paginação, formato de retorno, nem o efeito de parâmetros como auto_paginar. Falta contexto comportamental relevante para uma ferramenta com 8 parâmetros.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A descrição é curta e direta, com o propósito principal na frente. O caminho da API é informação útil, embora parte do texto repita o nome da ferramenta ('consultar classe servico'), o que gera pequena redundância sem comprometer a clareza.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para uma ferramenta com 8 parâmetros, sem output schema e sem annotations, a descrição é insuficiente. Faltam orientações sobre filtros, paginação, significado da hierarquia de classes de serviço e o formato da resposta. O agente precisaria inferir demais para usar corretamente.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
A cobertura de descrição no schema é baixa (38%), então a descrição deveria compensar, mas não menciona nenhum parâmetro. O schema documenta apenas formato, auto_paginar e limite_resultados; page, pagina, codigoGrupo, statusGrupo e codigoClasse ficam sem explicação adicional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição informa verbo e recurso específicos: 'Consulta dados públicos de serviços' e 'consultar classe servico', incluindo o caminho da API. O recurso 'classe servico' permite diferenciá-lo dos irmãos da hierarquia de serviços (seção, divisão, grupo, subclasse, item), embora não faça essa distinção de forma explícita.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Não há orientação sobre quando usar esta ferramenta em vez das alternativas, nem menção a pré-requisitos, filtros recomendados ou casos de uso. A descrição apenas afirma o que a ferramenta faz, sem contexto de seleção.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does add that the data is public, implying a read-only, likely unauthenticated operation, but it does not explain pagination behavior, result size limits, response format, or any other runtime traits. The word 'consulta' largely repeats the tool's own name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler and front-loads the core purpose. The endpoint path is redundant with the tool name but still useful; overall it is concise, though not a model of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with seven parameters, no required fields, no output schema, and no annotations, this description is too thin. It does not explain parameter roles, default behavior, how pagination works, or what the response represents, leaving significant gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, and the description does not compensate for the undocumented parameters. None of the seven parameters such as codigoServico, statusUnidadeMedida, or the page/pagina duplicate are explained beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Consulta dados públicos de serviços') and narrows the resource to 'und medida servico' with an explicit endpoint path. This is distinguishable from sibling service-module tools such as item, class, or nature-of-expense queries, though it does not explicitly contrast itself against them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over alternatives, nor any exclusions or prerequisites. With many similar 'consultar' siblings in the service and procurement domains, the agent must infer usage purely from the endpoint name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does convey that this is a public-data read operation ('Consulta dados públicos'), which implies read-only access and no sensitive token requirements. However, it omits important behavioral details such as pagination behavior, auto-pagination effects, and response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the resource and includes the endpoint path. The phrase 'ação consultar uasg' partially repeats the tool name, but the description has no real filler or redundant schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no output schema, no annotations, and many closely related siblings, this one-sentence description is severely incomplete. It omits filter semantics, required parameters, output format, pagination, and any relationship to CSV or órgão variants, leaving an agent with very little to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, yet the description adds no parameter-level meaning. It does not mention the required statusUasg or common filters like codigoUasg, siglaUf, or cnpjCpfOrgao, so it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a query action ('Consulta') and the resource ('órgãos e unidades administrativas', UASG), and it provides the endpoint path. It is not a tautology, but it does not explicitly differentiate this tool from close siblings like compras_listar_modulo_uasg_1_1_consultar_uasg_csv or compras_listar_modulo_uasg_2_consultar_orgao.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention the CSV variant, the órgão endpoint, or any criteria for choosing between them, so an agent must infer usage purely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates the operation is a read-only public data query, but doesn't mention pagination, response format, or the meaning of statusAtivo filtering. For a list endpoint with no annotations, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the action and endpoint path front-loaded. No redundant fluff, but it omits param details that could make it more informative without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and one undocumented parameter, the description is too thin for an agent to invoke correctly. It lacks distinctions from the get-by-id sibling and doesn't explain filtering or response behavior. The endpoint is simple, but the missing statusAtivo semantics is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% – the 'formato' parameter has a description, but 'statusAtivo' has none. The description itself adds no parameter-level semantics, so the agent cannot infer how statusAtivo affects the list. Since coverage is moderate and description doesn't compensate, parameter guidance is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('fontes orçamentárias') and the action ('listar registros') and includes the API path. It distinguishes the list operation from sibling 'obter_fontes_orcamentarias_por_id' by explicitly using 'listar'. However, it doesn't specify the scope or result set beyond listing public records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives, nor any mention of exclusions or preconditions. The description only states what the endpoint does, leaving the agent to infer usage from the name and path. The large sibling list offers a get-by-id alternative that is never referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says the data is 'públicos' (suggesting a read-only operation). It does not disclose whether the response is a list, whether pagination exists, how the optional IDs affect the result, or what 'normalizado' vs 'original' changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loads the main action and endpoint. The semicolon clause is slightly redundant ('ação obter...') but the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters, no annotations, no output schema, and many closely related siblings, this description is too thin. It omits the list/get distinction, default behavior with no arguments, and response shape, leaving an agent to guess at invocation semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (formato is documented), leaving modalidadeId and fonteOrcamentariaId unexplained. The phrase 'por modalidade' hints at modalidadeId's role, but it does not clarify that no parameters likely returns all associations or how the IDs combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Consulta'), resource ('modalidades e fontes orçamentárias'), and endpoint ('/v1/modalidade-fonte-orcamentaria'). This is clear enough to identify what the tool accesses, but it does not distinguish this from related sibling tools such as pncp_listar_modalidades or pncp_listar_fontes_orcamentarias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this tool over alternatives. It does not mention that the sibling pncp_obter_modalidade_fonte_orcamentaria_por_modalidadeid_fonteorcamentariaid is for retrieving a single relationship, nor when to use list vs get variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It conveys that the data is public and the operation is a consulta/listar, but it does not disclose the response shape, pagination behavior, or how irp/statusAtivo affect the results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence that front-loads the purpose ('consulta dados públicos...') and then gives the exact path and action. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and two undocumented boolean parameters, the description is too thin: it does not explain the meaning of the optional filters or the nature of the returned list. An agent can make a bare call but cannot confidently use the filtering options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% and the description adds no parameter meaning. irp and statusAtivo remain unexplained, and the description only repeats the endpoint instead of compensating for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('consulta dados públicos' and 'ação listar registros') and a clear resource ('modalidades de contratação') with the exact endpoint /v1/modalidades. It distinguishes from 'obter...por_id' siblings by indicating this is a list operation, but it does not explicitly name any sibling or contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of pncp_obter_modalidades_por_id or other list tools. The only implicit signal is the 'listar' action and path, so the agent must infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only states that the data is public and names the endpoint. It omits pagination behavior, response shape, and whether statusAtivo is applied server-side, leaving the agent with limited information for handling non-default calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the resource and action front-loaded. The phrase 'ação listar registros' is slightly redundant after 'Consulta', but the overall structure is efficient and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no annotations and no output schema, the description leaves meaningful gaps: the semantics of statusAtivo, pagination expectations, and the returned record structure. It is enough to identify the endpoint, but not enough to invoke it confidently beyond the default no-parameter call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds nothing about either parameter. 'formato' is already documented in the schema, but 'statusAtivo' remains unexplained, and the description does not compensate for that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource ('dados públicos de portes de empresa'), a clear verb ('Consulta'), and the list operation with the endpoint path /v1/portes-empresa. It is reasonably distinguishable from the sibling pncp_obter_portes_empresa_por_id via 'listar', though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 list endpoint versus pncp_obter_portes_empresa_por_id or other PNCP listing tools. The phrase 'ação listar registros' implies the operation, but there are no exclusions, prerequisites, or mention of filtering behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It only states that this queries public data and lists records, with no mention of optional filter behavior, pagination, read-only semantics, or response format. This is minimal disclosure for a data-listing endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the purpose and the endpoint without padding. It is slightly awkwardly structured with a semicolon, but it is efficient and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with three optional parameters, no annotations, and no output schema, the description is too thin. It does not explain what the returned records represent, how the optional IDs filter the results, or what response variants to expect. Given the many overlapping sibling tools, more orientation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%: the 'formato' parameter is documented, but 'modoDisputaId' and 'tipoInstrumentoConvocatorioId' have no descriptions anywhere. The tool description adds nothing about the parameters, so the low coverage gap is not compensated. The parameter names offer some clue, but the description provides no additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (listar/query) and resource (public data of instrumentos convocatórios e modos de disputa) and even gives the API path. However, it does not clarify that this tool lists the association/relationship records between instrument types and dispute modes, nor does it distinguish itself from siblings like pncp_listar_tipos_instrumentos_convocatorios or pncp_listar_modos_disputas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the related 'obter' tool or the list tools for the individual entity types. The agent must infer usage context entirely from the tool names and the path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 and only contributes 'dados públicos', which weakly signals a publicly accessible read operation. It does not disclose not-found/error behavior, the distinction between the 'normalizado' and 'original' response formats, or what the returned record contains. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence: it front-loads the action and resource, then gives the precise endpoint path with proper casing and slash structure, which is genuinely more usable than the concatenated tool name. No wasted words, though the second clause partially restates information already encoded in the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 25% parameter coverage, the description is too thin. It omits the response contents, the behavioral meaning of the formato parameter, and — most importantly — any hint that valid IDs can be sourced from pncp_listar_instrumento_convocatorio_modalidade_amparo_legal. An agent can call the endpoint but cannot reliably interpret the result or recover from a bad ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% — only 'formato' is documented — so the description needed to compensate for the three required IDs. Instead, it merely repeats the parameter placeholders inside the path without explaining what an amparo legal, modalidade, or tipo instrumento convocatório ID refers to or where to obtain them. The description adds essentially nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Consulta dados públicos... ação obter registro') and a specific resource (the instrumento-convocatorio-modalidade-amparo-legal association), reinforced by the exact endpoint path. It implicitly contrasts with the sibling pncp_listar_instrumento_convocatorio_modalidade_amparo_legal by specifying a single-record fetch, but it never names that sibling or explicitly draws the distinction, 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.
Usage Guidelines2/5
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. The description does not state that this should be used when the caller already knows the three composite IDs, nor does it point to the list endpoint (pncp_listar_instrumento_convocatorio_modalidade_amparo_legal) for discovering valid IDs. The only usage signal is the path template itself, which implies but never explains the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It does indicate a read-only 'consulta' action that obtains an image, but it does not describe the response format, whether the result is binary or JSON, or any other behavioral traits such as availability or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and contains the most useful information, the endpoint path, in a single sentence. The generic first clause is somewhat unnecessary, but it does not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool requires five nested identifiers and has no output schema or annotations, yet the description does not explain where these identifiers come from, how the image is returned, or what the 'formato' parameter does. The path template helps, but it is not enough for reliable invocation in a complex endpoint family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, and only 'formato' has a schema description. The endpoint path maps cnpj, ano, sequencial, numeroItem, and sequencialImagem to URL segments, which is useful, but it does not explain their domain meaning, how to obtain valid values, or how 'formato' affects the response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description contains a specific verb phrase 'ação obter imagem' and the exact endpoint path, which identifies the resource as a single item image identified by sequencialImagem. However, the opening clause is generic and does not explicitly contrast with the sibling tool that lists images for an item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the closely related sibling pncp_obter_orgaos_compras_itens_imagem_por_cnpj_ano_sequencial_numeroitem, which returns the list of images, or versus other procurement-item endpoints. The agent is left to infer usage from the name and path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It mentions that the data are public and names the action, but it does not describe what the response contains, whether results are paginated, how the 'formato' parameter changes the payload, or whether files are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the endpoint path and stays compact. There is minor redundancy ('dados públicos de compras públicas'), but generally every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four required parameters, no output schema, and no annotations, the description is thin. It omits the shape of the return value, pagination behavior, and the practical meaning of the normalizado/original format option, so an agent would need external knowledge to fully understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, limited to the formato parameter, and the description does not explain cnpj, ano, sequencial, or numeroItem. The endpoint path implies their roles, but the description adds no semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('consultar resultados') and gives the exact endpoint path /v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/itens/{numeroItem}/resultados, which clearly identifies the resource being accessed. It does not explicitly distinguish the sibling with an additional sequencialresultado, but the path and tool name make the scope reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus sibling tools such as the variant with /sequencialresultado or the parent item endpoint. The description only states what the tool does, not when it should be selected or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It states the data is public and read-only and that the response includes IRP and its items, but it does not explain what the historical data represents, whether pagination is required, or what the return format is. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the action and resource. It wastes no words, though the semicolon construction slightly buries the endpoint detail and there is no structured breakdown of behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema and no annotations, this description is too thin. It omits the return shape, pagination semantics, and the practical meaning of 'historico' in terms of what revisions or versions are returned. The endpoint path is helpful but does not make the tool safely callable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 25% of schema parameters have descriptions, so the tool description must compensate, but it only clarifies that cnpj, ano, and sequencial are path parameters via the URL template. The many pagination parameters (page, pagina, pageSize, page_size, etc.) remain unexplained, and the description does not indicate which one an agent should use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Consulta'), a resource ('dados públicos de intenções de registro de preços e seus itens'), and an explicit endpoint path ending in '/historico', making the tool's purpose reasonably clear. It does not explicitly contrast with sibling tools like the non-historico IRP lookup, but the resource plus path is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The path and tool name imply this is the historical IRP endpoint, but the description never states when to choose it over pncp_obter_orgaos_irp_por_cnpj_ano_sequencial or the related item/quantity endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, and it discloses almost nothing: it does not state that results are paginated (despite 9 pagination-related parameters in the schema), that responses can switch between 'normalizado' and 'original' formats, or what the returned item list contains. The only behavioral hint is that the data is public ('dados públicos'). The description does not contradict anything, but it adds little beyond the endpoint itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the resource and then gives the precise path. The only structural flaw is the redundant opening clause, which restates the IRP scope before narrowing to 'listar itens'; trimming it would make the description tighter. Overall it is efficiently sized with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 12 parameters, heavy pagination aliasing, no output schema, and no annotations, this description is not sufficient for an agent to invoke it correctly. Missing elements include pagination behavior (default page size, whether all items are returned), which of the duplicated pagination parameters to pass, and any hint of the response shape. The description establishes identity but not operability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate, and it only partially does: the URL path usefully clarifies that cnpj, ano, and sequencial are hierarchical path segments. However, the 9 pagination/format parameters remain unexplained, and the confusing duplicate aliases (page/pagina, pageSize/page_size/tamanhoPagina/tamanho_pagina) — a real trap with additionalProperties:false — get zero clarification about which to use or whether they are synonyms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Consulta'/'listar'), a concrete resource ('itens irp'), and pins the exact endpoint path /v1/orgaos/{cnpj}/irp/{ano}/{sequencial}/itens, which clearly separates this from the parent IRP tool and the single-item variant. It loses the 5th point because the opening clause ('intenções de registro de preços e seus itens') over-broadly claims scope over the IRP record itself, which is the parent sibling's job, creating mild ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance whatsoever on when to choose this over any of its many siblings. It does not mention that the parent tool pncp_obter_orgaos_irp_por_cnpj_ano_sequencial returns the IRP header, that the _numeroitem variant returns a single item, or that the _quantidade variant returns counts. An agent facing 200+ siblings gets no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'consulta dados públicos', implying a read operation, but it does not disclose pagination behavior, default response format, or how the many pagination/filter parameters affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the general purpose before giving the exact endpoint. The wording 'ação consultar dados pca itens categoria' is awkward, but there is little wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters, no output schema, and no annotations, the description is too thin. It lacks return-value expectations, pagination semantics, parameter details, and differentiation from similar pca_itens_* siblings, so an agent would have to guess or inspect schemas further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 23%, and the description adds minimal parameter meaning. The path clarifies that cnpj, ano, and sequencial are path parts, but it does not explain their formats, the optional categoria filter, or the pagination/alias parameters present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific read operation on annual procurement plan data and gives the exact endpoint /v1/orgaos/{cnpj}/pca/{ano}/{sequencial}/itens, so an agent can tell it is a PCA items query. It does not contrast with sibling tools like pncp_obter_orgaos_pca_itens_plano_por_cnpj_ano_sequencial, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over the many sibling PCA/PNCP endpoints, nor any exclusion criteria. The intended usage is only implicit in the endpoint path and the phrase 'pca itens categoria'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and there is no output schema to compensate. The description only notes the data is 'público' and uses 'consulta', implying a safe read, but it does not disclose the response shape, what the returned quantity represents, pagination, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler; the high-level purpose is front-loaded and the concrete endpoint follows. Mild awkwardness in the Portuguese phrasing ('ação consultar dados orgao pca quantidade no caminho') keeps it from being a 5, but it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the agent cannot determine what this quantity endpoint returns or how it differs from the quantity-based siblings in the same PCA family. The description confirms the domain and path but leaves the meaning of the count and the response contract entirely to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'formato' is documented in the schema), so the description must compensate for cnpj and ano — but it merely echoes them inside the path template. It offers no format hints for cnpj (digits only, mask, length) or valid range for ano, providing little added meaning beyond the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('consultar'), a resource (annual contracting plans data), and the exact endpoint path /v1/orgaos/{cnpj}/pca/{ano}/quantidade, which makes the resource and scope reasonably identifiable. However, it is phrased in broken Portuguese ('ação consultar dados orgao pca quantidade no caminho') and never states what the 'quantidade' actually counts, which matters because many sibling PCA endpoints contain 'quantidade' in their names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as pncp_obter_orgaos_pca_consolidado_por_cnpj_ano or pncp_obter_orgaos_pca_itens_quantidade_por_cnpj_ano_sequencial. No when-to-use, when-not-to-use, or alternative-routing information is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys only that this is a public read operation ('Consulta dados públicos') and provides the endpoint path. It does not disclose response format, pagination, authorization requirements, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler and includes the endpoint path. It is efficiently structured, though its brevity leaves out important explanatory content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, no annotations, and a large sibling family, the description omits selection guidance, response details, and parameter semantics. An agent would struggle to invoke it confidently without extra information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only 'formato' described. The description adds path context for 'cnpj' (órgão) and 'ano' (PCA year) but does not explain the 'categoriaItem' parameter or the 'formato' options, so it only partially compensates for the missing schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta') and resource ('valores categoria item' within annual contracting plans), and pinpoints the exact endpoint path. It is clear about what data is returned, though it does not explicitly distinguish itself from sibling tools like the 'sequencial' variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many similar sibling tools (e.g., pncp_obter_orgaos_pca_valorescategoriaitem_por_cnpj_ano_sequencial or pncp_obter_orgaos_pca_consolidado_por_cnpj_ano). Usage is only implied by the resource name and path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only states that the data is public and repeats the endpoint. It does not describe what the response contains, whether categoriaItem acts as a filter, what the default 'normalizado' format means behaviorally, or any limits or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence and wastes little space. It loses a point because 'consulta' and 'ação consultar' are slightly redundant, and the structure is a run-on with a semicolon rather than a clean front-loaded definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling set, low schema coverage, and absence of an output schema, this description is not complete enough. An agent cannot determine return shape, optional filtering behavior, or why this endpoint should be chosen over the sibling without the sequencial segment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description needed to compensate, but it only repeats the path variables cnpj, ano, and sequencial without explaining their meaning. Optional parameters formato and categoriaItem are not described at all, leaving significant semantic gaps beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action, 'consulta', over a specific resource, 'dados públicos de planos de contratações anuais', and includes the exact endpoint path with the resource hierarchy. It is clear what the tool does, but it does not explicitly differentiate itself from the near-identical sibling tool that omits 'sequencial' from its path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many similar PCA-related sibling tools, such as pncp_obter_orgaos_pca_valorescategoriaitem_por_cnpj_ano or pncp_obter_orgaos_pca_consolidado_por_cnpj_ano_sequencial. The description provides context about public data but no selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a read-only operation on public data ('consulta dados públicos'), but discloses nothing beyond that: no response format, pagination, data volume, or effect of the formato parameter on the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the core action front-loaded. However, it is mildly redundant: 'Consulta... indicadores' repeats the verb in 'ação consultar indicadores', and the endpoint path largely duplicates the function's action name. Acceptable size but not tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should explain what the agent will receive. It does not describe what 'indicadores consolidados' contains, what the normalized versus original payloads look like, or how this relates to the by-period indicator sibling. The call itself is trivially simple (no required params), but the response is a complete unknown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single formato parameter is fully documented in the schema with its enum ('normalizado'/'original') and default value. The description adds no parameter-level detail, but the schema already does the heavy lifting, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Consulta dados públicos de indicadores de compras públicas') and a specific action ('ação consultar indicadores consolidados') with its endpoint path. The word 'consolidados' helps distinguish it from the sibling compras_listar_modulo_indicadores_2_consultar_indicadores_por_periodo, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is a closely related sibling (compras_listar_modulo_indicadores_2_consultar_indicadores_por_periodo) and yet the description provides no trigger conditions, exclusions, or context about what kind of indicator query this suits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only reveals that the data is public; it says nothing about pagination or auto-pagination behavior, response format, date-range constraints, or limits. For a read query with zero annotation coverage, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the main purpose front-loaded. However, 'ação consultar arp fim vigencia' restates the tool name and is immediately duplicated by the path /modulo-arp/1.2_consultarARP_FimVigencia, so part of the sentence is redundant even if the explicit path retains some value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 16-parameter tool with no annotations, no output schema, and only 44% schema coverage, sitting inside a large cluster of ARP sibling tools. The description omits sibling differentiation, leaves the optional filters (codigoModalidadeCompra, numeroAtaRegistroPreco, codigoUnidadeGerenciadora) unexplained, and does not address the duplicated pagination parameters. It is not sufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 44%, with format notes on the date fields and behavior notes on formato, auto_paginar, and limite_resultados. The description adds modest value by framing the end-of-validity semantic, which clarifies the role of the two required date parameters, but it does nothing to resolve the confusing pagination aliases (page/pagina/pageSize/tamanhoPagina) or the undocumented filter fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Consulta), a concrete resource (atas de registro de preços), and a distinctive scope (fim vigencia / end of validity), so an agent can tell this is the ARP query filtered by final validity date. It doesn't explicitly contrast with the sibling consultar_arp, but the action name and API path pin down the purpose well enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives. The sibling set includes compras_listar_modulo_arp_1_consultar_arp (general ARP query) and compras_listar_modulo_contratos_1_2_consultar_contratos_fim_vigencia, but the description never names an alternative or states a selection condition. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does convey that the operation is a public, read-only query of contract data, which is useful. However, it does not disclose response behavior, pagination, error cases, or any additional constraints beyond the endpoint path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action, but it contains redundancy ('públicos' repeated) and largely restates the tool name. It is efficient but not carefully structured to maximize information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has three parameters, no output schema, no annotations, and appears among dozens of similar contract/contract-item tools. The description is far too thin to let an agent correctly select and invoke it, especially since it does not distinguish it from the non-id variant or explain what data the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description adds no explanation of the required parameters 'tipo' and 'codigo' or how they relate to 'item id'. The schema's enums provide some clues, but the description does not compensate for the missing semantics of the core parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as consulting public contract data via the specific 'consultar contratos item id' action and endpoint path. It is understandable on its own, though it does not differentiate from closely named siblings like 'compras_listar_modulo_contratos_2_consultar_contratos_item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over the many contract-related siblings, no exclusions, and no mention of what kind of input or use case maps to this operation. The agent is left to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses that the data is public and legacy ('dados públicos de licitações e compras legadas'), which is helpful. However, it doesn't disclose what the endpoint returns beyond 'public data', whether the response format ('normalizado' vs 'original') affects structure, error behavior, pagination, or any limits. The 'dt_alteracao' parameter suggests date-based filtering but its effect isn't explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no fluff, but it's repetitive: the tool name already contains 'consultar_licitacao_id' and the endpoint path mirrors it. The sentence provides only minimal additional context ('dados públicos', 'legadas') beyond the name. It's compact, but it doesn't use the space to add differentiating guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is thin. It identifies the resource and endpoint but omits usage guidance, return value expectations, parameter relationships (e.g., 'dt_alteracao' probably filters by change date), and how this differs from list variants like 'compras_listar_modulo_legado_1_consultar_licitacao'. An agent could call it correctly with 'id_compra' but without knowing what response to expect or when to prefer the list variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%: 'formato' and 'dt_alteracao' have descriptions in the schema, while 'id_compra' has none. The tool description doesn't add any parameter-specific meaning beyond the schema, but the schema already covers two of three parameters. The description's mention of 'consultar licitacao id' reinforces that 'id_compra' is the licitação ID, providing modest value for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Consulta' (queries public data of legacy bids/purchases) and identifies the specific action 'consultar licitacao id' at the endpoint '/modulo-legado/1.1_consultarLicitacao_Id'. It clearly indicates this is the by-id lookup variant, distinguishing it from sibling tools that list all licitações or operate on different modules. However, it doesn't explicitly contrast with the sibling 'compras_listar_modulo_legado_1_consultar_licitacao' that likely lists licitações without an ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for querying a specific licitação by ID (given the required 'id_compra' parameter), but it doesn't state exclusions or name sibling alternatives. An agent must infer usage from the endpoint name and required parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states that data is public and that it is a query action, which is mildly useful, but it does not disclose pagination behavior, whether statusGrupo acts as a filter, how auto_paginar behaves, or any rate-limit or response observations. 'auto_paginar' implies side effects of automatic traversal that are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with some redundant naming: 'compras públicas' appears twice and 'consultar grupo servico' repeats the tool name. It is compact, but it could be improved by removing redundancy and adding a short phrase about optional filters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 optional parameters, no output schema, and no annotations, the description does not provide enough context about how to use the filters or what the response contains. The tool name and siblings make its role in the service hierarchy inferable, but the description alone leaves too much unspecified for an agent to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, so the description must compensate for undocumented parameters like page, pagina, codigoGrupo, statusGrupo, and codigoDivisao. The description gives no parameter-level detail, but the names are self-explanatory and the schema includes defaults. This is average for a simple listing tool with no required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('consultar grupo servico') and a resource (public service data for public purchases), and it names the API path. This is clear enough to distinguish it from sibling tools in the same module, such as _1_consultar_secao_servico or _2_consultar_divisao_servico, based on the 'grupo' resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not explain that this is the hierarchical step between divisao and classe, nor does it mention that sibling tools like _4_consultar_classe_servico serve a different level. An agent would have to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the behavioral disclosure burden. It says 'dados públicos' but does not disclose pagination behavior, result limits, or the effect of the required 'statusOrgao' parameter. The description also does not clarify whether results are normalized, which is especially relevant given the 'formato' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and reasonably compact, but it mixes the endpoint path in a way that reads like machine-generated text and does not front-load the most decision-relevant behavioral detail. There is no waste, yet no structured guidance either.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, a required parameter, no output schema, and no annotations, this description is not enough for an agent to call it correctly in all contexts. It does not indicate which filters are mutually exclusive, which are optional, how pagination interacts with limits, or what the return shape looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 27%, and the description does not explain any parameters beyond naming the resource. The schema documents 'formato' and 'auto_paginar' directly, but the remaining nine parameters—especially required 'statusOrgao' and filter fields like 'codigoOrgao', 'cnpjCpfOrgao', and 'cnpjCpfOrgaoSuperior'—are left without semantic explanation. The description adds no parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Consulta dados públicos') and resource ('órgãos e unidades administrativas'), and it identifies the endpoint action ('consultar orgao'). Although the tool name already encodes the function, the description adds the public-data scope and endpoint path, which clarifies what the action is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explain when to use this tool versus sibling tools like compras_listar_modulo_uasg_2_1_consultar_orgao_csv or compras_listar_modulo_uasg_1_consultar_uasg. There is no mention of preferred filters, expected use cases, or exclusions, so the agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the data is public and that the action is a list, but it does not mention pagination, response shape, server-side filtering behavior, or any other runtime characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler words. It states the operation and the endpoint efficiently, though 'Consulta dados públicos' and 'listar registros' are partially redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two optional parameters, this is minimally viable: it names the resource, the action, and the path. However, with no output schema and no annotation, the missing details about return format, pagination, and the meaning of 'statusAtivo' leave clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% because 'statusAtivo' has no description in the schema, and the tool description adds no explanation of either parameter. The agent must infer that 'statusAtivo' filters by active status and that 'formato' switches response shapes, so the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a list operation: it says 'Consulta dados públicos de catálogos de itens' and explicitly names the endpoint '/v1/catalogos'. This differentiates it at least implicitly from get-by-id siblings like pncp_obter_catalogos_por_id, though it never mentions that alternative by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling list/obtain endpoints. The only contextual hint is 'dados públicos', which is too weak to help an agent decide between this and related catalog tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, yet it only states that the data is public ('dados públicos'). It does not explain what the response contains, how 'normalizado' differs from 'original' behaviorally, or any error or limit characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence and front-loads the resource. However, the clause 'ação obter modalidade fonte orcamentaria' merely restates the tool name and adds no information beyond the path that follows it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should supply return-value and behavioral context, but it gives none. An agent cannot anticipate the response shape, whether the call returns a single record, or where to find valid ID values, leaving the tool under-specified for a 3-parameter call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% — the two required int64 IDs lack descriptions. The description compensates partially by placing {modalidadeId} and {fonteOrcamentariaId} in the URL path, confirming they are the modality and budget-source identifiers. It does not explain what valid IDs are or how to obtain them, and the formato parameter's meaning is left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Consulta') and resource ('modalidades e fontes orçamentárias') and gives the full endpoint path with both path parameters, so an agent can tell this fetches one modality-budget-source association. It is clear, but it does not explicitly differentiate this from the sibling list endpoint pncp_listar_modalidade_fonte_orcamentaria or from related get-by-id tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no when-to-use guidance, no exclusions, and no mention of alternatives such as pncp_listar_modalidade_fonte_orcamentaria for listing. Usage intent must be inferred entirely from the tool name and the ID-bearing path, which is weak guidance given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only reveals the endpoint path; it does not state whether the response is the file content, a download URL, or raw bytes, nor how the 'formato' parameter changes the payload. Error behavior, size limits, and prerequisites are also undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but structurally wasteful: the first clause about 'compras públicas, itens, resultados e arquivos' is generic boilerplate that repeats the tool's broad domain and is redundant with the specific action stated in the second clause. Front-loading 'consultar arquivo no caminho...' would make it tighter and more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the agent is left without knowledge of the return type (file content vs. metadata vs. download link), the practical meaning of 'normalizado' versus 'original', or how this endpoint differs from the sibling list/count file endpoints. This is incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The path template '/v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/arquivos/{sequencialDocumento}' assigns clear semantic roles to 4 of the 5 parameters, which partially compensates for the 20% schema description coverage. However, the 'formato' parameter's effect on the response is left to the schema's terse enum/default, and the description adds nothing beyond the path mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('ação consultar arquivo') and gives the exact REST path, which aligns with the tool name. However, the leading clause 'Consulta dados públicos de compras públicas, itens, resultados e arquivos' describes a much broader scope than the specific single-file action, which muddies the purpose somewhat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the closely related siblings pncp_obter_orgaos_compras_arquivos_por_cnpj_ano_sequencial (list files) and pncp_obter_orgaos_compras_arquivos_quantidade_por_cnpj_ano_sequencial (count files), or the analogous contract-term and IRP file endpoints. An agent must infer the selection entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It only states that the data is public and gives the endpoint path, with no mention of pagination behavior, response size, rate limits, or the fact that all four identifiers must reference an existing ata. Behavioral disclosure is minimal and does not go beyond what the name and path already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence, but its front-loaded clause is generic filler that lists data types not actually returned by this endpoint. The valuable path information is buried mid-sentence rather than being the clear lead, and the Portuguese phrasing is awkward ('contratos ata registo preco').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must do more heavy lifting. It identifies the resource and required identifiers but is silent on return-value shape, response format, and pagination semantics. An agent would struggle with the 13-parameter surface, particularly knowing which of the three pagination parameter styles (page/pageSize, pagina/tamanhoPagina, page_size/tamanho_pagina/auto_paginar/limite_resultados) to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 54%, with the four required identifiers described in the schema; the path in the description reinforces their composite-key roles. However, the description adds nothing about the nine optional parameters, especially the confusing near-duplicate pagination set (page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina, auto_paginar, limite_resultados) or the formato enum. The description neither compensates for undocumented params nor clarifies which pagination parameter is canonical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: consulting contracts (contratos) of a price registration ata, backed by the precise API path /v1/orgaos/{cnpj}/compras/{anoCompra}/{sequencialCompra}/atas/{sequencialAta}/contratos. However, the opening clause 'Consulta dados públicos de compras públicas, itens, resultados e arquivos' is generic and misleading, since this endpoint returns contracts, not items, results, or files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 pncp_obter_orgaos_compras_atas_por_cnpj_anocompra_sequencialcompra_sequencialata (the ata itself), the ata files/partes endpoints, or the consolidated pncp_obter_contrato_completo. The path implies the identifier hierarchy, but no explicit use-case or exclusion conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It only says the action is to consult historical data; it does not disclose the response format, pagination behavior, the default 'normalizado' form, or that several pagination parameters exist (page/pagina/pageSize/page_size/tamanhoPagina/tamanho_pagina). For a read-only historical query, the lack of pagination/format behavior disclosure is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no fluff, but it primarily restates the endpoint path from the tool name. It is concise yet superficial: it earns its place but adds only slightly more than the name/schema already convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, no annotations, low schema coverage, and no output schema, the description is too thin. An agent knows the endpoint template from the description (helpful), but it lacks information about pagination semantics, response format, the difference between 'normalizado' and 'original', and how this relates to the sibling quantity/arquivo tools. The endpoint path helps, but it is not enough for a complex 13-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (23%). The description does add the meaning of the four required path-style parameters (cnpj, ano, sequencial, sequencialAta), but it does not explain the pagination or output-format parameters. Baseline 3 is fair because the description clarifies the core resource path, but it does not compensate for the 77% of parameters lacking schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('consultar') and resource ('historico ata' at a precise API path), and the name makes the target entity clear (historico of atas for a given org, compra, and ata). It doesn't explicitly distinguish from closely related siblings like pncp_obter_orgaos_compras_atas_historico_quantidade..., but the path and intent are sufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a literal API path but no guidance on when to choose this tool over closely related siblings (e.g., quantidade, arquivos, contratos, partesenvolvidas). It does not mention pagination, the formato options, auto_paginar, or any preconditions. An agent gets no explicit selection signal beyond the endpoint path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says the tool 'consults public data' and lists records, which implies a read-only operation, but it does not disclose pagination behavior, response shape, potential large result sets, or any authentication/availability considerations. The generic phrase 'compras públicas, itens, resultados e arquivos' (public purchases, items, results, and files) actually overstates the endpoint's narrow scope (budget sources) and is slightly misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence that front-loads the action and includes the endpoint path, which is useful. However, the phrase 'compras públicas, itens, resultados e arquivos' is a redundant preamble that lists things this endpoint does not specifically target (it targets budget sources), so the sentence wastes some words on inaccurate scope instead of defining the exact resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description alone must enable correct invocation. It names the four parameters only indirectly through the path and fails to explain what the response contains, whether the result is paginated, or how it differs from the sibling endpoint that returns a single budget source by its ID. Given the large sibling family with nearly identical path patterns, this description is not complete enough for reliable agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%: cnpj, ano, and sequencial have no descriptions, so the agent must infer their meaning from the endpoint path in the description. The description adds little beyond the path, although the path itself does clarify that cnpj, ano, and sequencial identify an procurement record. The 'formato' parameter is documented in the schema but not mentioned in the description, and the description does not explain what kind of identifiers are expected (e.g., CNPJ format, integer ranges).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Consulta dados públicos de compras públicas, itens, resultados e arquivos') and the precise endpoint path ('/v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/fonte-orcamentaria') for listing records. It clearly identifies the resource (budget source of a public purchase) but doesn't explicitly differentiate it from the closely related sibling pncp_obter_orgaos_compras_fonte_orcamentaria_por_cnpj_ano_sequencial_fonteorcamentariaid, which retrieves a specific item rather than the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when querying public purchase data by CNPJ, year, and sequential number for budget sources. However, it provides no explicit guidance on when not to use it or which alternative to prefer, such as the sibling that fetches a single budget source by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are entirely absent, so the description carries the burden. It does convey read-only semantics on public data ('Consulta dados públicos' and 'ação obter registro'), which is useful safety information. However, it discloses nothing about response format, authentication needs, rate limits, or error behavior, and 'obter registro' only implies a single-record response rather than stating it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first clause is loosely worded and partially irrelevant: 'dados públicos de compras públicas' is repetitive, and the list of 'itens, resultados e arquivos' does not apply to this specific endpoint. The precise path clause is useful but comes second, after the generic preamble.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 4 of 5 parameters undocumented in the schema, the description should clarify parameter roles, the nature of the returned record, and how this differs from the sibling list endpoint. It provides the path but none of that explicit context, leaving an agent to reverse-engineer the semantics from the tool name and sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% — just the formato parameter is documented. The description compensates minimally by embedding cnpj, ano, sequencial, and fonteOrcamentariaId in the URL path, implying a hierarchy of identifiers, but it never explains their domain meaning (e.g., what 'sequencial' refers to) and adds nothing about the formato parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The second clause gives a specific verb and resource: 'ação obter registro no caminho /v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/fonte-orcamentaria/{fonteOrcamentariaId}' — a single-record GET for a budget-source entry, which distinguishes it from the sibling collection endpoint pncp_obter_orgaos_compras_fonte_orcamentaria_por_cnpj_ano_sequencial. However, the opening clause 'Consulta dados públicos de compras públicas, itens, resultados e arquivos' is overly broad and lists resources (items, results, files) this endpoint does not return, muddying the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description never states it is for fetching one specific budget-source record once the ID is known, nor does it contrast with the list variant pncp_obter_orgaos_compras_fonte_orcamentaria_por_cnpj_ano_sequencial. An agent must infer the usage boundary from the tool name and path alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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, but it only states that the operation is a consultation and gives the URL. It does not disclose the response shape (single object vs collection), whether 'arquivos' are actually included in results, the behavioral difference between formato 'normalizado' and 'original', or any authentication or rate-limit considerations despite mentioning 'dados públicos'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and packs the essential path into one sentence, but the phrasing is redundant ('Consulta dados públicos de compras públicas') and the generic resource list dilutes the message. The distinguishing path information appears only in the second half rather than being front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 required parameters, no output schema, and no annotations, the description leaves critical gaps: it does not explain what data is returned, how a resultado relates to the parent purchase/item, or that the formato parameter can switch between normalized and original payloads. An agent could construct the URL from the path but would be guessing about the response and how to chain this call with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The path template adds structural meaning beyond the bare schema by mapping each undocumented parameter (cnpj, ano, sequencial, numeroItem, sequencialResultado) to its position in the resource hierarchy. However, schema description coverage is only 17%, and the description does not explain the semantic role of identifiers like 'sequencial' or 'sequencialResultado' or how an agent would discover valid values for them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('consultar resultado') and gives the full endpoint path /v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/itens/{numeroItem}/resultados/{sequencialResultado}, which differentiates this tool from the sibling that returns all results for an item. However, the opening clause lists several resources ('compras públicas, itens, resultados e arquivos') without clarifying what this endpoint actually returns, and it never defines what a 'resultado' is in this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the closely related sibling pncp_obter_orgaos_compras_itens_resultados_por_cnpj_ano_sequencial_numeroitem (which lacks the sequencialResultado segment) or how to obtain the five identifier values from prior listing calls. The path identifies the endpoint but provides no decision context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the data scope and endpoint but does not explain aggregation semantics, pagination/limit behavior, error cases, or whether the 'normalizado' vs 'original' format affects the count result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and reasonably compact. However, it is front-loaded with redundant phrases ('dados públicos de contratos públicos') and mixes a Portuguese functional description with an endpoint string, which adds noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, no output schema, and a huge sibling list with many similar count tools. The description only echoes the endpoint path; it does not specify input formats, output shape, or the distinguishing conditions against sibling count tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%. The description adds the endpoint path and the overall contract-document-count concept, which clarifies that cnpj/ano/sequencial identify a contract and that the result is a file quantity. It does not define the CNPJ format or connection between sequencial and the resource beyond the path, but the path provides most of the mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the data scope (contracts, empenhos, termos, arquivos) and the endpoint path with its resource/action (consultar contrato documento quantidade). It's clear enough about what the tool does, though it reads like a direct copy of an API route description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is essentially the endpoint signature restated. It does not say when to choose this tool over its siblings, and the sibling list has several nearly identical 'quantidade' variants (e.g., for compras, IRP, históricos) that an agent could confuse with this contract-file-count tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It indicates the operation is a public-data query, implying a read-only GET, but it does not disclose the response format, whether the file is returned as content or metadata, auth requirements, or error behavior for missing documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and includes the full path, which is useful and concrete. However, the phrase 'dados públicos de contratos públicos' is redundant, and the mention of 'empenhos' is tangential to this endpoint, making the opening clause less focused than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and dozens of closely related sibling tools, the description is incomplete. It does not explain what the response contains, how it differs from sibling file-list and file-count endpoints, or what an agent should do if the target file does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description needed to compensate. The endpoint path does add hierarchical meaning by showing that cnpj, ano, and sequencial locate a contract, sequencialTermo locates a term, and sequencialDocumento locates a specific file. However, it does not explain formats or exact meanings beyond the parameter names, leaving some ambiguity around cnpj formatting and the role of 'sequencial.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as 'consultar arquivo' and provides the exact endpoint path ending in '/arquivos/{sequencialDocumento}', which specifies a single file resource. However, the opening clause lists 'contratos públicos, empenhos, termos e arquivos' broadly, which is somewhat broader than the actual targeted resource and does not explicitly contrast this endpoint with its many sibling file-list or file-count tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as the term-file list endpoint or the contract-file endpoint. The path implies this retrieves one specific document file, but the description does not state exclusions like 'use this when you have sequencialDocumento, not for listing files.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does disclose one genuinely valuable behavioral trait — results are not deduplicated — and the verb 'Pesquisa' implies a read-only search operation. However, it says nothing about pagination, result limits, how multi-source results are aggregated, or filter behavior, so the disclosure is thin for a 10-parameter search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler: verb, resource, scope, and the deduplication caveat are all front-loaded. Every word earns its place. It is slightly under-sized relative to the tool's 10-parameter complexity, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, so that side is handled. But the input side is incomplete: 10 parameters, zero schema descriptions, no annotations, and a one-sentence description. An agent cannot determine date formats, whether filters are combinable or mutually exclusive, or which values `fonte` accepts beyond the 'todas' default. This is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 but barely does: 'nas fontes catalogadas' only loosely maps to the `fonte` parameter. The required `texto` parameter is never explained, and there is no guidance on how cnpj, uasg, data_inicio/data_fim, modalidade, codigo_servico, or codigo_material behave or combine. Parameter names are self-descriptive in Portuguese, but the description adds essentially no semantic value beyond them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pesquisa') and names the resource ('compras públicas'), adding scope with 'nas fontes catalogadas' and a distinguishing behavioral trait, 'sem deduplicar resultados.' This separates it from the many id/cnpj-specific consultation siblings even without naming one explicitly. It is clearly more than a tautology of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this broad search versus the dozens of sibling consultation tools (e.g., compras_listar_modulo_contratacoes_* or pncp_obter_*). The 'sem deduplicar resultados' clause hints that it returns raw, unfiltered results, but no alternative tool is named and no condition is stated. An agent must infer the tool's role from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Não há annotations, então a descrição deveria assumir o papel de informar comportamento. Ela diz que os dados são públicos e que a operação é de consulta, o que sugere leitura sem autenticação, mas não informa formato de retorno, paginação, erros, limites ou efeitos da operação.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A descrição é curta, com a informação principal (dados públicos de atas) no início e o endpoint no fim. Não há enrolação, embora a frase 'ação consultar arp id no caminho...' seja um pouco redundante com o próprio nome.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para uma ferramenta sem schema de saída e sem annotations, faltam detalhes essenciais: o que exatamente é retornado, se a resposta é única ou paginada, e quando preferir esta chamada a consultar_arp ou consultar_arp_fim_vigencia. A descrição cobre apenas o recurso e o endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
O schema já documenta formato e dataAtualizacao (67% de cobertura), e a menção a 'consultar arp id' ajuda a conectar o parâmetro obrigatório numeroControlePncpAta ao identificador da ata. Porém, a descrição não detalha o significado de numeroControlePncpAta nem a interação entre dataAtualizacao e formato.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição identifica verbo e recurso: 'consulta dados públicos de atas de registro de preços' e indica a ação exata 'consultar arp id' com o caminho /modulo-arp/1.1_consultarARP_Id. Isso permite diferenciá-lo de ferramentas irmãs como consultar_arp_fim_vigencia, embora não explique explicitamente que o parâmetro obrigatório é o identificador da ata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Não há orientação sobre quando usar esta ferramenta em vez das alternativas do módulo ARP, nem exclusões ou pré-condições. O contexto de 'consultar por ID' fica implícito no nome e no caminho, não na descrição.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It signals a read-only operation on public data, which is useful, but it does not disclose response behavior, error cases, pagination, or authentication requirements. The 'consulta' wording plus 'dados públicos' is moderately transparent but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the core action and resource, and including the endpoint path is genuinely useful. It has minor redundancy ('públicos de contratos públicos'), but overall it is compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling-tool family, no output schema, and two required parameters with ambiguous semantics, the description is too thin. It does not explain the identification model, what kind of ID is expected, or when this endpoint is preferable to the many related contract listing and detail tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and the description adds no explanation of how 'codigo' and 'tipo' relate. The enum values hint that 'codigo' is either a purchase ID or a PNCP contract control number, but the description never clarifies this relationship. The 'formato' parameter is documented in the schema, but the two required parameters are left underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a query action ('Consulta') against public contract data and includes the exact API path. It does not explicitly differentiate from sibling contract tools like the list or end-of-validity variants, but the verb and resource are specific enough for basic purpose identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this endpoint versus alternatives such as compras_listar_modulo_contratos_1_consultar_contratos or compras_listar_modulo_contratos_1_2_consultar_contratos_fim_vigencia. There is no mention of use cases, exclusions, or relationships to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden; it does add that the data is public (implying read-only, no auth) and legacy. But it discloses nothing about pagination defaults, the normalizado/original response format behavior, auto-paginar, or result limits, which matter for a list endpoint of 15 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence front-loads the purpose and then gives the endpoint, with no filler or repetition. The brevity is structurally efficient, though the resulting under-specification is penalized under contextual completeness rather than here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 15-parameter tool with no annotations and no output schema, yet the description is one sentence. It omits the required date-range contract, pagination behavior, and the relationship to the sibling _id endpoint, which is far from enough for reliable selection and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, leaving 10 of 15 parameters undocumented, including ambiguous duplicated pagination aliases (page/pagina/pageSize/page_size/tamanhoPagina/tamanho_pagina) and filters like uasg, modalidade, and numero_aviso. The description adds zero parameter meaning and does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Consulta) and a clear resource (dados públicos de licitações e compras legadas) and adds the API path, so an agent can identify what domain it operates in. However, it does not differentiate from its near-identical sibling compras_listar_modulo_legado_1_1_consultar_licitacao_id, which is the same module and action scoped by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the _id variant, the item endpoints, or the other modulo_legado tools. The two required date-range parameters imply a listing search, but the description never states that use case nor names any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; it does disclose that the operation reads public data ('dados públicos'), implying a safe read-only call. It does not mention response format, errors, rate limits, or any other side effects, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single efficient sentence with the core action and endpoint front-loaded. It wastes little space, though the word 'ação' is slightly redundant and no guidance is packed into the spare structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a large sibling family, the description is too thin to reliably orient an agent. It omits selection criteria, parameter roles (which id identifies the item vs the purchase), and any behavior of the optional 'dt_alteracao' filter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds no parameter-level meaning. It highlights 'item licitacao id' while the only required parameter is 'id_compra' and 'id_compra_item' is optional, which can confuse an agent about which identifier to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Consulta dados públicos...') and resource ('item licitacao id') and even gives the endpoint path. However, it does not explicitly contrast this with the very similar sibling 'compras_listar_modulo_legado_2_consultar_item_licitacao', so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to choose this tool over the many sibling legacy-module tools, nor any exclusions or prerequisites. The verb 'consultar' implies a query use case, but that is implicit rather than stated guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. 'Consulta dados públicos' does convey that this is a read-only, public-data operation, which is useful. However, it does not disclose pagination behavior, response format, or any operational caveats such as how auto_paginar and limite_resultados interact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and includes the endpoint path. It is not bloated, though it could have used the space to add parameter or usage context instead of repeating the tool's inherent purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 optional parameters, no output schema, no annotations, and a large sibling set, this one-sentence description is incomplete. It does not clarify what group material means, how filters combine, what the response contains, or when the agent should prefer this endpoint over related material hierarchy endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description should compensate for the undocumented parameters. It does not explain page versus pagina, codigoGrupo, statusGrupo, or how limite_resultados relates to pagination. The schema's existing descriptions cover some parameters, but the missing ones are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('consultar grupo material') and the resource ('dados públicos de materiais para compras públicas'), and gives the API path. It is specific enough to distinguish from the many sibling material tools, though it does not explicitly contrast it with related hierarchy tools like class or item material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as consultar_classe_material, consultar_item_material, or other material modules. The description only states what it does, leaving the agent to infer the appropriate selection context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It conveys that the operation is a read-only query of public data, which implies no authorization is needed and no mutation occurs; however, it does not disclose output format, pagination behavior, or error semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that combines domain, action, and endpoint path without redundant fluff. Minor structural clumsiness ('ação consultar material detalhe no caminho') does not hurt comprehensibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 12 parameters, several closely related siblings, and no output schema or annotations, yet the description only gives the endpoint and a generic action. Missing are what the detail response contains, how pagination works, and how this differs from the CSV or list siblings in the same module.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 42%, and the description provides no parameter-level meaning beyond 'material detail'. It does not explain that codigoItemCatalogo identifies the target item or what date-range and pagination parameters control, so it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action and resource: it queries public price-research data and specifically consults material details, including the endpoint path. It is not a tautology because it adds the public-data scope, though it does not explicitly differentiate itself from sibling tools like consultar_material or the CSV variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling alternatives such as compras_listar_modulo_pesquisa_preco_1_consultar_material or the CSV detail variant. The endpoint path and action imply a detail lookup, but the description never states conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool queries public data (implying read-only), but does not describe response format, pagination behavior, the meaning of 'normalizado' vs 'original' formats, or any rate limits or data volume implications. The 'auto_paginar' and 'limite_resultados' parameters hint at aggregation behavior, but the description does not clarify it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core purpose as 'Consulta dados públicos de planejamento de contratações' before mentioning the specific action. It uses no filler, though it could replace the redundant path fragment with a clearer conceptual phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, the description is too thin. It does not clarify the relationship between required parameters (anoPcaProjetoCompra, tipo, codigo), the expected values for 'codigo' (class code for material vs group code for service is only in the schema's parameter description), or the pagination/format options. An agent would struggle to know what data this returns and how it differs from sibling PGC tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only documents 4 of 12 parameters explicitly (33% coverage), so the description partially compensates by naming 'anoPcaProjetoCompra', 'tipo', and 'codigo' through context. The description itself doesn't define these, but the schema's required fields and enum values for 'tipo' add meaning. The many duplicate pagination parameters (page/pagina, pageSize/page_size/tamanhoPagina/tamanho_pagina) remain unexplained and confusing, which the description does not clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta') and resource ('dados públicos de planejamento de contratações'), and identifies the action/path ('consultar pgc detalhe catalogo'). It is clear about what the tool does, though it doesn't differentiate from the sibling 'compras_listar_modulo_pgc_1_consultar_pgc_detalhe' or the CSV variant 'compras_listar_modulo_pgc_2_1_consultar_pgc_detalhe_catalogo_csv' explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying public procurement planning data with catalog details, but provides no explicit guidance on when to use this tool versus alternatives such as the CSV variant or the related PGC detail tool. There is no mention of exclusions, preconditions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention pagination despite the schema exposing page, pagina, and auto_paginar parameters; it does not say whether statusNaturezaDespesa filters active/inactive records; it does not describe response shape or whether the 'normalizado' format transforms the payload. The description adds almost no behavioral context beyond the URL path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is dense and path-internal jargon ('ação consultar natureza despesa servico no caminho ...') rather than a clean, front-loaded explanation. It is concise but not optimally structured for an agent to quickly parse the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, no annotations, and a large sibling set, the description is incomplete. An agent cannot determine what filters are meaningful, whether this is a list vs. detail endpoint, how pagination interacts with auto_paginar, or what the response contains. The tool needs more behavioral and filtering context to be safely invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 38% schema description coverage, the description needed to compensate, and it partially does by naming the endpoint action and domain. The schema itself documents formato and auto_paginar, and the description implicitly ties the tool to natureza de despesa of serviço, which gives meaning to codigoNaturezaDespesa and statusNaturezaDespesa. However, it does not explain pagination parameters' semantics, nor the relationship between codigoServico, codigoNaturezaDespesa, and statusNaturezaDespesa.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('consultar natureza despesa servico') and resource ('dados públicos de serviços para compras públicas'), which distinguishes it from sibling service-lookup tools that focus on sections, divisions, groups, classes, or items. However, it is in Portuguese and mixes the tool name with the action, making it less crisp for an agent than an English or clearly-sentence-structured description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to choose this tool over the many sibling service-modulo tools (e.g., consultar_item_servico, consultar_classe_servico). It does not state what type of query or data this endpoint is best for, nor does it distinguish from the material-natureza-despesa sibling. Usage context is only implied by the tool name and URL path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the data is public ('dados públicos'), implying no special authentication is needed, and the 'consulta/listar' wording signals a non-destructive read. However, it omits pagination behavior, rate limits, and any side-effect or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the purpose and then specifies the path. No wasted words, though the generic 'consulta' verb could have been swapped for more useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of annotations and an output schema, the description is the agent's only source of context. It fails to explain statusAtivo, the difference from the por_id sibling, pagination, or what the response contains, leaving meaningful gaps for a simple but non-trivial list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: formato is documented in the schema, but statusAtivo has no description. The tool description adds no parameter information at all, so statusAtivo's meaning (presumably filtering by active status) remains entirely guesswork for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('ação listar registros'), a specific resource ('tipos de instrumentos de cobrança'), and the exact API path (/v1/tipos-instrumentos-cobranca). It conveys that this is a public-data listing operation, and the 'listar' framing implicitly contrasts with the sibling pncp_obter_tipos_instrumentos_cobranca_por_id, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the by-id sibling or the many other pncp_listar_* reference-data tools. The listing intent is implied by the word 'listar', but no exclusions, prerequisites, or alternative-selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose that the data is public and that this is a listing/read operation, which is useful. However, it does not describe what the response contains, whether pagination exists, how statusAtivo affects results, or any other behavioral detail beyond the endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, and it adds the endpoint path without unnecessary filler. The semicolon construction is slightly awkward, but the overall length is appropriate for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and an undocumented statusAtivo parameter, the description is too thin. It does not mention return value shape, filtering semantics, or how it relates to the by-id sibling, leaving an agent to guess important invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds no explanation for the two parameters. The formato parameter is documented in the schema, but statusAtivo has no schema description and the tool description does not clarify whether it filters to active instrument types or what its default behavior is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Consulta dados públicos... lista registros') and the specific resource ('tipos de instrumentos convocatórios') with the API path included. It is distinct enough from siblings like pncp_obter_tipos_instrumentos_convocatorios_por_id because it names the list operation rather than a single-record lookup, though it does not explicitly contrast the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this listing endpoint over related alternatives such as the by-id getter or association endpoints like pncp_listar_tipo_instrumento_convocatorio_modo_disputa. The word 'listar' implies collection-level use, but there are no explicit conditions, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Consulta dados públicos' (queries public data), which signals a read-only operation, but provides no context on response format, pagination, error behavior, or whether the 'formato' parameter changes the payload structure. Given there is no output schema, this is a considerable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that identifies the action, resource, and endpoint path. It is front-loaded with the core purpose and contains no filler. It loses a point for not adding any searchable context about the data format or parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a get-by-id reference lookup tool with no output schema and no annotations, the description provides only the basic purpose. It omits the meaning of the response, the effect of the 'formato' enum, and the relationship to list-style siblings. The endpoint path helps, but the agent still lacks enough context to invoke the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: the 'formato' parameter already has a schema description stating 'Formato da resposta: normalizado ou payload original', and the description adds nothing about it. The 'id' parameter is required but only minimally defined as an integer; the description doesn't explain what identifier this refers to (e.g., modality ID) beyond the endpoint path. The description does not compensate for the undocumented half of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Consulta' (queries) and the resource 'modalidades de contratação', plus the endpoint path '/v1/modalidades/{id}' which clarifies this is a get-by-id operation. However, it doesn't explicitly distinguish it from the sibling 'pncp_listar_modalidades' (list all) and other similar 'obter_*_por_id' lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool over alternatives. It does not mention that this is for fetching a single modality by ID, nor does it exclude it from list-oriented siblings like 'pncp_listar_modalidades' or other related PNCP reference endpoints. The agent must infer usage from the endpoint path and naming convention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It states the data is 'públicos' (public) and the action is a query, which implies read-only access without authentication, but it discloses nothing about the response shape, record fields, error behavior on a nonexistent ID, or pagination. For a tool with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that front-loads the purpose and ends with the concrete API path. Every element earns its place, though it reads slightly like a technical endpoint note rather than agent-facing prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple public get-by-id endpoint with 2 parameters and no output schema, the description is minimally viable: it conveys public read access, the resource, and the route. However, it omits what a 'modo de disputa' record contains, how an agent obtains a valid ID (e.g., via the list sibling), and any error/response behavior. These gaps are modest for such a simple fetch but still present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: the 'formato' parameter is already documented in the schema with a clear enum, while 'id' has no schema description. The tool description adds no parameter-level semantics, but 'id' is made self-evident by the tool name ('por_id') and the path placeholder {id}. The combination of schema, name, and path adequately compensates for the description's silence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Consulta'/'obter') and resource ('modos de disputa'), and pinpoints the REST path /v1/modos-disputas/{id}, making the get-by-id intent unambiguous. It distinguishes itself from the sibling list tool (pncp_listar_modos_disputas) through the path's {id} placeholder, though it never explicitly names that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. There is no statement like 'use this when you have a specific mode-of-dispute ID' nor any mention that pncp_listar_modos_disputas should be used to enumerate records or discover IDs. The usage context is only implied by the name and path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Consulta dados públicos' (queries public data) which implies a read-only operation, but it doesn't disclose what the response contains, whether the formato parameter changes structure significantly, whether pagination is involved, or whether missing ata records produce errors or empty results. The description is too thin for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient, but it wastes space by repeating the API path that the tool name already encodes. The path inclusion is somewhat useful for disambiguation, but the opening 'Consulta dados públicos de compras públicas' is generic and could apply to dozens of siblings. It is concise but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 5 parameters, 4 required, no output schema, and no annotations. The description does not explain the return value shape, the meaning of 'ata' in this context, the difference between 'normalizado' and 'original' response formats, or the relationship to the many ata-related siblings. Given the complexity of the public procurement domain, the description is insufficient for an agent to confidently select and call this tool without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'formato' has a description). The description itself does not explain the required parameters (cnpj, anoCompra, sequencialCompra, sequencialAta), though the values are largely inferable from their names and path. The 'formato' parameter is described in the schema, and the description adds nothing about how the response format varies. Baseline 3 applies because the schema partially covers one parameter but the others are minimally documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Consulta dados públicos de compras públicas') and specifies the resource path including 'atas' (minutes/records), which identifies this as retrieving public procurement ata records. It differentiates from sibling tools that target arquivos, contratos, itens, etc. However, it doesn't clearly state that this returns the specific ata by sequencialAta, and the generic 'dados públicos' phrasing is vague about the exact entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that the sibling pncp_obter_orgaos_compras_atas_por_cnpj_anocompra_sequencialcompra lists atas for a compra without the sequencialAta parameter, or that pncp_obter_ata_completa provides a consolidated view. An agent must infer the purpose from the parameter path alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does indicate this is a public read-only query via 'Consulta dados públicos' and 'ação consultar', which is useful. However, it does not mention response format details, authentication expectations, or how the 'formato' option changes behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence that states the action and the full endpoint path without filler. It is concise, though the phrase 'itens, resultados e arquivos' is slightly over-broad.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no annotations, and no output schema, the description is too thin to make the tool fully self-contained. It omits when to use this item-level endpoint over the item-list or item-result siblings, what the returned data contains, and how the 'normalizado' versus 'original' formats affect the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, covering just 'formato'. The required parameters cnpj, ano, sequencial, and numeroItem have no schema descriptions, and the description does not explain them beyond repeating their names in the URL path. An agent gets little semantic guidance for values such as 'sequencial' versus 'numeroItem'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('consultar'), a specific resource ('compra item'), and provides the exact API path with the item identifier, so an agent can understand this fetches a single item in a public purchase. However, the opening phrase mentions 'itens, resultados e arquivos' more broadly than the endpoint actually covers, and no sibling tool is explicitly named for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related siblings such as pncp_obter_orgaos_compras_itens_por_cnpj_ano_sequencial (item list) or the results/image variants. The path template implies the selection criteria, but no explicit when-to-use or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states that the data are public and the action is a consult/read operation, but it does not disclose whether the response is file content, metadata, normalized JSON, or binary, nor does it mention authentication, rate limits, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and the path template is genuinely useful. The opening clause is somewhat vague and redundant ('públicos' appears twice), but the description as a whole is short and contains no filler beyond that.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and no output schema, the description is too thin. It omits what the caller receives, how sequencialDocumento is obtained, and how this endpoint relates to the file list/count sibling tools, leaving the agent unable to confidently predict the response or workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description partially compensates by embedding the required parameters in the URL path, which hints at their roles. However, it never explains the meaning of 'sequencial' versus 'sequencialDocumento' or how they relate, and the optional 'formato' behavior is left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('consultar arquivo') and resource (a contract file), backed by the full endpoint path including cnpj, ano, sequencial, and sequencialDocumento. This distinguishes it from sibling file-list and file-count tools, though the opening phrase about 'contratos públicos, empenhos, termos e arquivos' is broad and slightly noisy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as pncp_obter_orgaos_contratos_arquivos_por_cnpj_ano_sequencial. The path implies that sequencialDocumento is needed, but the description never states that this is for fetching a single known file or that the sibling list endpoint should be used first to obtain that identifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it only says the data is public and the action is to consult a quantity. It does not disclose what the quantity represents, whether it counts history records, or what the response looks like. 'Consulta' implies read-only, but no concrete behavioral detail is added beyond the path itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the general resource and then specifies the exact action and path. It has little wasted text, though the phrase 'e seus itens' is somewhat broader than the quantity-history endpoint and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, low schema coverage, and a large sibling family, the description is too thin. It does not specify what is counted, the response structure, or how this differs from closely named IRP endpoints, so an agent lacks enough context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% because only 'formato' has a description. The description partially compensates by embedding cnpj, ano, and sequencial in the endpoint path, giving context that these identify an IRP record. However, it does not explain CNPJ formatting, the meaning of sequencial, or the expected range of ano, leaving meaningful gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('consultar quantidade') and a concrete resource path under /v1/orgaos/{cnpj}/irp/{ano}/{sequencial}/historico/quantidade, making it clear this is a quantity/history query for IRP data. It distinguishes from the sibling pncp_obter_orgaos_irp_historico_por_cnpj_ano_sequencial by emphasizing 'quantidade', though it does not explicitly name any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many related IRP endpoints, such as the full history, items, or files variants. The path implies a count-oriented use case, but no explicit context, exclusions, or alternative-selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does convey that the operation is a public read-only lookup via 'Consulta dados públicos' and 'consultar item irp', which is useful. However, it does not disclose response format, error behavior, authentication needs, or any operational caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the resource and action and includes the precise endpoint path. There is slight redundancy between the opening phrase and the action phrase, but nothing excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete for reliable invocation. It omits expected return shape, how the parameters relate to the IRP parent entity, and any guidance on interpreting or requesting results. The schema's formato description helps only marginally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description does not compensate. The endpoint path repeats the parameter names but adds no meaningful semantics for cnpj, ano, sequencial, or numeroItem beyond what the schema already shows. Only the formato parameter has a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: consulting a specific item of an IRP (intenção de registro de preços) and gives the exact endpoint path. This distinguishes it as the single-item variant of the IRP item endpoint, though it does not explicitly name or contrast sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as the list-items endpoint or other IRP-related tools. It only states the action and path, leaving the selection criteria implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says the tool consults public IRP data and includes the path. It does not disclose whether this is read-only, whether the response may be paginated, whether the formato parameter changes the response shape, or any other behavioral trait. The phrase 'dados públicos' implies a safe read but is not enough to satisfy behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the core purpose and the API path. It is relatively compact and does not waste words. However, it is structurally cluttered by mixing Portuguese description text with the API path and lacks lightweight structure such as separating the usage context from the technical endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and this is a retrieval tool with 4 parameters. An agent needs more context about what data is returned, what 'normalizado' versus 'original' means for the response, and whether all fields are included. The path is helpful and the tool name maps to sibling endpoints, but the description is too sparse to be considered complete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%: three required parameters (cnpj, ano, sequencial) have no descriptions in the schema. The tool description itself doesn't add meaning to those parameters; however, the name and path pattern explicitly convey the role of the required parameters: orgão CNPJ, year, and sequential number. The optional formato parameter does have a schema description. The description provides some contextual semantics via the path, compensating for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Consulta dados públicos de intenções de registro de preços e seus itens' and includes the API path. It is clear this tool retrieves public data about price-registration intentions and their items. It doesn't explicitly distinguish itself from the sibling tools, but the path and name make the target resource reasonably identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of alternatives. The description does not mention exclusions, conditions, or when to prefer a sibling tool. It gives basic context that the data is public, but this does not help an agent select between this and similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that public data is queried and provides the path; it does not describe the response shape, pagination, year availability, what 'consolidado' contains, or how the formato parameter changes behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no redundant filler, and the actionable content (query type, public data, endpoint path) is front-loaded. The phrasing is slightly awkward ('ação consultar dados orgao pca no caminho'), but it earns its place by conveying the route.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, this description is incomplete. It does not explain what the consolidated response contains, does not distinguish itself from the many similar PCA siblings in the tool list, and leaves the meaning of 'normalizado/original' formats to inference. An agent could easily select the wrong PCA variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (formato is the only documented parameter). The description partially compensates by embedding {cnpj} and {ano} in the path, making their roles inferable from the route, but it does not specify CNPJ format constraints, valid year ranges, or what 'normalizado' vs 'original' means beyond the schema's terse phrasing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (consulta) and resource (dados públicos de planos de contratações anuais) and includes the endpoint path /v1/orgaos/{cnpj}/pca/{ano}/consolidado, which pins down the scope. It conveys the 'consolidado' variant, but it does not explicitly differentiate itself from closely named siblings like pncp_obter_orgaos_pca_consolidado_unidades_por_cnpj_ano or pncp_obter_orgaos_pca_consolidado_por_cnpj_ano_sequencial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives. Given at least three near-siblings (consolidado_unidades, consolidado_por_cnpj_ano_sequencial, pca_csv_por_cnpj_ano), the absence of any selection criteria or exclusions is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It only states that the tool 'consulta dados públicos', implying a read-only safe operation, but discloses nothing else: no mention of response format differences beyond the schema's formato enum, no pagination, no rate limits, and no note that 'consolidado' merges plan data in a specific way. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with no filler. The purpose is front-loaded and the API path earns its place by clarifying both scope and parameter mapping. The semicolon splice is slightly awkward but does not impair readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, this description leaves too much to inference. It does not differentiate itself from the near-identical sibling pncp_obter_orgaos_pca_consolidado_por_cnpj_ano, does not explain the meaning of 'consolidado', and provides no information about the shape or scope of the response. An agent could select or invoke it correctly, but only by reasoning through the name and path rather than from explicit guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25% — only 'formato' is documented in the schema). The description partially compensates by embedding cnpj, ano, and sequencial in the URL template /v1/orgaos/{cnpj}/pca/{ano}/{sequencial}/consolidado, which clarifies their roles as path identifiers. However, it does not explain what 'sequencial' semantically refers to (the plan sequence within a year) or what 'normalizado' vs 'original' output means, leaving real gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Consulta') and resource ('dados públicos de planos de contratações anuais'), and further narrows it to the 'plano consolidado' operation via the explicit API path. The path template disambiguates this tool from the sibling pncp_obter_orgaos_pca_consolidado_por_cnpj_ano by including the {sequencial} segment, though it never explicitly contrasts the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention the sibling without 'sequencial' (year-level consolidated plan), the unidades variant, or the itens variants, nor does it state any preconditions (e.g., needing the sequencial from a prior list call). Usage context must be inferred entirely from the name and path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 implies a safe read operation by stating the data is 'públicos' and the verb is 'consultar', but it never discloses the response shape or clarifies what 'plano com itens' returns relative to the items-only sibling endpoint. The normalizado/original transform implied by the formato parameter is only documented in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the domain front-loaded before the route detail; there is no filler. The semicolon splice is slightly awkward, but the content is efficient and ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must make selection and invocation safe on its own. It provides the route and lets the path parameters be inferred, but it leaves the ambiguity with pncp_obter_orgaos_pca_itens_por_cnpj_ano_sequencial unresolved and gives no expectation of the returned payload. An agent could plausibly invoke the wrong sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (just formato is documented), so the description must compensate for undocumented cnpj, ano, and sequencial. The path template '/v1/orgaos/{cnpj}/pca/{ano}/{sequencial}/itens/plano' does map these parameters to URL positions, adding structural meaning. Yet it never explains what sequencial represents (plan sequence number) or the expected CNPJ format, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Consulta') and resource ('dados públicos de planos de contratações anuais') and pins the action to the exact route '/v1/orgaos/{cnpj}/pca/{ano}/{sequencial}/itens/plano', clarifying this is the plan-with-items variant. However, it does not distinguish this tool from the near-identical sibling pncp_obter_orgaos_pca_itens_por_cnpj_ano_sequencial, so part of the differentiation must be inferred from the route suffix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this endpoint versus the many PCA siblings such as pncp_obter_orgaos_pca_itens_por_cnpj_ano_sequencial, pncp_obter_orgaos_pca_itens_contratacao_por_cnpj_ano_sequencial, or pncp_obter_orgaos_pca_itens_quantidade_por_cnpj_ano_sequencial. There are no conditions, exclusions, or alternative pointers, leaving tool selection to guesswork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only states that the data is public and the action is a query; it does not describe response structure, pagination, normalization differences, error behavior, or any other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler words. It front-loads the resource type and then gives the exact endpoint path, making it easy to scan, though the path largely repeats information already in the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a large sibling set of similar PCA tools, the description leaves too much unstated. An agent still cannot tell what 'sequenciaisplano' actually returns, when to prefer it over related endpoints, or what response to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 25%, and the description helps only by embedding cnpj, uasg, and ano in the path template, clarifying their role as path parameters. It does not explain acceptable formats, value semantics, or the meaning of 'sequenciaisplano'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('consultar sequenciais do plano') and identifies the resource ('planos de contratações anuais') plus the exact API path. This distinguishes it from sibling PCA endpoints like consolidado or itens, though only implicitly via the path segment 'sequenciaisplano'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling PCA tools, such as pca_consolidado_por_cnpj_ano, pca_itens_por_cnpj_ano_sequencial, or pca_quantidade_por_cnpj_ano. There is no when/when-not or alternative selection advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It explicitly discloses that this is a read operation on 'dados públicos' (public data), which signals a non-destructive, likely unauthenticated query. However, it does not mention response shape, possible error behavior for invalid CNPJs, or the meaning of the normalizado/original output modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with no filler, front-loading the purpose before the endpoint detail. It is slightly redundant because 'ação consultar ente' repeats the verb from the first clause, but overall it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, plus a sibling list with several similarly named tools, the description is under-specified. It leaves the agent without disambiguation guidance, CNPJ format expectations, or any sense of what the response contains, making correct selection and invocation harder than necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: only 'formato' is documented in the schema, while 'cnpj' has just a type. The description adds no parameter detail beyond restating the placeholder {cnpj} in the path; it fails to specify whether CNPJ should be raw digits or formatted with punctuation, which is essential for a correct call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Consulta') and resource ('dados públicos de órgãos e unidades públicas') and pinpoints the exact endpoint path /v1/orgaos/{cnpj}. It clearly conveys that this tool fetches a single public entity by CNPJ, but it does not explicitly differentiate from near-identical siblings such as pncp_obter_orgaos_unidades_por_cnpj.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives. The only usage signal is the path template /v1/orgaos/{cnpj}, which implies 'use when you have a CNPJ', but the description never states exclusions or points to siblings like pncp_listar_orgaos or pncp_obter_orgaos_unidades_por_cnpj for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does communicate that this is a public-data read operation ('Consulta dados públicos') and shows the HTTP-style path, but it says nothing about response shape, failure behavior, authentication needs, or format expectations. For a read endpoint this is minimal but not dangerously misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence and front-loads the domain ('Consulta dados públicos...') before the specific endpoint. It is concise with no filler, but the phrase 'ação consultar unidade orgao' is awkward and slightly redundant with the path that follows.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a very simple GET-like tool, but with no annotations and no output schema, the description still needs to provide enough context. It gives the path and parameters, yet omits return value shape, CNPJ/unit-code formatting, and any distinction from the sibling list endpoint. An agent could construct the call but would not know what to expect back or when exactly to prefer it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'formato' is documented), so the description must compensate for cnpj and codigoUnidade. The endpoint path does add semantic meaning: cnpj identifies the org and codigoUnidade selects a unit within it. However, it does not state expected formats (masked vs raw CNPJ, numeric vs string unit code), so it only partially compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('consultar unidade orgao') and resource (public agencies/units) and gives the exact endpoint path /v1/orgaos/{cnpj}/unidades/{codigoUnidade}. This makes it clear it fetches one unit by CNPJ and unit code, and it is implicitly distinguishable from sibling pncp_obter_orgaos_unidades_por_cnpj (which lists units). It loses the fifth point because the wording is awkward and it never explicitly contrasts with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement of when to choose this tool over alternatives, nor any exclusions. The endpoint path implies the intended use (provide a CNPJ and a unit code), but the description does not say 'use this when you need a specific unit' or 'to list units, use pncp_obter_orgaos_unidades_por_cnpj'. This leaves usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does communicate that this is a public read/consult operation ('dados públicos', 'ação consultar'), which is useful. However, it does not disclose response format, filtering behavior, pagination, or other invocation-relevant traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and resource, then gives the exact endpoint path. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four optional parameters, no annotations, no output schema, and a large sibling set, this one-sentence description is not sufficient for confident autonomous invocation. It omits parameter semantics, usage differentiation, and any indication of what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description should compensate, but it does not explain the modalidadeId, amparoLegalId, or tipoInstrumentoConvocatorioId parameters. The resource nouns in the description loosely map to these IDs, but the agent gets no guidance on optionality, combinations, or how formato affects the response beyond the schema's own enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Consulta dados públicos de instrumentos convocatórios, modalidades e amparos legais' plus the exact API path. It identifies the combined subject matter well, though it does not explicitly differentiate itself from sibling list/getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as pncp_obter_instrumento_convocatorio_modalidade_amparo_legal_por_... or the simpler list tools for modalidades/amparos. The description merely states what it does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does convey that this is a public read-only consultation via 'Consulta dados públicos' and 'obter'. However, it does not mention response format, potential errors, authentication needs, or whether the result is normalized/original, which would be useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the purpose before giving the path. It is slightly repetitive because 'ação obter modalidade criterio julgamento' largely restates the verb and resource, but overall it is compact and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID endpoint, the description identifies the resource and path, which is a reasonable minimum. However, with no output schema and no annotations, it leaves gaps about what the returned data contains, how the two IDs relate, and how formato affects the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description should compensate for the undocumented modalidadeId and criterioJulgamentoId parameters. It does not explain their meaning or expected values, only echoing them in the URL path. The formato parameter is documented in the schema but not addressed in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Consulta dados públicos') and a specific resource ('modalidades e critérios de julgamento'), and gives the exact endpoint path with both ID placeholders. It is clear about what the tool operates on, though it does not explicitly distinguish itself from sibling tools like pncp_listar_modalidade_criterio_julgamento.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for retrieving a single specific pair by IDs, nor does it contrast with list endpoints or other get-by-id tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden of behavioral disclosure. It discloses that this is a public-data consultation and that it returns documents/files, but gives no detail on pagination behavior, file formats, whether documents are binary or metadata, or response shape. The schema shows pagination and formato parameters, but the description doesn't explain what they control beyond the schema's own text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, reasonably compact. It front-loads the broad resource list and ends with the path; the beginning phrase is a bit redundant with the path and could be tightened, but it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations mean the description must explain call semantics, pagination, and expected return. It explains only the basic endpoint and a vague resource list, leaving an agent unsure whether this returns raw file bytes, metadata, a download URL, or paginated JSON documents, and unclear on which of the many pagination parameters to prefer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description names the three required parameters (cnpj, ano, sequencial) by placing them in the path, and the path helps show they identify a contract. With only 25% schema description coverage, the description partially compensates but says nothing about page, pagina, pageSize, page_size, tamanhoPagina, tamanho_pagina, limite_resultados, or auto_paginar, many of which are self-evident only by name and not by schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (consultar) and resource (arquivos de contratos por CNPJ/ano/sequencial) and names the REST path. However, it is somewhat muddled by listing 'contratos públicos, empenhos, termos e arquivos' broadly before narrowing to files, which could confuse an agent briefly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it by naming the endpoint path and the resource kind, and many sibling tools follow the same pattern (arquivos vs quantidade vs sequencialdocumento). It never states explicit when-not-to-use conditions or names alternatives, so the agent must infer the distinction from the path and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention pagination behavior, the effect of the formato parameter, return structure, or any rate-limit/availability considerations. The tool has 13 parameters including aliases and auto-pagination flags, but the description gives no behavioral context beyond being a public data query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the purpose and the endpoint path. It is not excessively long, but the long technical path is front-loaded and may obscure the high-level purpose for an agent trying to select the tool quickly. It earns its place but could be structured more effectively with a cleaner summary followed by the endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, no annotations, and many closely related siblings, this description is insufficient. It does not explain pagination options, required identifier semantics, or how this endpoint differs from pncp_obter_orgaos_pca_itens_por_cnpj_ano_sequencial and similar tools. An agent would likely struggle to invoke it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 23%, with descriptions for formato, auto_paginar, and limite_resultados. The description adds limited value beyond the path, which partially explains the required parameters (cnpj, ano, sequencial, numeroContratacao) via their placement. It does not clarify the multiple size/page aliases or the semantics of sequencial vs numeroContratacao.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('consultar') and resource ('itens plano por contratacao') and includes the full endpoint path, which clearly indicates this tool retrieves items of a specific contracting process within an annual procurement plan. However, it does not explicitly differentiate itself from the many sibling tools with similar names such as pncp_obter_orgaos_pca_itens_por_cnpj_ano_sequencial, so some ambiguity remains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The endpoint path implies the tool is used when you have cnpj, ano, sequencial, and numeroContratacao to fetch contracting items. It does not explicitly state when to prefer this over the dozens of similar PCA/contract/contracting siblings, nor does it mention alternatives for consolidated data or other endpoint variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 this is a read/consult operation by starting with 'Consulta dados públicos', which conveys a non-destructive public-data lookup. However, it does not disclose response format, pagination, error behavior, or that the 'formato' parameter can toggle between normalized and original payload. It also does not clarify what 'tipoParteEnvolvida' values are valid, despite a sibling tool pncp_listar_tipos_parte_envolvida existing for that purpose. The behavioral disclosure is minimal beyond the read-only implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is front-loaded with a broad enumeration ('compras públicas, itens, resultados e arquivos;') that is not directly relevant to this specific endpoint and could mislead an agent into thinking this tool retrieves all of those resources. The most useful identifying information, the endpoint path, appears after the semicolon. The sentence could be shorter and more precise, e.g., 'Consulta uma parte envolvida de uma ata de compra pública', with the path as a reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a highly specific lookup tool with 8 parameters, no annotations, and no output schema. The description does not explain the relationship between the path parameters, what constitutes a parte envolvida, how to discover valid tipoParteEnvolvida values, or how the formato parameter changes the response. Given the large sibling list, the description is insufficiently complete: an agent would need to rely on the path template and parameter names alone, plus external domain knowledge of PNCP data semantics, to invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 every parameter with at least a short label. The description does not add meaning beyond the path structure, which does reveal relationships among parameters (e.g., cnpj belongs to the compra, cnpjOrgao/codUnidade/tipoParteEnvolvida identify the parte envolvida). The 'formato' parameter is mentioned in the schema with enum values and default, and the description says 'Consulta dados públicos' but does not explain the practical effect of normalizado vs original on the response. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (consultar parte envolvida ata) and the exact API path. However, it begins with a broad phrase listing many resources ('compras públicas, itens, resultados e arquivos'), which is generic and does not differentiate this tool from the many siblings. The route itself names the resource precisely, so an agent can infer that this fetches a specific involved party (parte envolvida) associated with a procurement ata. It lacks a plain-language statement of what is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this tool queries data about a specific parte envolvida ata via a detailed API path, which implies when it should be used: when the caller has all seven path identifiers (cnpj, anoCompra, sequencialCompra, sequencialAta, cnpjOrgao, codUnidade, tipoParteEnvolvida). It does not explicitly state when not to use it or mention alternatives, such as pncp_obter_orgaos_compras_atas_partesenvolvidas_por_cnpj_anocompra_sequencialcompra_sequencialata (which lists all partes envolvidas for an ata). The route is informative but the description does not tell the agent to prefer the list endpoint when the specific party identifiers are unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral load. It conveys a read operation ('Consulta') and public data ('dados públicos'), which is useful. However, it does not disclose response format, error behavior, pagination, or any rate/auth expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core action and public-data framing. The route string is long but informative, and there is no wasted filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is thin: it omits what the response contains, how to obtain idCompra, and how this differs from sibling legacy tools (list vs items). For a 2-param get-by-id it is minimally actionable but leaves important context unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents 'formato' with enum, default, and description, so no extra value is needed there. The description only loosely maps to the required idCompra via 'compra sem licitacao id' and does not explain the identifier's format or provenance; at 50% schema coverage, this is marginal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('consultar compra sem licitacao id') and the endpoint path, and 'Consulta dados públicos' identifies the resource domain. It is clear enough to distinguish from sibling list tools (e.g., compras_listar_modulo_legado_5_consultar_compras_sem_licitacao) because it targets a single ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided; it does not say 'for a specific compra sem licitação, use this; for listing all, use the sibling.' The only implied trigger is having an idCompra, inferred from the name/path, and given the large sibling family this lack of routing is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 tells the agent this is a read-like public data listing, but does not disclose pagination behavior, filtering semantics (statusAtivo), default output behavior (formato default), rate limits, or any response shape details. For a listing endpoint with no annotation support, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the action and resource, then references the API path. It is appropriately concise and free of filler, though it could have used the available space to add behavioral or parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is thin for a complete invocation: it does not explain the meaning of statusAtivo, what 'normalizado' vs 'original' changes, whether results are paginated, or how this list operation relates to pncp_obter_modos_disputas_por_id. The combination of a sparse description, low parameter coverage, and lack of output schema leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters descriptively (formato has a full description), but statusAtivo has only a key name with no description. The tool description itself adds no parameter-level semantics; it only mentions the path. With half the parameters undocumented, the description provides no compensation, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta' / list action) and resource ('dados públicos de modos de disputa'), and explicitly identifies the API path /v1/modos-disputas. It is clear that this lists dispute-mode records, though it doesn't explicitly distinguish it from the sibling pncp_obter_modos_disputas_por_id beyond the 'listar' naming pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a list/consultation use case for public data, which is adequate context. It provides no explicit when-to-use guidance or exclusions compared against the many sibling tools, particularly pncp_obter_modos_disputas_por_id which likely retrieves a single record. The phrase 'dados públicos' suggests no authentication context, but the usage context is otherwise left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description discloses the endpoint and that public data is queried, but it doesn't state whether this is a safe read-only operation, how the count is returned, whether there are limits or pagination, or what happens when no files exist. For a quantity endpoint, the return shape and count semantics (count of what exactly, e.g., files per ata) are important and left undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the general domain ('public purchase data') before specifying the exact endpoint. It is compact and earns its place, though the Portuguese phrasing is a bit dense and mixes the general scope with the specific path. No wasted words, but the structure could be clearer with a verb at the start.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should explain what a caller gets (a count?) and how to interpret it. The sibling list contains closely related endpoints (ata files with sequencialDocumento, ata list, ata quantity, purchase files quantity) that could easily confuse an agent, and this description does not disambiguate them. The five parameters are only implicitly explained through the URL path. This is adequate for a human API reference, but thin for an agent selecting among dozens of similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, with only the 'formato' parameter described in the schema. The description repeats the endpoint path which implicitly maps cnpj, anoCompra, sequencialCompra, and sequencialAta to path segments, adding some meaning to the four required parameters. However, it doesn't explain the semantics of 'sequencialAta' vs 'sequencialCompra' or 'sequencialDocumento' naming patterns, nor clarify that 'formato' is optional. The endpoint path provides moderate compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: it queries the quantity of public purchase document files (atas) and mentions the endpoint path. The tool name itself encodes the entire path (orgao/cnpj/compra/ata/arquivos/quantidade), so an agent can infer the scope. It doesn't explicitly name sibling tools to differentiate, but the resource and action are specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies a specific path and states what the action does, which implies when to use it (when needing the count of ata files). However, it doesn't explicitly say when not to use it or name alternatives such as the similar quantity tool for purchase files (pncp_obter_orgaos_compras_arquivos_quantidade_por_cnpj_ano_sequencial). No exclusions or decision guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the burden. It communicates that this is a public-data read operation and hints at the endpoint; however, it does not disclose return-value shape, whether the quantity is a single number or a list, pagination, or error conditions. Since 'public data' is stated, a read-only expectation can be inferred, but the description could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence and quickly tells the agent this is a public PCA data query with the endpoint. Front-loading the domain ('planos de contratações anuais') is helpful. However, the phrasing 'ação consultar dados pca itens quantidade itens' is a bit redundant and the endpoint repetition takes space that could have been used for usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a modest 20% parameter description coverage, the description is not complete enough for an agent to invoke this tool with confidence. It omits what the quantity response actually contains, whether 'categoria' filters the count, and how this differs from pncp_obter_orgaos_pca_itens_por_cnpj_ano_sequencial. The endpoint path indicates the URL shape but not the payload semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'formato' has an inline description). The tool description does not explain the meaning of required parameters cnpj, ano, sequencial or optional categoria, though the endpoint path and the Portuguese terms ('cnpj', 'ano', 'sequencial', 'itens', 'quantidade') make some meanings evident. The description adds the endpoint context but does not compensate for the missing parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Consulta dados públicos de planos de contratações anuais') and an explicit resource path ('/v1/orgaos/{cnpj}/pca/{ano}/{sequencial}/itens/quantidade'), which clearly indicates the operation is a read of item quantity data from an annual procurement plan. However, it does not explicitly distinguish this tool from its siblings like pncp_obter_orgaos_pca_itens_por_cnpj_ano_sequencial or pncp_obter_orgaos_pca_quantidade_por_cnpj_ano; the resource path is the main differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus the many closely named sibling tools, such as pncp_obter_orgaos_pca_itens_por_cnpj_ano_sequencial or pncp_obter_orgaos_pca_consolidado_por_cnpj_ano. There is no mention of exclusions or conditions like 'use this for counts only' or 'use the non-quantidade variant for full item details'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for behavioral disclosure. It only states that the tool 'consults public data' and 'lists records'; it does not describe response shape, pagination/limits, performance traits, whether the data is large, or any side effects. The term 'ação listar registros' is nearly a restatement of the operation, adding little behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core purpose, with the path appended as practical context. It is arguably terse, and the phrase 'ação listar registros no caminho ...' is somewhat mechanical, but it earns its place by specifying the resource and endpoint in one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should provide more context: response format, whether statusAtivo filters results, pagination, and how this list endpoint relates to the detail endpoint. The description leaves most agent-relevant operational details unspecified, so it is incomplete for a tool with two optional parameters and an undocumented one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: 'formato' is fully documented with enum and description, but 'statusAtivo' has no description beyond its boolean type. The description itself doesn't explain the parameters, so for 'statusAtivo' the agent gets no semantic guidance from either source. However, the presence of only two optional parameters and one clearly documented enum helps; the description does not actively mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Consulta dados públicos de critérios de julgamento') and a specific resource ('criterios de julgamento'), plus the API path '/v1/criterios-julgamentos'. It distinguishes list vs. detail siblings like pncp_obter_criterios_julgamentos_por_id, so the purpose is understandable, though it doesn't explicitly contrast with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the list/query operation for judgment criteria data, and the sibling set contains a single detail endpoint (pncp_obter_criterios_julgamentos_por_id), which gives context. However, it provides no explicit guidance on when to choose this tool over alternatives, no mention of pagination or filtering to reduce result sets, and no discussion of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Sem anotações, a descrição precisa assumir o peso da transparência; ela informa que se trata de consulta a dados públicos, o que sugere leitura sem efeitos colaterais. Porém, não detalha o formato da resposta, comportamento para IDs inexistentes, requisitos de autenticação além de 'público', nem o efeito do parâmetro formato.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A descrição é curta, direta e começa com o propósito principal, seguido do endpoint. Há uma redundância leve entre 'consulta' e 'obter registro', mas o texto é econômico e sem informações irrelevantes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para um GET simples com dois parâmetros, a descrição dá o recurso e o caminho, mas não cobre elementos úteis como quando preferir esta operação à listagem, o que retorna, ou a diferença prática entre os formatos normalizado e original. Como não há output schema, o agente fica sem saber o formato do retorno.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
O schema já documenta o parâmetro formato com enum, default e descrição, e a descrição acrescenta que o id é usado no caminho /v1/amparos-legais/{id}. Ainda assim, não explica o significado do id além do nome nem como o formato altera a resposta, então a cobertura semântica fica apenas parcial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição usa verbo e recurso específicos ('consulta dados públicos de amparos legais' / 'obter registro') e informa o caminho da API com {id}, deixando claro que se trata de uma busca por identificador. A diferenciação em relação à listagem fica implícita pelo uso de {id}, mas não nomeia diretamente o sibling pncp_listar_amparos_legais.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Não há orientação explícita sobre quando usar esta operação versus alternativas como pncp_listar_amparos_legais ou outros endpoints 'obter_por_id'. A descrição afirma que é uma consulta a dados públicos, mas não apresenta critérios de escolha, exclusões ou pré-requisitos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does state 'Consulta dados públicos', which signals a read-only operation over public data, and the endpoint path is transparent. However, it does not disclose the return shape, pagination behavior, or whether 'quantidade' returns a simple integer or an object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and includes the full endpoint path, which is information-dense. However, the opening clause is generic and partially redundant ('dados públicos ... compras públicas') and lists items, resultados, and arquivos that are not specific to this endpoint. It is acceptable but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, and the tool sits among many similar `historico` and `quantidade` siblings. The description gives the endpoint but not the response semantics, not the choice between this and the non-quantity history variant, and not enough parameter detail to compensate for the low schema coverage. It is enough to locate the endpoint but not enough to invoke it with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (20%), as four required parameters have no descriptions. The path in the description adds some meaning by showing parameter order and hierarchy (`cnpj`, `ano`, `sequencial`, `sequencialAta` under `/atas/`), and `formato` is already documented in the schema. But the description does not explain what `sequencial` or `sequencialAta` mean beyond their names, so it only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('consultar historico ata quantidade') and anchors it to the exact API path `/v1/orgaos/{cnpj}/compras/{ano}/{sequencial}/atas/{sequencialAta}/historico/quantidade`, so an agent can tell which resource is targeted. The opening clause is generic and could apply to many siblings, but the path and the word 'quantidade' sufficiently distinguish this tool from the similar history-endpoint variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no sibling alternative is named. The use case is implied: call this when you need the quantity of the historical record for an ata, as opposed to the full history returned by `pncp_obter_orgaos_compras_atas_historico_por_cnpj_ano_sequencial_sequencialata`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the operation is a read-only query ('Consulta') of public data, and it lists the data categories involved. However, it does not describe the response shape, whether the 'formato' parameter changes the payload structure, or behavior when a contract is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that includes the essential path template and the resource category. It is not bloated, though the phrase 'dados públicos de contratos públicos' is slightly redundant and the list of data types could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-record GET endpoint, the description gives the endpoint path and data categories, and the schema documents the optional 'formato' parameter. Yet with no output schema and no annotations, the description does not fully cover what the returned contract payload contains or how this tool differs from the many closely-related sibling endpoints, making it adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% since only 'formato' has a description. The description helps by embedding cnpj, ano, and sequencial in the path template, showing they are path parameters, but it does not explain what each one semantically represents beyond what is inferable from the tool name. This is partial compensation, not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Consulta dados públicos ... ação consultar contrato') and the explicit API path /v1/orgaos/{cnpj}/contratos/{ano}/{sequencial}, so an agent can identify what resource is being accessed. However, it does not explicitly distinguish this tool from the many sibling contract sub-resource tools, and the opening list 'empenhos, termos e arquivos' overlaps with sibling tool names, creating slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many related siblings such as pncp_obter_orgaos_contratos_empenhos_por_cnpj_ano_sequencial or pncp_obter_orgaos_contratos_termos_por_cnpj_ano_sequencial. The description provides no when-to-use, exclusions, or alternatives, so an agent is left to infer selection solely from the tool name and path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context; it does communicate that this is a read-only query over public data and that the result is a quantity of items. However, it does not say whether the response is a plain number, JSON object, or what the formato parameter changes about the payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact single sentence that includes both the domain and the concrete URL path. It could be restructured to lead with the exact quantity-counting action rather than the broader IRP context, but there is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple count endpoint, the description gives enough to infer the call: required identifiers are present in the path and the action is clear. But with no output schema and no annotations, it omits response shape, authentication expectations, and the practical effect of normalizado versus original.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%; only formato has a schema description. The endpoint path in the description gives cnpj, ano, and sequencial contextual meaning as identifiers of the órgão/IRP, but it does not define their expected values or formats beyond that context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action — consulting the quantity of IRP items for a given órgão, year, and sequence — and gives the exact API path, which disambiguates it from the sibling item-listing endpoints. It does not explicitly name a sibling or contrast itself, so it stops just short of the highest rating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this endpoint over the closely related pncp_obter_orgaos_irp_itens_por_cnpj_ano_sequencial or other quantity endpoints. The text only restates the action; it does not state what distinguishes this query or when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure. It does reveal that the data is public, the action is a listing, and the output is CSV via the stated path. It does not, however, state whether the response is a raw CSV download, how pagination works, or any file/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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that includes the endpoint path and main scope, with no filler. The phrasing 'ação listar planos todas unidades do orgao csv no caminho' is a bit awkward, but it is short and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a public CSV listing endpoint, the description plus the schema is usable, but there is no output schema and no annotations, so the description should clarify the CSV delivery format, what columns/records are returned, and what 'todas unidades' represents. It is adequate for basic invocation but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (just formato), so the description must compensate for cnpj and ano. The endpoint path partially does this by showing cnpj as the órgão identifier and ano as the year in the URL. It still does not give CNPJ formatting/masking, year bounds, or clarify how formato changes the CSV payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete operation: listar planos de contratações anuais for all units of an órgão as CSV, with the exact endpoint path including {cnpj} and {ano}. It is clear enough to distinguish from the consolidated, JSON, and quantity PCA siblings, although it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when/when-not guidance or reference to any alternative tool, despite a very large sibling set with similar PCA endpoints. The only signal is the phrase 'csv' in the path and tool name, which implies CSV use but does not explain when this tool should be preferred over pncp_obter_orgaos_pca_consolidado_por_cnpj_ano or related variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It does communicate that the data is public and that the operation is a read/consult of a single record. However, it does not disclose error behavior, response shape, or how the id should be obtained, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: it leads with the purpose and then identifies the endpoint. It is slightly awkwardly phrased but contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter GET operation, the description plus input schema is mostly workable. However, there is no output schema, and the description does not clarify what the returned record contains, what a valid id looks like, or how the 'original' vs 'normalized' formats affect the response. These gaps make it minimally adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'formato' has a useful schema description, but 'id' is only typed as an integer with no semantic explanation. The description's path '/v1/portes-empresa/{id}' reinforces that id is a path parameter, but it does not explain what the id represents or how to obtain valid IDs, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Consulta dados públicos de portes de empresa') and resource ('obter registro no caminho /v1/portes-empresa/{id}'). It is unambiguous about retrieving a single company-size record by ID, though it does not explicitly contrast with sibling tools like pncp_listar_portes_empresa.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied: the endpoint path and the 'por_id' name suggest this is for fetching one specific record, while a list sibling would be used for enumerating records. The description does not explicitly state when to choose this tool over alternatives or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the disclosure burden. It does convey that the data is public and that the operation is a read-style 'obter registro', which implies a safe lookup. However, it does not mention error behavior, return shape, or any handling of the 'normalizado' vs 'original' response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loads the domain ('Consulta dados públicos') before giving the endpoint pattern. It is reasonably tight, though the phrase 'ação obter registro' is slightly redundant with the tool name and could have been trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-key read endpoint, the path and action are enough for basic invocation, and the schema covers the optional format parameter. But with no output schema and no annotations, the description could usefully explain what the returned record contains and how the response format option changes the payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and while the description maps the two ID parameters into the URL path, it adds no semantic meaning beyond their self-explanatory property names. The 'formato' parameter is already covered by the schema's enum and description, so the description provides only marginal parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('obter registro', i.e., get record) and identifies the resource path with both ID parameters, so an agent can tell this is a single-record lookup for a tipo-instrumento-convocatorio-modo-disputa. It is clear, though it does not explicitly distinguish this from the sibling list endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives such as pncp_listar_tipo_instrumento_convocatorio_modo_disputa or the individual 'por_id' lookups. The description only restates the endpoint behavior without adding selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does convey that this is a read-only consultation of public data, which is useful. However, it does not mention response behavior, possible errors, authentication needs, or any limitations beyond the endpoint path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose and includes the endpoint path. Minor redundancy exists in 'ação consultar tipo parte envolvida', but it does not harm usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup-by-id tool, the description is adequate: it names the public scope, the action, and the endpoint. However, it lacks an explicit statement of what the response represents, how the optional 'formato' affects output, and how this differs from the list sibling, which would make agent selection more reliable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'formato' with enum values and a default, but does not explain 'id'. The description partially compensates by embedding 'id' in the path, making clear that it identifies the 'tipo parte envolvida'. Still, the description adds no detail about the format parameter or the source/nature of the id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Consulta dados públicos de tipos de parte envolvida') and identifies the specific resource and path with an {id} placeholder, making the tool's purpose evident. It does not explicitly contrast with the sibling list tool, but the '/{id}' path and 'por_id' naming provide enough distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as pncp_listar_tipos_parte_envolvida. The intended use is only implied by the name and path, and no exclusion or prerequisite conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does disclose that the operation is a public-data consultation and a list action, which implies a read-only, no-auth call. It does not state pagination, response shape, or rate limits, so some behavioral details remain unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence: it states the public-data nature, the action, and the exact API path without filler. Every part contributes to selecting and invoking the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter list endpoint, the core operation and path are present, but with no output schema the description does not explain the response format or pagination, and it gives no sibling-routing context. It is minimally adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage: 'formato' has an enum and default, and 'statusAtivo' is described as a boolean filter. The description adds no parameter-level meaning, but the baseline of 3 applies because the schema handles the parameters fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('listar'/'list records'), a clear resource ('tipos de documentos'), and the API path, so an agent knows what the tool does. It stops short of 5 because it does not explicitly contrast with siblings like pncp_obter_tipos_documentos_por_id; the distinction is inferable but not stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance or mention of alternatives. The description never says 'use this to list all document types' or 'use the get-by-id tool for a specific type,' and there are no exclusions or prerequisites. Usage must be inferred from the tool name and the verb 'listar.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It does disclose that the operation queries 'dados públicos' (public data), implying a safe read requiring no special access. However, it does not describe the response shape, how the 'formato' choice changes the payload, or any error behavior, leaving notable gaps for a tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence front-loads the core purpose ('Consulta dados públicos de categorias...') before providing the endpoint. There is no redundant or filler content, and it is appropriately sized for a simple two-parameter lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with two params and no output schema, the description covers the essential purpose and endpoint. It is incomplete in that it offers no differentiation from the list sibling, no hint of the response format, and no elaboration on the impacto of the 'formato' parameter beyond a schema already covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the 'formato' parameter is already described in the schema, and the description adds nothing about it. The 'id' parameter, undocumented in the schema, is given implicit meaning by the endpoint path '/{id}' and the tool name. The description adds marginal value but does not compensate for the undocumented required parameter beyond what the path already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Consulta') and identifies the precise resource ('categorias de itens de planos de contratações anuais') plus the exact endpoint path (/v1/categoriaItemPcas/{id}). The by-id single-record nature is clear from both the path and the phrase 'obter registro', distinguishing it from the list sibling pncp_listar_categoria_item_pcas, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives such as pncp_listar_categoria_item_pcas (the list variant) or the many other pncp_obter_*_por_id tools. The agent must infer from the name and path that this is for fetching a single record by id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose the key trait: this is a public-data read operation ('Consulta dados públicos'). That is meaningful context. However, it adds nothing about response shape, error behavior, or the difference between the 'normalizado' and 'original' response formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the purpose and appends the exact endpoint. Every element earns its place with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id endpoint the essentials are present: what it fetches, the endpoint, and both parameters are covered between description and schema. But there is no output schema and no description of the returned record, no guidance on choosing between 'normalizado' and 'original', and no pointer to the list sibling for ID discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: the `formato` parameter is well documented in the schema with enum values and a default, while `id` has no schema description. The description partially compensates by showing the path template /v1/fontes-orcamentarias/{id}, which clarifies that `id` identifies the budget-source record, but it does not explain where such IDs come from or their constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta'/'obter registro') and resource ('fontes orçamentárias'), and pins the operation to a concrete endpoint (/v1/fontes-orcamentarias/{id}). It clearly indicates a single-record fetch by ID, which distinguishes it from the listing sibling `pncp_listar_fontes_orcamentarias`, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives. The 'por id' pattern implies the agent should call it when it already has a budget-source ID, and that `pncp_listar_fontes_orcamentarias` is the alternative for browsing, but this is left entirely to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and does establish the read-only, public-data nature of the call ('Consulta dados públicos'), which is useful safety context. However, it discloses nothing about pagination defaults (page and pagina both default to 1), response shape, or rate limiting, leaving those to be inferred from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that opens with the verb and resource. The second clause ('ação consultar entes por filtro') is somewhat redundant with the first, but it earns partial value by supplying the concrete endpoint path /v1/orgaos/.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filtered-listing tool the core is present, but with no output schema the description should at least hint at the response, and it never clarifies the puzzling duplication of the page and pagina pagination parameters. The well-described schema compensates for some, but not all, of the missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented, including razaoSocial's minimum length and the formato enum. The description adds only a generic 'por filtro' notion that maps loosely to razaoSocial, keeping this at the baseline 3 for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (consulta) targeting public data of agencies and public units (órgãos e unidades públicas), with filtering ('por filtro') at the /v1/orgaos/ path. The word 'filtro' signals this is the filtered search operation, distinguishing it from exact-lookup siblings like pncp_obter_orgaos_por_cnpj and pncp_obter_orgaos_id_por_orgaoid, though those alternatives are not named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: 'ação consultar entes por filtro' tells the agent this is the filter-based query over agencies, versus ID/CNPJ-based retrieval siblings. There is no explicit when-to-use, when-not-to-use, or named alternative, which matters given the very large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 data is public ('dados públicos'), which signals a read-only operation with likely no auth requirement. It also identifies the exact API path, which helps the agent understand the request target. However, it doesn't disclose response format, pagination behavior, or whether the list can be filtered, which would be useful for a listing endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('Consulta dados públicos de tipos de parte envolvida') and follows with the endpoint path. It is concise, under 30 words, and contains no filler. It could be slightly improved by separating the path reference more grammatically, but it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only one optional parameter and no output schema, the description is mostly adequate: it states the resource, the public nature, and the endpoint. The main gap is not explaining the relationship with the sibling 'pncp_obter_tipos_parte_envolvida_por_id' nor describing what the returned list contains (e.g., ID and name fields). Since the tool is trivial (no required params), this is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%: the 'formato' parameter has a full description ('Formato da resposta: normalizado ou payload original') and an enum with both options. The description doesn't add extra parameter semantics beyond the schema, but the schema is already self-sufficient. The baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta dados públicos'), a resource ('tipos de parte envolvida'), and the API path ('/v1/tipos-parte-envolvida'). It clearly indicates this is a read/list operation for public data. While it doesn't explicitly differentiate from the sibling 'pncp_obter_tipos_parte_envolvida_por_id', the 'listar' vs 'obter_por_id' naming convention and mention of the list endpoint provide reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is for querying public data of 'tipos de parte envolvida' in a list endpoint, which implies a directory/list use case. However, it doesn't explicitly state when to use this versus 'pncp_obter_tipos_parte_envolvida_por_id' (e.g., when you need all types vs a specific type by ID), nor does it mention any exclusions or alternatives. The use case is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the operation is a public-data read and that it retrieves a single record, which is reasonably transparent. However, it does not mention response format, error behavior, or whether authentication is required, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the resource and the exact action in one sentence with no filler. It communicates the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple public get-by-id endpoint, the description is minimally viable: it states the resource and path. But it lacks usage guidance, parameter explanation, and any sense of the expected return payload, so an agent would likely need to inspect the schema or sibling names to be fully confident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 50% of the schema properties have descriptions, and the tool description adds no parameter-level meaning. The 'id' parameter is left to inference, though the endpoint hint partially compensates. The 'formato' parameter is already described in the schema, so the description contributes no extra value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the operation ('Consulta dados públicos de critérios de julgamento') and identifies the exact resource path with an id placeholder. This distinguishes it from list-style siblings like pncp_listar_criterios_julgamentos and other lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the many sibling tools. The endpoint path implies a get-by-id operation, but the description does not mention alternatives, exclusions, or contexts where this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. 'Consulta' and 'dados públicos' signal a read-only public lookup, which is useful, but the description does not mention response format, error behavior, or other operational traits beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and embeds the full endpoint path, which is valuable for invocation. The opening phrase listing 'termos e arquivos' adds ambiguity and could be trimmed, but overall the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The path template plus input schema gives enough to attempt a call, but with no output schema or annotations, the agent is left to infer what the response contains and when to prefer this endpoint over the related list-empenhos tool. More explicit return-value and selection context would be needed for a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), so the description's URL template adds real value by showing that cnpj, ano, sequencial, and sequencialEmpenho are path segments. Still, it leaves 'sequencial' undefined and does not clarify where the optional 'formato' parameter is applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action — consultar empenho — and gives the exact endpoint path, which makes the resource and scope reasonably clear. However, the opening phrase lists 'contratos, empenhos, termos e arquivos' broadly, which muddies the focus and prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the path includes {sequencialEmpenho}, so the agent can infer this is for retrieving one specific empenho by its sequential number. There is no explicit guidance on when to use this instead of the sibling list endpoint pncp_obter_orgaos_contratos_empenhos_por_cnpj_ano_sequencial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys that this is a read-only query of public data ('Consulta dados públicos') and that it returns a count. However, it does not disclose the response shape, error behavior, or how the 'formato' parameter affects the payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and includes the useful endpoint path, but the opening clause is repetitive ('públicos... públicos', 'contratos... termo contrato') and the sentence is run-on. The specific purpose appears after a broad, slightly misleading preamble rather than being front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should clarify what the response contains and how to distinguish this count endpoint from related file/term endpoints. It only paraphrases the path and leaves return format, 'formato' behavior, and sibling selection to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description partially compensates by embedding the parameter hierarchy in the path: cnpj identifies the órgão, ano the contract year, sequencial the contract, and sequencialTermo the specific term. This adds relational meaning beyond the bare schema property names. Still, it does not describe valid formats or domain constraints for cnpj/ano.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: consulting the quantity of term-contract documents, and gives the exact endpoint path. The word 'quantidade' and the path suffix '/arquivos/quantidade' clearly distinguish it from the sibling endpoint that returns the actual files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus related siblings, such as the endpoint that returns the actual term files or the endpoint that counts terms themselves. The agent must infer usage solely from the tool name and path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It does convey that the operation is a public-data consult, implying read-only behavior. It does not, however, describe the response shape, error behavior, or any access considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that includes the key action and the full API path. The lead phrase is somewhat redundant and broader than the actual action, but the format is still efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple identifier-based lookup, the path plus schema provides enough for a basic invocation. However, with no annotations, no output schema, and no sibling differentiation, the agent is left to infer return values and which related endpoint is appropriate for listing all terms or fetching term files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description must add meaning. It does help by embedding the four required parameters in the URL path, clarifying that `cnpj` identifies the órgão and `sequencialTermoContrato` identifies the specific term. But it does not explain the parameters in prose and does not mention `formato`, so the compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the verb ('consultar') and the exact resource via the API path, including the specific term identifier `sequencialTermoContrato`. This helps distinguish it from sibling endpoints that list contract terms. However, the opening phrase 'dados públicos de contratos públicos, empenhos, termos e arquivos' is overly broad and does not explicitly name or contrast with a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The path structure implies this tool should be used to fetch a single contract term when `cnpj`, `ano`, `sequencial`, and `sequencialTermoContrato` are known. There is no explicit statement about when to use it versus the sibling term-listing endpoint `pncp_obter_orgaos_contratos_termos_por_cnpj_ano_sequencial` or related file/document variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It does convey that this is a read-only lookup of public data ('Consulta dados públicos'), which is helpful. It does not describe response characteristics, error behavior, or potential rate limits, leaving some behavioral details implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource. The phrase 'ação consultar ente no caminho' is slightly awkward and redundant, but overall there is no excessive padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter lookup with no output schema, the description plus schema gives a workable but thin picture. An agent learns the endpoint and parameters, but the response shape, whether units are included, and how to distinguish this tool from many related sibling tools remain largely implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'formato' with its enum, default, and description, but leaves 'orgaoId' undocumented. The description adds some meaning by showing that 'orgaoId' is the path parameter in /v1/orgaos/id/{orgaoId}, but it does not add detail about the expected value semantics or the meaning of 'formato' beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Consulta') and resource ('dados públicos de órgãos e unidades públicas'), and identifies the exact endpoint path /v1/orgaos/id/{orgaoId}. It is not a tautology, though it does not explicitly contrast itself with sibling CNPJ-based or listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The endpoint path and tool name imply this should be used when an orgaoId is available. However, the description gives no explicit guidance about when to prefer this over pncp_obter_orgaos_por_cnpj or pncp_listar_orgaos, and provides no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, but it only says 'dados públicos' and 'obter registro.' It does not explicitly state that this is a safe read-only operation, nor any response format, authorization, or rate-limit behavior, and it adds little beyond what the action and route already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that leads with the operation and the resource and includes the concrete endpoint path. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter GET, the combination of description and schema gives enough to invoke the tool: required id, optional formato with enum/default, and public-data context. But with no output schema and no annotation safety profile, it would benefit from an explicit statement of when to use this over the list sibling and what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: id has no schema description, and the description does not explain what the id represents beyond placing it in the URL path. The 'formato' parameter is documented in the schema, so the description adds no meaningful semantics for either parameter and fails to compensate for the undocumented id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Consulta dados públicos' / 'obter registro') and a resource ('tipos de instrumentos de cobrança'), and the explicit route path /v1/tipos-instrumentos-cobranca/{id} makes clear this is the by-id retrieval variant. This distinguishes it from the list sibling pncp_listar_tipos_instrumentos_cobranca.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: call when you have an id and need a single collection-instrument type record, as signaled by 'obter registro no caminho .../{id}' and the '_por_id' name. However, it never explicitly contrasts with pncp_listar_tipos_instrumentos_cobranca or other alternatives, so the guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It discloses what the tool returns (sources, domains, coverage, version) but does not explicitly state that the operation is read-only, free of side effects, or safe to call anytime. The empty schema with additionalProperties:false structurally prevents side effects, which mitigates the gap, but the safety profile is only implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single eight-word sentence that is front-loaded with the verb and enumerates the returned content compactly. Every word earns its place; there is no filler or redundancy with the title (which is null) or the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, output-schema-backed metadata tool, the description is largely complete: the four returned categories are named, and an output schema exists so return structure need not be explained. It could add one sentence framing this as the discovery entry point for understanding the server's data sources, but nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so per the rubric the baseline is 4. There is nothing for the description to clarify about parameters, and it sensibly does not invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retorna fontes, domínios, cobertura e versão do catálogo MCP' states a specific verb (Retorna) and a well-defined resource (the MCP catalog), naming the four content categories returned. It is clearly distinct from the ~170 sibling tools, which all query specific procurement data rather than catalog metadata, but it does not explicitly differentiate itself from any sibling by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no mention of alternatives. The intended use is only implied by the tool's nature as a zero-parameter capability/metadata listing tool; the description never states 'call this to discover which data sources are available before querying' or anything equivalent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds a meaningful behavioral fact by saying the data is 'públicos' and using 'Consulta', which implies a safe read-only operation on public data with no auth or privacy concerns. However, it does not disclose pagination behavior, result volume, or response shape, which matters for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, and the endpoint path earns its place by making the operation concrete. There is only minor redundancy between 'Consulta' and 'ação listar', which is acceptable given that the second clause adds the path.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with zero required parameters and no output schema, the description states the purpose and endpoint adequately. But it leaves the semantically opaque 'statusAtivo' parameter unaddressed and gives no indication of what a normalizado versus original payload looks like, so an agent still has gaps before invoking it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is exactly 50%: 'formato' has an enum and description, but 'statusAtivo' is an unexplained boolean. The tool description adds nothing about either parameter. An agent cannot determine what statusAtivo filters (presumably active contract types) from either the schema or the description, and the description 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Consulta dados públicos de tipos de contratos') and grounds it in the concrete API path '/v1/tipos-contratos' with the 'ação listar registros' action. This lets an agent distinguish it from the sibling 'pncp_obter_tipos_contratos_por_id': this one lists the collection, that one fetches a single record by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied through the word 'listar' and the collection path; no explicit guidance is given about when to choose this tool over the get-by-id sibling or when not to use it. The description never names an alternative or an exclusion condition, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does disclose that the operation is a public-data query, which implies read-only and no auth requirement. It does not mention response format, error behavior, or rate limits, but for a simple public GET this is partially transparent rather than misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the purpose and immediately supplies the endpoint path. There is no filler or redundant information; every part contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter GET endpoint, the description and schema are probably enough to invoke the tool correctly. Still, there is no output schema, no guidance on alternatives, and no note about what the returned catalog record contains, so the contextual picture is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to 'id' by embedding it in the endpoint path, clarifying that it identifies the catalog record. The optional 'formato' parameter is already well described in the schema with an enum and default value. Schema coverage is only 50%, but the path context partially compensates for the lack of an 'id' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('consulta'), the resource ('dados públicos de catálogos de itens'), and the scope ('obter registro no caminho /v1/catalogos/{id}'), which indicates a single-record retrieval by ID. It does not explicitly name a sibling like pncp_listar_catalogos, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a single catalog record is needed by ID, especially through the '/v1/catalogos/{id}' path. However, it gives no explicit when-to-use/when-not-to-use guidance and does not mention any alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Não há annotations, então a descrição carrega o peso de explicar o comportamento. Ela informa que se trata de uma consulta de quantidade, ou seja, uma operação de leitura, e que não retorna os registros em si. Porém, não detalha o formato exato da resposta, o comportamento em caso de dados inexistentes, nem eventuais requisitos de autenticação ou limites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A descrição tem uma frase única, direta e sem redundância. O verbo e o recurso aparecem no início, e a menção ao caminho é compacta e informativa.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para uma ferramenta sem annotations e sem output schema, a descrição é funcional mas enxuta: explica o propósito e o caminho, mas não cobre o formato da resposta, possíveis erros ou a relação com o endpoint de histórico completo. O schema cobre o formato, mas o contexto geral ainda tem lacunas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
O schema só descreve o parâmetro formato (25% de cobertura), mas a descrição agrega significado ao mostrar o caminho /v1/orgaos/{cnpj}/contratos/{ano}/{sequencial}/historico/quantidade, indicando que cnpj, ano e sequencial identificam o órgão e o contrato. Ainda assim, não informa formatos aceitos para CNPJ, nem como obter ou validar o ano e o sequencial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição usa verbo específico ('consulta') e recurso bem definido ('quantidade de registros do histórico do contrato'), além de mostrar o caminho exato da API. Isso a diferencia claramente do sibling pncp_obter_orgaos_contratos_historico_por_cnpj_ano_sequencial, que retornaria os registros e não a quantidade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Não há orientação sobre quando usar esta ferramenta em vez das alternativas, como o endpoint de histórico completo ou outros endpoints de contratos. O agente precisa inferir pelo nome e pelos siblings que esta é a versão de contagem, mas a descrição não deixa isso explícito.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose that the data is 'dados públicos' (public data), which hints that this is a safe read operation without special permissions. However, it does not describe the response format, whether pagination might apply (unlikely for a get-by-id), or what happens when the id does not exist. The 'consulta/obter' phrasing implies read-only intent, but little else is revealed beyond what the purpose statement already covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence: it leads with the purpose ('Consulta dados públicos de tipos de contratos'), then specifies the action and path. There is zero fluff, no repetition of the tool name, and every word carries meaning. The path is front-loaded as a concrete detail that anchors the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple get-by-id operation, so the description need not be extensive. It successfully conveys the resource, action, and path, and the schema covers the two parameters adequately. However, there is no output schema, and the description does not state what the returned record contains or how to obtain the id (e.g., from a list call). For an agent deciding whether this tool fits a given task, the lack of return-value context is a notable gap, though not fatal given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: 'formato' has a description, while 'id' does not. The tool description only reflects the path with {id}, which adds little beyond the schema's required parameter. It confirms id is the record identifier but does not explain its provenance, syntax, or domain meaning. The 'formato' parameter is already adequately described in the schema, and the description does not add further semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the resource ('tipos de contratos'), the action ('obter registro'), and the exact path with id placeholder ('/v1/tipos-contratos/{id}'). This clearly identifies it as a get-by-id operation and distinguishes it from sibling tools like pncp_listar_tipos_contratos, which would list all records. An agent can tell immediately what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool instead of its siblings. It does not mention that it is intended for retrieving a single record when an id is available, nor that pncp_listar_tipos_contratos should be used when listing is needed. The path with {id} implies the id requirement, but the description does not state the decision rule or mention the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does disclose a key behavioral trait — this is a read-only query against public data ('Consulta dados públicos'), which is genuinely useful for the agent. However, it says nothing about return shape, error behavior for unknown ids, or what the 'normalizado' vs 'original' formato variants mean behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose ('Consulta dados públicos de tipos de documentos') and immediately follows with the endpoint detail. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter public read endpoint with no output schema, the description covers the essentials: what it retrieves, the public nature of the data, and the exact path. The notable gap is routing — an agent is not told to use pncp_listar_tipos_documentos to obtain a valid id, and the return value is not characterized. Adequate for the tool's simplicity, but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; the formato parameter is already fully described by its schema enum and description, so no compensation is needed there. The description adds the path context /v1/tipos-documentos/{id}, clarifying that id is the URL path identifier — this is meaning beyond the bare 'integer' schema. But it doesn't say where valid ids come from or what id values are expected, so compensation for the undocumented id is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consulta' — queries) and a specific resource ('tipos de documentos' — document types), and it specifies the action is 'obter registro' at the path /v1/tipos-documentos/{id}. The {id} path segment clearly differentiates this from the list sibling pncp_listar_tipos_documentos, though the description never names that alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The path with {id} and the 'obter registro' phrasing imply this tool is for fetching a single document type when an id is already known, but the description gives no explicit when-to-use guidance. It does not state that pncp_listar_tipos_documentos should be used to discover ids first or that this tool should be skipped when no id is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose that this is a public read operation ('Consulta dados públicos'), which is useful safety-relevant context. However, it does not mention behavior on invalid/non-existent ids, response contents, authentication requirements, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the resource, verb, and exact path. It contains no filler, no repetition of schema details, and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple public reference lookup and the schema documents both parameters, so invocation is feasible. Still, with no output schema and no annotations, the description omits response-shape expectations and fails to mention the list alternative, leaving the context minimal but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'formato' with its own description, and the description adds that 'id' is a URL path placeholder in '/v1/.../{id}'. However, it does not explain what the id represents beyond the resource name, and with 50% schema coverage it only partially compensates for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Consulta'), names the resource ('tipos de instrumentos convocatórios'), and gives the exact path '/v1/tipos-instrumentos-convocatorios/{id}', clearly identifying this as a get-by-id lookup. This distinguishes it from the sibling list tool pncp_listar_tipos_instrumentos_convocatorios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus the list sibling or other related endpoints. The only implied context is that an id is needed, but there is no when/when-not or alternative routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It does disclose that the tool reads public data (read-only implication of 'public data') and specifies the endpoint path, which is helpful. However, it does not mention pagination behavior, response format details, date-range semantics, or any limitations beyond the schema. With no annotation support, the disclosure is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that conveys the tool's purpose, data standard, action, and endpoint path. It is front-loaded with the verb and resource, contains no filler, and is appropriately sized for the complexity of the tool. This is concise without losing critical routing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, 3 required, and no output schema, so the description must give enough context for correct invocation. It names the required filtering dimensions (buyerID and release date range) implicitly through the endpoint purpose, but it does not explain pagination usage, the meaning of the 'normalizado' vs 'original' response formats, or how results are returned. The description is complete enough for a basic call but lacks guidance for advanced options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, leaving page, offSet, pagina, and releaseEndDate without explicit descriptions beyond the schema types. The description does not elaborate on the parameter meanings, but the schema itself documents most parameters with defaults and descriptions for key options like formato and auto_paginar. The description adds little beyond the schema, but because the schema covers a majority of parameters with useful semantics, the shortfall is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Consulta dados públicos'), a specific resource (contracting data in OCDS format) and the action (listar releases at a specific endpoint path). While it does not compare against siblings, the mention of the OCDS standard and the exact path '/modulo-ocds/1_releases' distinguishes it from the many PNCP and ARP sibling tools. It loses a point because it doesn't explicitly differentiate from related OCDS/consultation endpoints among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for querying public OCDS releases, which gives some usage context. However, it provides no explicit guidance on when to choose this tool over sibling tools that also consult contracts, ARP, or PNCP data, nor does it state any exclusions or alternatives. The context is clear enough for a generic data-query task but not specific about when this endpoint is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Consulta dados públicos' and 'ação listar registros' signal a read-only, public operation, which is useful. However, it does not disclose response format, pagination behavior, or how statusAtivo affects results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the resource, action, and endpoint path. Every element adds value, with no redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter list endpoint, the description covers the core purpose and path, but it omits response shape, statusAtivo filtering behavior, and pagination expectations. With no output schema and no annotations, these gaps leave the agent with partial information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% and the description adds no parameter-level meaning whatsoever. It does not explain 'formato' or 'statusAtivo', leaving statusAtivo undocumented in both description and schema. The description 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Consulta', 'listar'), a resource ('categorias de itens de planos de contratações anuais'), and the API path ('/v1/categoriaItemPcas'). This clearly distinguishes it from the sibling pncp_obter_categoria_item_pcas_por_id, which is an 'obter por id' operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the list endpoint for category items, but it does not explicitly say when to use it versus pncp_obter_categoria_item_pcas_por_id, nor does it mention when to apply the optional statusAtivo filter. Usage context is clear only by inference from the 'listar' action and endpoint path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds useful traits ('públicos' and 'leves' suggesting public, low-impact probes), but it does not disclose failure behavior, rate limits, or whether the probes are read-only beyond the implicit meaning of 'probe'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the action and outcome with no filler words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description covers the basic action and result. However, it does not explain what 'cataloged probes' or 'sources' refer to in concrete terms, nor when an agent should invoke this tool, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter documentation burden. The baseline for 0-param tools is 4, and the description does not need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('executa probes') and states the resource and output ('informa a saúde de cada fonte'). It is clearly distinct from the sibling data-query tools, though it does not specify which sources/fontes are covered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: run when you need to check source health. However, it gives no explicit when-to-use guidance, no exclusions, and no alternatives, leaving the agent to infer when this tool should be preferred over the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

MCP Compras Públicas Brasil MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![MCP Compras Públicas Brasil MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/LeonardoDiasRR/compras-publicas-br/badges/card.svg)](https://glama.ai/mcp/servers/LeonardoDiasRR/compras-publicas-br)

Score Badge

Copy to your README.md:

[![MCP Compras Públicas Brasil MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/LeonardoDiasRR/compras-publicas-br/badges/score.svg)](https://glama.ai/mcp/servers/LeonardoDiasRR/compras-publicas-br)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![MCP Compras Públicas Brasil MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FLeonardoDiasRR%2Fcompras-publicas-br%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/LeonardoDiasRR/compras-publicas-br)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LeonardoDiasRR/compras-publicas-br'

If you have feedback or need assistance with the MCP directory API, please join our Discord server