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

Annotations already flag readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the agent knows this is a non-idempotent, potentially billable operation. The description adds genuinely new context: the billing is in credits, the first call is free and returns cost plus balance, and a paid call already made is reported as such. It does not cover failure behavior (e.g. insufficient credits, analysis latency), which is the remaining gap.

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 compact sentences: the access prerequisite is bracketed up front, then the concrete deliverables, then the mandatory call protocol front-loaded with 'SEMPRE'. The page-citation clause and the cost/balance clause both earn their place. Slightly dense with parentheticals, but no filler.

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

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

There is no output schema, yet the description enumerates both the analysis payload (summary, checklist, deadlines, risks, next steps, each with source page/trecho) and the preview payload (cost in credits, balance, whether already paid). Combined with the auth prerequisite and the confirm-to-charge protocol, an agent has everything needed to call this correctly for a two-parameter tool.

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

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

Schema coverage is 100% and the schema already explains that 'confirmar' controls free preview versus charged execution, including the instruction to show cost first. The description nonetheless reinforces the two-phase semantics at the tool level and ties 'id' to its source field indirectly through the workflow, adding modest value on top of a fully documented schema.

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 gives a specific verb and resource ('Lê o edital') and enumerates the concrete outputs produced: resumo, checklist de documentos, prazos, riscos, and next steps, each with page/trecho provenance. That is far more specific than a title restatement. It does not, however, differentiate itself from close siblings such as resumo_edital or ler_edital, which is the only thing keeping it from a 5.

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

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

It gives an explicit call protocol: always call first without 'confirmar' to obtain a free cost estimate, show the cost to the user, and only repeat with 'confirmar: true' after the user says yes. It also states the BITBUSCA_API_KEY prerequisite. What is missing is guidance on when to choose this over resumo_edital or ler_edital, so the sibling routing is left implicit.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new operational context: the tool requires an API key and belongs to an "avançado" tier, and it discloses that results yield an id consumed by other tools. Pagination/cursor behavior is left to 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.

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

A single tight sentence with the key prerequisite front-loaded in brackets and the downstream hand-off at the end. Nothing is redundant, though the bracketed prefix is slightly compressed to the point of terseness.

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 an 8-parameter, all-optional search tool with no output schema, the description covers source scope, auth requirement and the returned id. The remaining gap is the absence of any differentiation from the sibling editais_abertos, which an agent would need in order to choose 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 every parameter is already documented in the schema. "filtros de valor e prazo" loosely points at valorMin/valorMax and encerraAte but adds no syntax or semantics beyond what the schema supplies; baseline 3 applies.

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

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

States a concrete verb and resource ("Busca editais abertos") plus the sources it queries (PNCP e outros portais) and its filter dimensions (valor, prazo). It does not, however, distinguish itself from the sibling tool editais_abertos, so an agent must guess which listing tool to pick.

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?

"Avançado: exige BITBUSCA_API_KEY" gives a prerequisite, and naming ler_edital/analisar_edital as consumers of the returned id signals the follow-on workflow. There is no explicit statement of when to prefer this over editais_abertos or when it should not be used, so usage is only implied.

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

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

Annotations already declare readOnly=true, idempotent=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds two pieces of context beyond that: the API-key entitlement gate and the content boundary '(sem sócios)', which tells the agent partner data is not returned. It omits result shape and 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.

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

Two compact clauses: the entitlement warning is bracketed and front-loaded so it is seen before anything else, followed by a single sentence covering verb, data source and filters. No filler and nothing repeated from the schema.

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

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

With nine optional parameters, no required fields, idempotent/read-only annotations and a fully described schema, the definition covers invocation well. The gap is that there is no output schema, yet the description says nothing about the row shape returned or that paging is capped at page 20 with 25 rows by default, so the agent cannot anticipate the result envelope.

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

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

Schema description coverage is 100%: all nine parameters, including page, pageSize, somenteAtivas and aberturaDias, are documented in the schema itself. The description only names the filter families and adds no syntax detail (e.g. multiple CNAEs comma-separated, município accepting name or IBGE code), so it sits at the baseline for high-coverage schemas.

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 gives a concrete verb ('Lista') and a concrete resource ('empresas da base de CNPJ'), then enumerates the filter dimensions (UF, município, bairro, CNAE, porte, data de abertura). The parenthetical '(sem sócios)' implicitly separates it from the single-company lookup sibling consultar_cnpj, but it never names that sibling, so differentiation is inferential rather than explicit.

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 states a real precondition ('Avançado: exige BITBUSCA_API_KEY'), which tells the agent when the call will fail, and the filter list implies a bulk/segment search use case. However, it never says when to prefer this over consultar_cnpj for a single company or buscar_editais_bitbusca for procurement notices, leaving the routing decision to inference.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds a real operational constraint in the auth requirement and identifies the data source as the municipal cadastro. It omits what a no-match result looks like, which keeps it from a 5.

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

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

