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

With no annotations, the description carries the full burden and does it well: it defines the status semantics (ok / parcial / indisponivel, clarifying that indisponivel is not the same as inexistência), explains nao_indexado for external-source items, and explicitly disclaims vigência. It also discloses a side effect ('Pode gravar cache local') and the hard limit of 50, none of which the schema or annotations convey.

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?

Information-dense and front-loaded: the search scope and 'returns candidates, not legal validity' caveat come first, followed by status semantics and the routing hint. The line-broken list style is slightly ragged but every clause carries substantive meaning.

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

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

An output schema exists, yet the description still usefully enumerates status values and the nao_indexado flag, and it discloses the cache write side effect that no annotation covers. Given the tool's moderate complexity (external network sources, offline mode, pagination), only the pagination/cursor behavior and the distinction from the source-specific siblings are 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 0%, so the description has to compensate and only partly does: it explains `fonte` restricts to one source, `data` selects the redação, and repeats the 50 cap for `limite`. The required `q` and especially `cursor` (pagination, only inferable) are left undocumented, so a quarter to half of the parameter space remains opaque.

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 legislação e normas') plus the scope (local index, falling back to official sources named explicitly: Planalto, CVM, BCB/CMN, Senado). It also states the output nature ('Devolve CANDIDATOS'). It does not differentiate itself from the sibling tools buscar_normas_cvm and buscar_normas_bcb, which appear to overlap with its fonte-scoped behavior, leaving some ambiguity about which entry point to choose.

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 explicit usage chain: 'Use para descobrir a norma; depois obter_dispositivo e verificar_citacao', which tells the agent this is a discovery step and names the follow-up tools. It also sets the expectation 'não vigência nem prova'. It stops short of when NOT to use it (e.g. versus the source-specific buscar_normas_cvm/bcb siblings).

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that the API is queried live, that results are candidates, that status ok|parcial|indisponivel means source/network/offline failure rather than zero hits, that some circulars may lack device structure, and that a local cache may be written. Remaining gaps are pagination, result volume, and authentication requirements.

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 in the first line and the behavioral caveats follow. The parenthetical status gloss is dense but each clause carries information; a few items (the circular JSON note) are phrased elliptically enough to slow an agent down.

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 search tool with an output schema, the definition covers the important non-obvious behavior: live querying, candidate results, degraded-source semantics, cache writes, and field provenance for situação/revogação. What is missing – query syntax and result limits – is modest given an output schema already exists.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate. It explains `tipo` ('restringe a espécie') but does not say what values are accepted or how matching works, and `q` is never described (query syntax, phrase support, max 4000 chars go unmentioned). Partial compensation only.

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 ('Busca') and resource ('normativos do BCB e do CMN') and enumerates the document species (resoluções, circulares, cartas circulares, instruções normativas). The explicit source scope (BCB/CMN) cleanly separates it from the sibling buscar_normas_cvm and the jurisprudence tools without needing 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?

Usage is only implied by the source scope; there is no explicit statement of when to pick this over buscar_legislacao or buscar_normas_cvm, nor any 'do not use for X' exclusion. The note about 'CANDIDATOS' and the status values does tell the agent what to expect, which shapes usage indirectly but leaves selection 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?

With no annotations present, the description carries the full burden and does so well: it discloses that the source is a live portal index, that act text is only captured when indexed, the three possible statuses (ok | parcial | indisponivel) and their meaning, that nao_indexado items assert nothing about vigência, that a declared revocation on the act page blocks validity, and that it may write a local cache. Failure modes, partial-result semantics and a side effect are all surfaced before invocation.

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?

Front-loads the purpose in the first clause, then layers source, result semantics, parameter note and routing advice. Dense and telegraphic with some sentence fragments ('Item nao_indexado não tem captura nem afirma vigência'), but essentially every clause carries operational information and none is redundant.

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

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

An output schema exists, yet the description still usefully explains the candidate/status model and the non-indexed caveat, plus the cache write and jurisprudence routing — enough for correct invocation and result interpretation. The one real gap is the unstated value space for `tipo`, which leaves the agent guessing at a required input format.

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

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

