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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description need only add contextual behavior. It adds useful detail such as aggregate coverage over several portals, return of a page with IDs and dates, and optional readable edital fields when edital_legivel is true. There is no contradiction with the annotations.

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

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

The description is compact and front-loaded: it first defines what is searched, then describes return values and follow-up tools, and finally relates the tool to pncp_listar. Every sentence contributes meaningful information without repetition or fluff.

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

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

For a 20-filter search tool with no output schema, the description gives valuable output context: one page of results, IDs, opening/closing dates, and optional edital fields for downstream reading. Still, it does not fully describe the outcome shape, pagination behavior, or the exact semantics of several filters, so completeness is adequate but not strong.

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

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

Schema description coverage is 0%, so the description must compensate for 20 parameters. It explains major filters like keyword, value range, UFs, modalidades, portais, participation exclusiva, and superoportunidades. However, it leaves gaps around parameters such as itens_desertos, somente_sigilosos, pesquisa_ampla, expandir, tipo_periodo, and date semantics.

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

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

The description opens with a specific verb and resource ('Busca de OPORTUNIDADES de licitação') and clearly defines the scope: editais/pregões with rich filters and aggregate portal coverage. It also distinguishes itself from pncp_listar by noting it is the same source but with more qualification filters.

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

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

The description provides practical routing guidance: same source as pncp_listar but with more filters, use pncp_processo for full opportunity detail, and use pncp_texto/pncp_arquivos to read the edital. It lacks explicit when-not-to-use advice or exclusions for other search siblings like pncp_buscar, but the guidance is clear enough for most agents.

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