A single sentence with the auth tag front-loaded in brackets and the exclusion clause trailing. Nothing is redundant and the most operationally important fact (requires a key) comes first.

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 three-parameter read tool with no output schema, the auth requirement, source registry, accepted input types and the CPF exclusion cover what an agent needs to call it correctly. Result-shape and pagination behavior are the only gaps, and the limite parameter plus readOnly annotations partially compensate.

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 all three parameters including the cidade slug hint and limite are already documented. The description's phrase "por endereço ou inscrição" restates the termo parameter rather than adding syntax or format guidance, so baseline 3 applies.

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

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

States a concrete verb ("Acha") and resource ("o lote/imóvel no cadastro municipal") plus the accepted key types (endereço ou inscrição), which lets an agent distinguish it from consultar_cnpj or ficha_imovel. It stops short of 5 because it never names the sibling it defers to for the excluded case.

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

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

Gives an operational precondition (requires BITBUSCA_API_KEY, flagged as advanced) and one negative scope ("não busca por CPF"), which is useful routing information. It does not state when to prefer it over ficha_imovel or what to do when the key is missing, so usage is implied rather than spelled out.

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

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

Annotations already declare readOnly/idempotent/openWorld and non-destructive, so the safety profile is covered; the description adds genuinely new context by flagging the BITBUSCA_API_KEY prerequisite and the 2021 coverage boundary. It does not mention pagination behavior or the 50-item cap beyond what the schema states, so it stops short of a 5.

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

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

Two sentences, front-loaded with the paid/API-key tag and then the search scope, with the chaining advice compressed into one efficient clause. The parenthetical for calcular_prazo is dense but every element carries routing information.

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

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

For a 10-parameter, no-required-parameter search tool with no output schema, the description covers purpose, prerequisites and downstream chaining well. The notable gap is that it never says whether at least one filter is needed or what an empty call returns, leaving an agent to guess about a zero-argument invocation.

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

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

Schema description coverage is 100%, so the schema already documents formats for de/ate, oab, processo, cursor and limite; the description only restates the filter axes. The one addition is clarifying that 'data' is the disponibilização field used downstream by calcular_prazo, which is marginal value over the schema.

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

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

States a specific verb and resource ('Busca intimações e publicações do DJEN') with scope ('desde 2021') and enumerates the five search axes (OAB, processo, parte, advogado, palavras) that map to its parameters. An agent can distinguish it from siblings like buscar_editais_bitbusca or ficha_processo 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.

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

Explicitly routes the agent onward: ler_publicacao(id, data) for full text, ficha_processo(numero) for movements, and calcular_prazo for the deadline, including which field ('data', data de disponibilização) to feed into the deadline tool. This is a concrete when-to-use-this-vs-alternatives chain, not implied guidance.

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

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

Annotations already mark it as read-only, idempotent, non-destructive, and local (openWorldHint false); the description goes further by explaining that computation is local, that each skipped day is reported with its source, that the DJEN date is the disponibilização, and that unsupported tribunals trigger a warning plus national-holiday fallback. That is real behavioral context beyond 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?

Purpose is front-loaded and every clause carries information; the colon list of covered regimes is efficient. The single dense sentence could be split for readability, but there is no filler.

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

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

For an 11-parameter, domain-heavy tool with no output schema, the description explains what is computed, what the result reports ('passo a passo', each skipped day with its source), and how coverage gaps behave. Only the shape of the returned step-by-step output and error/warning format remain under-specified.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds interpretive meaning by tying 'dias' to the pre-doubling value, explaining the 10-day ciência ficta window, the 20/12–20/01 recess and suspension, and the tribunal/comarca holiday sources. It stops short of clarifying every parameter (e.g., how 'consulta' interacts with the 10 days), so not a 5.

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

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

States a specific verb+resource: computes the due date of a procedural deadline, and enumerates exactly what regimes it handles (CPC business days, CLT, calendar days, DJEN publication, electronic intimation with 10-day fictitious notice, double deadlines, recess 20/12–20/01, court and municipal holidays). It is clearly distinguishable from simple counters like contar_dias_uteis or somar_dias_uteis.

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 usage context (procedural deadline in a specific court/comarca) is implied by the mentioned regimes, and it does warn that full calendars exist only for tribunals in tribunais_cobertos, falling back to national holidays otherwise. However, no sibling tool is named as an alternative, so an agent must infer when to prefer this over contar_dias_uteis or prazos_da_lei.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds context the annotations cannot: the call requires BITBUSCA_API_KEY and coverage is partial rather than nationwide, which prevents the agent from treating an empty result as proof no listings exist. It does not describe the shape of each returned city entry beyond the slug field.

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

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