Schema description coverage is 0% for 2 parameters, so the description must compensate. It explains `tipo` only at the level of 'restringe a espécie' — never enumerating the accepted values, so an agent cannot construct a valid `tipo` string from the definition. `q` is left entirely implicit, though its meaning as the query string is inferable from the verb.

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 normas no portal oficial da CVM') and enumerates the covered species (resoluções, instruções, pareceres de orientação), so the agent knows exactly what corpus is searched. It explicitly routes Collegiate decisions to pesquisar_jurisprudencia, distinguishing itself from one sibling, but says nothing about how it differs from buscar_legislacao or buscar_normas_bcb, which occupy adjacent territory.

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

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

Gives a concrete alternative with its triggering condition ('Decisões do Colegiado são jurisprudência: use pesquisar_jurisprudencia') and explains that `tipo` narrows the species. It also warns that an 'indisponivel' status is a portal/network/offline failure and NOT an empty result set, which is exactly the kind of usage guidance that prevents misinterpretation. No explicit guidance on when to prefer buscar_legislacao, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the history is source-limited, that the altering act's date is not the start of validity, and that absence of history is not a claim of immutability. These epistemic caveats prevent real misinterpretation; only a short read-only/no-side-effects note is missing for a perfect score.

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 definition is front-loaded with the core purpose, then caveats, then the sibling routing. Every sentence carries information; it is dense but not padded, though the parenthetical delimiter remark is slightly awkwardly placed and could be tightened.

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

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

An output schema exists, so the description needn't describe return values, and it covers purpose, limits and the alternative tool. The remaining gap is input-format guidance for `citacao`, which is the one thing an agent could still get wrong when calling it.

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

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

Schema description coverage is 0% for the single required parameter `citacao`, so the description must compensate. The parenthetical about 'trechos entre delimitadores de documento oficial' hints at the expected input form, but it does not state the citation syntax, delimiter format, or what happens if the citation is ambiguous or unresolvable.

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 first sentence states a specific verb+resource: a timeline of redactions and events for the cited device, scoped to what the official source contains. It is clearly distinguishable from verificar_citacao, which is named explicitly, so an agent can pick between them 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?

It gives an explicit when-to-use ('Use para citar redação antiga') and an explicit when-to-use-instead ('para a vigência numa data, use verificar_citacao com `data`'), naming the alternative and the discriminating condition. This is exactly the routing guidance an agent needs.

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

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

With no annotations, the description carries the burden and does so well: it declares that sources with an open circuit respond "unavailable", that a count of 0 means an empty acervo, that the recorte describes the installed collection rather than the official source, and that three fields are experimental. It omits anything about cost, latency, or read-only guarantees, which are only implied by "lista".

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?

Front-loaded with the purpose and the "start here" directive, then a compact per-field breakdown. It is on the long side and partly restates return fields that an output schema already exposes, but each clause (circuit states, experimental fields, recorte limits) adds genuine interpretation rather than 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 zero-parameter discovery tool with an output schema, the description covers what an agent needs: the shape of the response, the meaning of empty counts, and the two degraded states (nao_confirmado_no_acervo, unavailable). Nothing required to call it correctly is missing.

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

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. The description spends its space on return-value semantics instead, which is the right allocation for a no-arg tool.

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 fontes") plus the scope it covers (what each source covers and the instalado acervo recorte), so an agent knows it is an inventory/discovery call rather than a search. It never names a sibling tool or explicitly contrasts itself with buscar_legislacao or pesquisar_jurisprudencia, so sibling differentiation is left implicit through the "Comece por aqui" framing.

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?

"Comece por aqui" gives a clear entry-point instruction, and the note that outside the recorte the answer becomes nao_confirmado_no_acervo or depends on a live query gives concrete downstream guidance. No explicit when-not-to-use or alternative-tool routing is stated.

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

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

With no annotations, the description carries the full burden and does so: it discloses the non-substitution guarantee ("nunca outro documento no lugar"), the four possible status outcomes, that nao_encontrado_no_acervo refers only to the local corpus and not to real-world nonexistence, and that partial text is paged. It also states the mutual-exclusion rules between parte_idx and offset/max_chars, which an agent could not infer from the schema.

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

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

