Resumo curto do edital (IA)

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

Annotations declare readOnlyHint=false and idempotentHint=false but give no reason; the description supplies it — this is a credit-billing tool, not a mutation. It adds concrete behavior an agent could not infer: the BITBUSCA_API_KEY requirement, that the first call is free and returns cost/balance/already-paid status, and that only the confirmed call charges.

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

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

Three sentences, front-loaded: prerequisite and capability first, then the cost/confirmation workflow. Every clause carries information — the API-key note, the output fields, the free-then-charged flow. Slight density of nested clauses keeps it from a 5.

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

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

There is no output schema, so the description carries the return-value burden and does so: it names the summary fields, the per-item source attribution, the credit cost, the balance, and the already-paid flag. Combined with the disclosed key prerequisite and billing model, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds procedural meaning to 'confirmar' that the schema only states statically: the two-phase call pattern and the requirement to surface the cost to the user before the true call. The 'id' parameter's provenance is already in the schema, so no extra credit there.

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

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

The description states a specific verb and resource ('Resume o edital') and enumerates the output contents (objeto, valor, prazo, exigências principais) plus per-item sourcing, so an agent knows exactly what it gets back. It does not, however, differentiate itself from sibling tools like ler_edital or analisar_edital, which presumably also read the same edital.

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

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

It gives explicit procedural guidance: always call first without confirming, show cost to the user, and only repeat with confirmar: true after the user says yes. That is clear when/how-to-call guidance. The gap is that it never states when to prefer this over the sibling reading tools (ler_edital, analisar_edital) — there are no exclusions or alternatives named.

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