Two tight sentences: prerequisite first, then purpose and coverage caveat, then the actionable routing instruction. Nothing is padded and the most decision-relevant facts lead.

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

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

For a zero-parameter reference lookup with no output schema, the description supplies the prerequisite, the coverage limitation and the key return field. Minor gaps remain (whether entries also carry name/state/UF, or rough result size), but an agent can call this correctly and use the result without further information.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing to disambiguate on input. The description does useful extra work by naming the output field ('slug') that downstream tools expect, compensating for the absent output schema.

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

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

States a specific verb and resource ('Lista as cidades com cadastro imobiliário disponível') and immediately scopes it with 'cobertura parcial do país', so an agent knows this is a discovery/lookup of covered cities, not a search of listings. It distinguishes itself from buscar_imovel and ficha_imovel by positioning itself as the source of the city slug those tools consume.

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

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

Explicitly routes the agent: take the 'slug' field and pass it as the city argument in buscar_imovel and ficha_imovel, which is exactly the when/how-to-use guidance needed for a reference-data tool. It also flags the advanced API-key prerequisite. It stops short of saying 'call this first when the city is unknown', but the routing is clear enough to infer.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds value by disclosing the specific payload the agent will receive (feature explanation, price, and key-acquisition steps), which is behavior beyond what the annotations state. It does not mention response format or that the answer is static documentation, a minor remaining gap.

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

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

A single, front-loaded sentence that lists the three content areas in a natural order (what it does, cost, how to get the key). No filler, no repetition of the title, nothing that could be cut.

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

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

For a zero-parameter, read-only informational tool with no output schema, the description supplies enough to know both the content and the safe nature of the call. The only thing missing is a hint that the return is explanatory text/documentation rather than structured data, which would help an agent set expectations about the response.

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

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

The tool takes zero parameters and the input schema correctly declares an empty object, so there is nothing for the description to disambiguate. Baseline of 4 applies for a parameterless tool, and the description does not waste words restating the empty schema.

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 gives a concrete verb ("Explica") and enumerates exactly what content is covered: what advanced mode does, its cost, and how to get the free BitBusca key. This clearly marks it as an informational/how-to tool, distinguishing it from functional siblings like buscar_editais_bitbusca or meu_saldo, though it never names those siblings explicitly.

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

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

Usage is implied: an agent can infer this is the tool to call when a user asks about advanced mode, pricing, or a free key. However, there is no explicit when-to-use statement, no exclusion of alternatives, and no signal about what to do if the user asks about something adjacent (e.g., account balance, which maps to meu_saldo).

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely non-obvious operational context: the service is free, subject to a daily quota per connection, and the quota disappears when BITBUSCA_API_KEY is supplied. It does not say what happens for an invalid or unfound CEP, but the added quota/auth detail is valuable.

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

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

Two short sentences with no filler; the field list and the quota caveat are both load-bearing. The opening noun-phrase fragment rather than a verb clause slightly weakens front-loading.

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

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

With no output schema, the description usefully enumerates the returned fields and discloses the quota/key behavior, which is enough to call the tool correctly. It omits error/not-found behavior, which is the main remaining gap for a lookup tool.

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

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

Schema description coverage is 100% and the single parameter already documents its format (com ou sem hífen). The description adds no syntax, normalization, or error-handling meaning beyond the schema, so the baseline applies.

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

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

The description enumerates the returned resource fields (logradouro, bairro, cidade, UF, IBGE, DDD, coordinates), which makes the resource identifiable, but it never states a verb or that it looks up/retrieves by CEP. It also does nothing to distinguish it from siblings such as consultar_cnpj or cidades_imovel beyond the implicit input type.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives (e.g., using cidades_imovel for the reverse direction). The only contextual clause is about quota, which is behavioral rather than usage routing.

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

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

Annotations already declare read-only, idempotent, non-destructive and open-world, so safety is covered. The description adds genuinely non-obvious behavior: a free daily quota per connection versus a 1-credit cost when BITBUSCA_API_KEY is supplied, and a precise inventory of what data is and is not returned. It does not say what happens when the quota is exhausted, which keeps it below 5.

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

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

Two dense sentences with zero filler: the first front-loads what data comes back and what does not, the second front-loads the cost model. Nothing is repeated from the schema or annotations.

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 single-parameter lookup with no output schema, the description fully compensates by listing the returned fields, the exclusions, and the pricing/quota behavior. An agent has everything needed to decide whether to call it and what to expect back.

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?

With one parameter at 100% schema description coverage ('CNPJ com ou sem pontuação, aceita o alfanumérico'), the schema already carries the semantics. The description adds no extra format, normalization, or validation detail beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource (consulta do cadastro público do CNPJ na Receita Federal) and enumerates exactly which fields come back: razão social, nome fantasia, situação, abertura, natureza jurídica, porte, CNAE principal, endereço, Simples/MEI. The explicit exclusions ('Sem sócios e sem contatos') plus the '(básico)' framing let an agent distinguish this from richer company tools like buscar_empresas without opening either schema.

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

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