Purpose is front-loaded in the first sentence, followed by parameter semantics and then usage, which is a sensible order. The middle paragraph is dense and runs statuses, paging and the experimental alternative together without line breaks, so it reads as a block rather than scannable chunks, but almost every clause carries non-obvious 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 seven-parameter read tool with no annotations and two competing paging modes, the description covers failure modes, ambiguity handling, limits and mode incompatibility, and an output schema already documents return fields such as `particao`. The remaining gap is `id`: where it comes from and what it looks like is only implied.

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

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

Schema coverage is 0%, so the description must define all seven parameters, and it defines six of them meaningfully: parte's enum values, offset as paging, max_chars default 8000 / cap 50.000, parte_idx ordering semantics with parte_tamanho range 500–10.000, default 2.000 and 200-codepoint overlap, plus tribunal's role in disambiguation. Only `id` is left without format or provenance detail beyond the implied link to pesquisar_jurisprudencia.

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?

"Obtém a parte disponível de uma decisão do acervo" gives a specific verb and resource, and the parenthetical delimits the return as official-document text. It also names the sibling predecessor (pesquisar_jurisprudencia), so the agent can place it in a workflow, though it doesn't explicitly contrast with obter_evidencia or obter_registro.

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

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

"Use depois de pesquisar_jurisprudencia, para ler e citar com url oficial e fetched_at" states the entry condition and downstream use, and the status list tells the agent what to do when the identifier is ambiguous (informe `tribunal`). It stops short of explicit when-not-to-use guidance versus the other lookup siblings.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the delimiter wrapping of official documents as data-not-instruction (a prompt-injection defense), the four-valued status taxonomy with an explicit clarification that 'indisponivel' means capture or source failure rather than inexistence, and the returned url/capture_id used for citation. These are non-obvious behavioral traits an agent could not infer otherwise.

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?

Front-loaded with purpose, then inputs, then status semantics, then workflow ordering — no filler sentences. It is denser than ideal, packing parentheticals and a status enum into a short block, but every element earns its place.

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

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

Covers purpose, inputs, failure modes and citation outputs for a read-only lookup tool with no annotations; the output schema covers the return shape. Remaining gaps are minor: no guidance on handling 'ambigua' results (e.g., disambiguate and retry) or on auth/rate behavior.

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

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

Schema coverage is 0%, so the description must compensate; it explains that `citacao` or the pair `work_id` + `caminho` must be supplied, and that `data` selects the redaction/version. It does not specify the expected syntax of `caminho` (a path within the work) or of `citacao`, nor what a null `data` means, so format-level meaning is still missing.

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 (obter) and resource (texto do dispositivo: artigo, inciso, parágrafo) plus the version dimension (na redação da `data`), which distinguishes it from siblings like historico_dispositivo and verificar_texto. The function is unmistakable 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 places the tool in a pipeline: 'Use depois de resolver_citacao ou buscar_legislacao e antes de citar o texto', naming the prerequisite siblings and the follow-on action. It also gives the input-mode alternatives (informe `citacao` ou `work_id` + `caminho`) and the status semantics that tell the agent whether to retry (indisponivel) or conclude non-existence (inexistente).

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

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: pagination via offset, text wrapped in official-document delimiters, enumerated status values, and the crucial scope limit that a capture proves the origin of bytes but neither validity nor legal judgment. It does not say whether it is read-only or what happens with an invalid/expired capture_id, 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?

The output/what-you-get statement is front-loaded, and the usage and caveat sentences follow in a sensible order with no filler. The parenthetical asides and line-broken status enumeration make it slightly less scannable than it could be.

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

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

An output schema exists, so return structure need not be re-explained; the description still covers purpose, pagination, status semantics, and evidentiary limits, which is what a three-parameter read tool needs. The remaining gap is error/edge behavior for a bad capture_id, which the agent would have to discover at call time.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partly does: it explains that capture_id comes from other tools and restates the 50,000 max_chars ceiling already encoded in the schema. The offset parameter, the core of the pagination contract, is never explained, so half the parameters remain opaque.

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 first sentence names the specific resource: metadata of an official capture (url, hash, date) plus the extracted text, paginated between document delimiters. That is a concrete verb+resource statement an agent can act on. It stops short of 5 because it never names a sibling tool (e.g. resolver_citacao or obter_dispositivo) that would be the alternative when a capture_id is not in hand.

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

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

"Use para conferir de onde veio um resultado (capture_id vem de outras ferramentas)" gives a clear trigger and tells the agent where the required id originates. The caveat that status=unavailable means the capture is missing rather than the document not existing is a useful anti-misuse rule. No explicit exclusions or named alternatives, so it falls short of 5.

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

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

No annotations are provided, so the description carries the full burden, yet it never declares that this is a read-only lookup, nor what happens when the record is absent ('encontrada' implies a found/not-found outcome but the negative path is unexplained). It hints that the response carries integrity and conference status, which is useful, but side effects, permissions, and error behavior stay undisclosed.

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 lines with no padding, and the resource statement is front-loaded before the input/output breakdown. The inline reference 'decisão 0075, 3.4' is cryptic but costs little space.

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

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

For a tool with three parameters, one required identifier, a nested evidence structure, and no annotations, the description leaves too much open: the meaning of the conference check, the not-found behavior, and its place among twelve sibling lookup tools. The presence of an output schema offsets some return-value burden, but the core semantics remain thin.

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

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

Schema description coverage is 0%, so the description must compensate. It names all three parameters and marks two as optional, but adds no meaning beyond the schema: it does not explain why evidence objects or a temporal basis must be supplied to a retrieval call, nor what 'conferência' validates against the record.

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 phrase 'Registro local da operação de verificação' identifies the resource (the local record of a verification run) and the mention of 'encontrada' with 'integridade e status de conferência' hints that this retrieves a record. However, no explicit verb of retrieval is used and nothing distinguishes it from siblings such as obter_evidencia or obter_decisao, so an agent must infer the exact purpose.

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 only describes the inputs; it never states when this tool should be chosen over obter_evidencia, obter_decisao, or verificar_citacao, nor any precondition such as a prior verification run. No when-not guidance is offered either.

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

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

With no annotations, the description carries the full burden and does so: it discloses that results are 'CANDIDATOS, não prova', enumerates the status vocabulary (ok | parcial | indisponivel | nao_confirmado_no_acervo) with the key caveat that the last is not proof of nonexistence, warns that search is lexical not semantic, and notes local cache writes. That is unusually rich disclosure for a retrieval tool.

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?

Front-loaded with the core verb and the source enumeration, then the return-semantics caveats — a sensible order. The per-tribunal recorte block is long but each clause carries distinct operational information; only the 'limite máximo: 50' line is wasted 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?