The 'Sem sócios e sem contatos' clause effectively tells the agent when NOT to use this tool, and the key/quota clause explains the two operating modes. It stops short of naming the alternative sibling to use when partner or contact data is needed, so routing is implied rather than explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low; the description still adds real context beyond them. It discloses the boundary convention (start excluded, end included), that non-counted days are returned with reasons, and that the computation is local ('Cálculo local'), implying no network call and deterministic results.

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

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

Three short sentences, front-loaded with the core question and the counting convention, then calendar scope, then output shape, then the local-computation note. Every clause carries information an agent would otherwise have to guess.

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

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

With no output schema, the description usefully sketches the return ('Lista os dias que não contaram e por quê'), and it defers tribunal validation to tribunais_cobertos, which is the right move. It is nearly complete for a six-parameter read-only calculator, missing only explicit interaction rules between 'tribunal', 'materia' and 'comarca'.

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 83% and both enums ('materia', 'calendario') are documented in the schema, so the baseline is 3. The description restates the calendar-mode defaults already present in the schema and adds nothing new about 'de'/'ate' formats, 'comarca' holiday lookup, or how 'materia' interacts with 'tribunal'.

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

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

States a specific verb and resource ('Quantos dias úteis há entre duas datas') and pins the counting convention (excludes start date, includes end date), which is the main ambiguity for this kind of tool. It does not distinguish itself from siblings like somar_uteis/feriados/calcular_prazo by name, so an agent must still infer which of the date-math tools to pick.

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?

Implied guidance only: the 'calendario' clause explains that 'forense' is the default when a tribunal is given and 'nacional' when it is not, which nudges selection, and it points to tribunais_cobertos for valid siglas. There is no explicit when-to-use-this-instead-of-somar_dias_uteis or calcular_prazo statement and no stated exclusions.

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

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

Annotations already declare read-only, idempotent, non-destructive and open-world, so the safety profile is covered. The description still adds real context beyond them: the data source (official Banco Central indices), the exact month-boundary convention inherited from the Calculadora do Cidadão, and the explicit exclusion of juros and multa from the result.

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

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

Three short sentences, each carrying distinct information: what it does, which convention it follows, and what it deliberately excludes. The operative verb leads and there is no filler.

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

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

For a read-only calculation with a fully documented four-parameter schema, the definition covers purpose, convention and scope limits adequately. With no output schema present, it would help to say what comes back (corrected value, index applied, factor), which is the only remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns the extra point by explaining what the date parameters actually mean in combination ('do mês inicial até o mês anterior ao final'), a convention the schema does not convey. It also restates the index choices and the ipca default, which the schema already provides.

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

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

Names a specific verb (corrige) and resource (valor entre duas datas) and enumerates the supported indices, so the operation is unmistakable. It does not differentiate itself from the sibling indice_economico, which is the nearest plausible alternative, so it stops short of a 5.

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

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

Usage context is implied rather than stated: 'Correção simples, sem juros nem multa' signals the tool is wrong when interest or penalties apply, and the Calculadora do Cidadão convention scopes the date handling. There is no explicit when-to-use versus indice_economico or calcular_prazo, and no prerequisites are listed.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the write/non-idempotent nature is covered. The description adds two things beyond that: the API key requirement and the fact that delivery is push-based via webhook on every new publication, which tells the agent this is a persistent, recurring side effect. It omits where the webhook target comes from, since no webhook parameter exists in 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.

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

Two compact segments: the prerequisite first, then a single sentence naming the resource and its trigger. Nothing is redundant and the most decision-relevant constraint (advanced/API key) is front-loaded.

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 state-creating tool with no output schema, the description never says what comes back (a monitor identifier, status) or how an existing monitor is inspected or removed. Combined with the unexplained webhook destination, an agent can invoke it correctly but cannot reason about the full lifecycle of the object it creates.

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

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

Schema description coverage is 100%, with 'alvo', 'tipo' (enum) and 'rotulo' each documented in the schema, so the baseline of 3 applies. The description only restates the target domain ('OAB, parte ou processo'), adding no syntax or defaulting detail beyond what the schema already says about deducing 'tipo' from 'alvo'.

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?

Specific verb plus resource ('Cria um monitor') and a clear scope ('publicação nova de uma OAB, parte ou processo' no DJEN). An agent understands exactly what is created and what it observes. It does not explicitly contrast with the search sibling (buscar_publicacoes_djen), 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.

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

The bracketed '[Avançado: exige BITBUSCA_API_KEY]' flags a prerequisite and points at the activation path (como_ativar_avancado), which is real guidance. However, it never states when to prefer this over a one-off search of publications, nor when not to use it (e.g. duplicates, monitoring already exists). Usage is implied rather than prescribed.

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

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely new context: the data comes from the public PNCP API and only covers notices with open proposals, and it advertises the returned fields (órgão, valor estimado, prazo, link), which matters because no output schema exists.

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

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

Two sentences, both front-loaded: the first states the resource and filters, the second states the returned fields. No filler or repetition.

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

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

With full schema coverage, complete annotations, and no output schema, the description is nearly self-sufficient, covering source, scope, filters, and return contents. The only gaps are pagination/rate behavior on the API side and any pointer to the sibling tool when a different notices source is wanted.

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

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

Schema description coverage is 100% and every parameter, including both enums and the pagination bounds, is documented inline. The description merely restates the same filter dimensions, adding no syntax, defaults, or inter-parameter behavior beyond what the schema already provides, so the baseline 3 applies.

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

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

The description names a specific resource and scope: open-for-proposal licitações from the PNCP public API, with the filter dimensions listed. An agent can grasp what it does immediately, but it never distinguishes itself from the sibling editais search tool (buscar_editais_bitbusca), so the source-based differentiation is only implicit.

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

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

Usage is implied by the filter list (keyword, UF, município, modalidade, deadline), which tells the agent how to narrow results, but there is no explicit when-to-use statement, no when-not, and no mention of the alternative editais search tool. The agent must infer that this is the PNCP source as opposed to BitBusca.

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

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

As annotations já declaram readOnly, idempotent, non-destructive e openWorld=false; a descrição agrega valor ao informar que o cálculo é local e que o resultado inclui a lei de cada feriado, portarias, recesso e pontos facultativos. Ainda assim, não há output schema e a descrição não descreve o formato de retorno nem a granularidade dos itens do calendário forense.

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?

São três frases curtas e densas, com a distinção de escopo front-loaded antes dos detalhes do calendário forense. Não há enchimento, embora a expressão "(e comarca)" entre parênteses deixe a combinação de parâmetros um pouco ambígua à primeira leitura.

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?

Com 5 parâmetros todos opcionais e sem output schema, a descrição cobre o suficiente para o agente escolher o modo correto e entender o conteúdo retornado. Faltam apenas detalhes sobre formato de retorno e sobre quais tribunais são cobertos, deixados para o schema e para tribunais_cobertos.

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?

A cobertura de schema é 100%, então o schema já explica ano, comarca, matéria e calendario, inclusive os padrões (nacional sem tribunal, forense com tribunal). A descrição reforça a relação tribunal/comarca, mas não acrescenta sintaxe, formatos ou restrições além do que o schema fornece; baseline 3 é adequado.

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

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

A descrição nomeia o recurso (feriados do ano) e divide explicitamente o escopo em dois modos: sem tribunal (feriados nacionais de lei, com a lei de cada um) e com tribunal/comarca (calendário forense com portarias, feriados municipais, recesso, pontos facultativos e suspensão de prazos). Isso permite distinguir os dois comportamentos internos do tool, embora não o diferencie dos irmãos que também lidam com prazos e dias úteis (contar_dias_uteis, calcular_prazo).

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?

A descrição dá orientação condicional clara: "Sem tribunal" produz feriados nacionais, "Com tribunal (e comarca)" produz o calendário forense completo. Não nomeia alternativas nem diz quando preferir calcular_prazo ou contar_dias_uteis em vez deste tool, o que impede nota máxima.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds two things annotations cannot convey: an authentication requirement (BITBUSCA_API_KEY) and a data-minimization constraint (no phone, e-mail or address), which prevents the agent from promising contact details.

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

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

One compact sentence plus a bracketed prerequisite; the auth requirement is front-loaded and the returned fields are listed inline. No wasted words.

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

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

With no output schema, the description compensates by listing the returned fields, and with a single required parameter at full schema coverage the invocation contract is fully specified. The only dependency, the API key, is stated up front.

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

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

Schema description coverage is 100% and the single 'oab' parameter already documents the 'UF + número' format with an example 'MS12345'. The description only restates that lookup is by OAB, adding no syntax or validation detail beyond the schema.

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

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

The description names a specific verb+resource ('Mostra a ficha pública do advogado pela OAB') and enumerates exactly what is returned (nome, inscrição, situação, cidade/UF). It is unmistakable against siblings like ficha_processo, which cover a different entity.

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 bracketed prerequisite '[Avançado: exige BITBUSCA_API_KEY]' tells the agent it needs a paid/advanced key, and 'sem telefone, e-mail nem endereço' implicitly warns against using it for contact data. But there is no explicit when-to-use/when-not guidance or named alternative for related lookups.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real context beyond that: an authentication/plan requirement (API key), the fact that valor venal is only present 'quando houver' (partial results), and an explicit privacy boundary excluding owner data.

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

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