For a multi-source, multi-modal retrieval tool this covers the hard parts: coverage semantics, failure modes, and next-step routing (an output schema exists, so return shape needn't be spelled out). The gap is the four undocumented parameters, which leaves the agent guessing about date filtering and pagination.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate and largely doesn't: `desde`, `ate`, `cursor` and `autoridade_min` are never mentioned. It adds real meaning for `q` (the three query forms) and `tribunais` (aceita siglas e nomes), but 'limite máximo: 50' merely restates the schema's maximum rather than explaining pagination interaction with `cursor`.

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 ('Pesquisa jurisprudência') plus the three search modes (tema, número CNJ, classe e número) and the scope ('nas fontes cobertas'). It also names the sibling it hands off to (obter_decisao) and the one that enumerates the corpus (listar_fontes), so the agent can distinguish it from neighbors without opening any schema.

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

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

Per-tribunal guidance is explicit: which sources are live vs. local-only, where a CAPTCHA or WAF blocks scraping, and what each court returns (e.g. 'TCU ... sem busca ao vivo', 'acórdão só com ementa'). It also states the sequencing rule — read `cobertura` before concluding something doesn't exist, then complement in another source, then call obter_decisao.

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

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

No annotations exist, so the description carries the burden and does well: it names the covered sources (Planalto, CVM, BCB/CMN, Senado), discloses on-demand capture and the side effect "Pode gravar cache local ao capturar a obra", and defines the five status outcomes with the crucial distinction that 'indisponivel' is not the same as 'inexistente'. It omits auth/network requirements and rate or latency expectations for on-demand capture.

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?

Front-loaded with the verb, input, and outputs; the status enumeration is dense but each value carries distinct meaning. Somewhat telegraphic pipe-delimited syntax, but no sentence is wasted.

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

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

An output schema exists, so return values need not be explained, and the description still contributes the domain context an agent needs: source coverage, capture-on-demand behavior, cache side effect, and the outcome taxonomy. Nothing essential for correct invocation 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 0% for the single parameter, so the description must compensate, and it does by giving a concrete citation format example («art. 254-A da Lei 6.404/76»). It does not address the 4000-character limit or what happens with malformed input beyond naming the 'formato_invalido' status.

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 ("Resolve uma citação normativa") and the concrete outputs (work_id e caminho), plus a worked example of the citation format. It does not distinguish itself from the similarly named sibling verificar_citacao, so an agent cannot be fully sure which of the two to pick from the description alone.

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

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

"Use para identificar a obra antes de obter_dispositivo" gives an explicit sequencing rule and names the downstream sibling, which is strong guidance. It stops short of exclusions — nothing says when to prefer verificar_citacao or what to do when the result is 'ambigua'.

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

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

With no annotations the description carries the full burden and does so: it defines the outcome state machine (verified, unknown, ambiguous, unavailable, not_found), clarifies that unavailable means source failure rather than non-existence, states that support stays not_assessed and proposicao is only echoed, warns that 'verified' never means 'juridically correct', and discloses the local-cache write side effect.

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 core action is front-loaded in sentence one, followed by state semantics, then usage and exclusions. Every clause carries non-obvious information; nothing restates the tool name or 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?

An output schema exists, so return-shape detail is unnecessary; the description supplies the state vocabulary an agent needs to interpret results, an explicit sibling handoff, and the cache side effect. The only residual gap is the undocumented data/trecho parameters, which is a minor omission for a verification tool.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It explains modo (literal | normalizado) and the passive role of proposicao, but leaves data and trecho undefined and says nothing about how citacao is parsed or how trecho interacts with the literal/normalizado modes.

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 ('Verifica uma citação normativa contra captura oficial') and enumerates the four verification dimensions (identity, text, temporal, support). It also draws a bright line against the sibling obter_decisao by declaring that judicial decisions are out of scope, so an agent can route 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?

Gives an explicit trigger ('Use antes de citar um dispositivo ou trecho') and an explicit exclusion plus alternative target ('Não verifica decisões judiciais: para elas, obter_decisao'). This is the when/when-not/alternative pattern in full.

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

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

No annotations, so the description carries the burden, and it discloses the most important behavior: the enumerated per-citation states including the subtle distinction that 'indisponivel' is not the same as 'inexistente', plus hard limits (100,000 chars, 200 citations) and the fact that it may write a local cache. Missing only whether the operation otherwise mutates anything or requires configuration.

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?

Tight, front-loaded, and organized into purpose, state taxonomy, routing rule, and limits with no wasted prose. The state enumeration is somewhat dense in a single run-on line, but every clause carries information.

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

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

The output schema covers return values and the description covers scope, limits, states, and the sibling alternative, which is nearly everything needed to call it correctly. The one real gap is the undocumented 'data' parameter, which matters for a verification tool where the reference date could change results.

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

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

Schema coverage is 0%, so the description must compensate. It does partly – the text length limit restates the schema's maxLength and the 200-citation cap is genuinely new – but the 'data' parameter is left entirely unexplained in both schema and description, leaving the agent to guess its purpose and format.

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 pair and resource: extracts normative citations from a text and verifies each one (anti-hallucination). This is clearly distinct from the sibling verificar_citacao, which it names explicitly as the single-citation alternative.

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 explicit routing rule: use this for reviewing an entire draft, use verificar_citacao for a single citation. It also sets a scope boundary – citations outside covered sources are simply not validated rather than reported as failures.

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