A single sentence plus a bracketed prerequisite tag, with the access requirement front-loaded and the returned fields and exclusion clause packed in without waste. Nothing could be removed without losing information.

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

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

For a two-parameter read-only lookup with no output schema, the description covers what the tool returns and what it deliberately omits, plus the access gate. Minor gap: no mention of behavior when the property is not found in the municipal cadastro or how the two parameters interact (e.g., city slug must match a cidades_imovel entry).

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

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

Schema description coverage is 100%, so both parameters are already documented, including the note that 'valor' comes from buscar_imovel. The description adds no syntax, format, or validation detail for cidade/valor beyond what the schema provides, which is the expected baseline-3 case.

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

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

States a specific verb and resource ('Mostra a ficha do imóvel no cadastro municipal') and enumerates the returned fields (área, uso, valor venal). It also delimits scope with 'sem dados do proprietário', though it never names the sibling buscar_imovel as the natural predecessor — that link only appears in the schema's parameter description.

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 bracketed 'Avançado: exige BITBUSCA_API_KEY' is a useful gating prerequisite, but the description gives no explicit when-to-use or when-not-to-use guidance relative to buscar_imovel or cidades_imovel. The workflow (search first, then fetch the ficha) is only implied by the schema, not stated here.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral information: it requires a BITBUSCA_API_KEY, and it discloses which sections are returned. It stops short of saying whether "últimos movimentos" is truncated or how failures (invalid CNJ, missing key) surface.

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

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

One sentence, front-loaded with the operational prerequisite before the functional description. Nothing is repeated and nothing is wasted.

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

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

For a read-only, single-parameter tool with no output schema, the definition covers the credential requirement and the shape of the returned data. Minor gaps remain around error behavior and the pointer to como_ativar_avancado for obtaining the key.

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

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

Schema coverage is 100% and the single parameter is documented as "Número CNJ do processo (20 dígitos)". The description's "de um processo" adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

"Mostra capa e movimentações de um processo" names a specific verb and resource and even enumerates the returned sections (classe, assuntos, órgão, últimos movimentos), so the agent knows exactly what it gets. It does not explicitly contrast with the similarly named ficha_advogado / ficha_imovel, but the target resource (a court case) is unambiguous.

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 bracketed prerequisite "Avançado: exige BITBUSCA_API_KEY" tells the agent a credential is required, which is real usage context. However, there is no statement of when to prefer this over siblings such as buscar_editais_bitbusca or como_ativar_avancado when the key is missing; usage must be inferred from the resource name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that: the data source is a live public SGS API and monthly indices also carry accumulated period and 12-month figures. It does not mention caching, rate limits, or what happens when the requested month range predates the series.

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

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

Two sentences, front-loaded with source and output content, followed by a compact index glossary. The enum list partially duplicates the schema's enum, but appending unit and cadence information makes it earn its space; minor redundancy only.

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

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

With no output schema, the description does its part by stating that results include the period accumulated total and 12-month accumulation for monthly indices, and by giving units per index. It still leaves the concrete response shape (field names, time series framing) and error behavior for a date range that exceeds the series unspecified.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns extra credit by explaining what each enum value actually measures and in which unit (e.g. selic_mensal is accumulated monthly % vs selic which is daily %), and by flagging which indices are monthly versus daily, which governs the de/ate and ultimos parameters.

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

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

The description names the resource (official Banco Central index values via the public SGS API) and enumerates every available index with its unit of measure, so an agent knows exactly what data comes back. It does not distinguish itself from the nearest functional sibling (corrigir_valor, which also deals with index-based correction), leaving that differentiation implicit.

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

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

There is no explicit guidance on when to call this tool versus corrigir_valor or any other sibling, nor any stated preconditions or exclusions. An agent can infer 'use this to fetch raw index values' from the index list, but the description never says so or routes to alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the one thing annotations cannot: this call requires an advanced plan/API key (BITBUSCA_API_KEY), which is a real gating precondition an agent must check before invoking. It does not describe behavior for an unknown or expired id.

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

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

Two short clauses with the prerequisite bracketed up front and the returned content immediately after – no filler. Density is high, though the extreme brevity leaves the gaps noted in the other dimensions.

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 one-parameter read tool this largely suffices, and because there is no output schema the enumeration of returned fields (itens, documentos, datas, órgão) is a useful stand-in. Still missing: whether the id comes only from buscar_editais_bitbusca, and what happens on a missing/blocked id, which matters because the tool is gated behind an API key.

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

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

Schema description coverage is 100% and the single 'id' parameter already documents its provenance ('campo id de buscar_editais_bitbusca') and length limits. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource (show detail of one edital) and enumerates what the payload contains: itens, documentos, datas and órgão. It is clearly a detail-fetch by id, distinct from the search tool named in the schema, though it never names its closest siblings (resumo_edital, analisar_edital) to sharpen the boundary.

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

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

Usage is only implied: the 'Avançado: exige BITBUSCA_API_KEY' tag plus the schema note pointing at buscar_editais_bitbusca suggests 'search first, then fetch detail with the returned id'. There is no explicit when-to-use or when-not-to-use versus resumo_edital or analisar_edital, which an agent would need to choose correctly in this crowded sibling set.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the bar is lower, but the description still adds meaningful behavior: the API-key/advanced-tier requirement and the fact that the response includes parties and lawyers, not just raw text. It does not mention output size, rate limits, or how pagination behaves, which would have earned a 5.

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

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

A single sentence with the access prerequisite bracketed and front-loaded, followed immediately by what the tool returns. No filler, no restatement of the title.

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 three-parameter read tool with no output schema, the description covers the essential facts: what is returned (full text plus parties/lawyers), the auth requirement, and implicitly the retrieval pattern. A note that long texts are paginated via the parte parameter would close the remaining gap.

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

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

Schema description coverage is 100%, and the schema already explains id, data and the pagination-oriented parte parameter thoroughly. The description adds nothing parameter-specific beyond implying the id comes from a search, so baseline 3 is appropriate.

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

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

The description names a specific verb ("Traz o texto completo") and a specific resource ("uma publicação do DJEN"), plus the payload contents (partes e advogados). It implicitly contrasts with the search sibling buscar_publicacoes_djen, but never names it outright, so the differentiation is inferred rather than stated.

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 discloses a real prerequisite ("exige BITBUSCA_API_KEY") and, via the schema, that an id from a prior search is needed, which tells an agent when the tool is callable. However, there is no explicit when-to-use or when-not-to-use guidance and no named alternative (e.g. buscar_publicacoes_djen for listings vs. this for full text).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely new context beyond that: the call requires a BITBUSCA_API_KEY and belongs to the 'Avançado' tier, which an agent needs to know before invoking it.

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

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

A single well-formed sentence with the prerequisite front-loaded in brackets, so the constraint is seen before the purpose. No wasted wording, though brevity means some context is left implicit.

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

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

For a simple, no-parameter read tool whose annotations fully cover the safety profile and whose schema is empty, the description supplies everything essential: purpose, auth requirement, and tier. The absence of an output schema is minor since the description enumerates what is returned (plan, balance, limits).

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool applies. Nothing in the description misrepresents the input surface.

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

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

States a specific verb ('Mostra') and three concrete resources: plan, credit balance, and key limits. It is easily distinguished from the sibling tools, which are all document/legal lookups, though it doesn't name an alternative explicitly.

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

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

The bracketed '[Avançado: exige BITBUSCA_API_KEY]' gives a useful prerequisite (advanced tier, API key needed) that implicitly tells the agent when this tool is callable. However, there is no explicit when-to-use/when-not guidance or pointer to a sibling such as como_ativar_avancado for key setup.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine value by disclosing the coverage scope (CPC, CLT, Juizados) and the shape of the answer (days, counting rule, legal basis). It does not mention result limits, empty-result behavior, or how counting varies by branch, so it is useful but not rich.

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

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

Two sentences, front-loaded with the action and scope, followed by concrete query examples. The four examples are slightly long but they directly serve query formulation for a term-matching tool, so little is wasted.

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

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

With no output schema, the description usefully summarizes the return content (dias, forma de contagem, base legal) and the doctrinal coverage (CPC, CLT, Juizados), which is what an agent needs to trust the answer. Minor gaps remain around result limits and what happens when a termo is not found, but nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including both enums (quem, ramo) and the limite bounds. The description contributes only extra sample values for termo and says nothing about how ramo or quem constrain results beyond what the schema states, so baseline 3 applies.

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

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

States a specific verb ("Procura no catálogo") and a specific resource ("prazos processuais") and lists exactly what comes back: day count, counting method, and legal basis. The word "catálogo" plus the term examples implicitly separate it from calcular_prazo, but the description never names that sibling, so the differentiation is inferred rather than stated.

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 example terms ("contestação", "apelação", "embargos de declaração", "recurso ordinário") show how to phrase a query, which is real usage help. However, there is no explicit guidance on when to pick this over calcular_prazo (apply a deadline to a case) or contar_dias_uteis (count days), leaving the routing decision to inference.

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

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

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.

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

Annotations already cover readOnly/idempotent/openWorld, so the bar is lower, but the description still adds real context: an authentication requirement (API key), the data basis and rule framework for the score, and that the response includes the reasons behind the score. It does not mention rate limits or failure modes, keeping it below a 5.

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

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

One front-loaded sentence with the access prerequisite first and the output content last; no wasted language. The nested parenthetical is slightly dense but still readable.

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

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

For a single-parameter, read-only tool with no output schema, the description covers what is computed, on what data basis, what is returned (score plus reasons), and the access requirement. Only the fallback path when the API key is absent is left unaddressed.

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

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

Schema description coverage is 100% and the single cnpj parameter is already documented as the buyer agency's CNPJ from the edital. The description adds no format, masking, or validation detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: gives a 0-100 score for the public contracting agency (órgão público). It also names the score's basis (fiscal health and payment history) and that reasons are returned, so an agent can tell it apart from the plain lookup sibling consultar_cnpj. It stops short of explicitly saying how it differs from that sibling.

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

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

The description flags the prerequisite '[Avançado: exige BITBUSCA_API_KEY]', which is genuinely useful for deciding whether the tool is callable. However, it gives no explicit when-to-use versus consultar_cnpj or buscar_empresas, and does not tell the agent what to do if the key is missing (e.g., the como_ativar_avancado sibling).

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

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

Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds meaningful behavioral context by specifying that the initial day is not counted, negative N moves backward, and different calendars apply.

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

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

The description is three tight sentences with the core calculation rule front-loaded, followed by use cases and the key alternative. There is no filler.

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

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

For a six-parameter date calculation tool with full schema coverage and no output schema, it covers the counting convention, calendar domain, use cases, and main alternative. It does not explicitly state the return value format, which leaves a minor gap for invocation clarity.

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

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

Schema coverage is 100%, so the baseline is 3. The description still adds important meaning not fully captured in the schema by emphasizing the exclusion of the initial day and reinforcing negative N and the calendar choice.

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 operation: return the date that falls N business days after or before a given date, excluding the starting day, under forensic, national, or banking calendars. It also distinguishes itself from the sibling calcular_prazo for procedural deadlines arising from intimation.

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 use cases (internal office deadlines and bidding deadlines) and explicitly redirects procedural deadline calculations from intimation to calcular_prazo. The alternative is named with the condition that selects it.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuine behavioral context beyond that: it discloses the coverage boundary and the fallback semantics (national holidays only, with a warning) that govern downstream calculations — information an agent cannot get from 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?

Two sentences, front-loaded with the positive case (covered courts) followed by the negative/fallback case, with no filler. The phrasing 'anos conferidos' is slightly compressed and could be more explicit about what a 'verified year' means, but nothing is wasted.

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

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

For a zero-parameter read-only listing tool with no output schema, the description supplies what matters: the scope of the list, the components of a 'complete calendar', the notion of verified years, and the consequence when a court is absent. An agent can call it and interpret the result without further context.

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

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

The tool takes zero parameters, so the baseline is 4 and the description has no parameter semantics to clarify. Nothing in the text misdescribes the inputs, and the schema fully specifies the empty object.

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

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

The description states a specific verb and resource ('Lista os tribunais com calendário forense completo') and scopes it with what is included (portarias, comarcas, feriados municipais) plus the verified years. It is clearly distinct from siblings like 'feriados' or 'calcular_prazo', though it never names an alternative to contrast with.

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

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

Usage is implied rather than stated: the second sentence explains that for uncovered courts the calculations fall back to national holidays only and warn the user, which hints this is a coverage-check tool to consult before relying on deadline math. There is no explicit 'use this when…' or 'do not use this for…' instruction, and no sibling is named as the alternative.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real value: local execution on the user's machine, no external lookup, no existence or ownership assertion, and — importantly — that the CPF is returned only masked. That masking note is output behavior an agent could not derive from the annotations or schema. It stops short of describing the result shape for valid vs. invalid input.

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

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

Three short sentences, no filler. The core action is front-loaded and the disclaimers (no database, no ownership, masked return) follow in the order an agent would need them to avoid misusing the result.

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 two-parameter, single-purpose validator with no output schema, the description covers the essential unknowns: what is checked, what is deliberately not checked, and that the CPF comes back masked. A minor gap remains around what the return looks like on an invalid document (error vs. boolean) and how the 'tipo' inference behaves on ambiguous lengths.

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

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

Schema description coverage is 100%: 'documento' is documented as CPF or CNPJ with or without punctuation, and 'tipo' explains that omitting it makes the tool infer from length. The description adds nothing about either parameter, but with full schema coverage the baseline of 3 is appropriate rather than a penalty.

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

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

States a precise verb and resource: checks the check digit (dígito verificador) of a CPF or CNPJ, and adds the non-obvious scope note that the 2026 alphanumeric CNPJ is covered. The clause 'não consulta nenhuma base' implicitly separates it from the sibling consultar_cnpj, which does query a registry, so an agent can choose between them without opening a schema.

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

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

Gives strong negative guidance that functions as routing: it does not query any database, does not say whether the document exists, and does not say whose it is — exactly the conditions under which an agent should reach for consultar_cnpj instead. What's missing is an explicit naming of that alternative, so the agent must infer the hand-off rather than being told it.

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