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

With no annotations, the description carries the full burden and does meaningful work: it discloses a side effect ('Pode gravar cache local' — may write local cache) and an important epistemic caveat ('Retorna candidatos, não vigência jurídica' — returns candidates, not legal validity). It stops short of permissions, rate limits, or pagination behavior.

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

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

Three short lines with no padding; the core purpose is front-loaded and the caveats follow. It is efficient, though extremely terse relative to the tool's five parameters.

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 formatting need not be explained, and the cache/validity caveats cover behavior. However, for a multi-source search with cursor-based pagination and a source enum, the description leaves too many call-critical parameters (fonte, cursor, data) unexplained to be complete.

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, but it only mentions 'limite máximo: 50' — which merely repeats the schema's maximum of 50. The key semantics of q, data, fonte (including the cryptic '__somente_local__' enum value) and cursor are left entirely undocumented.

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') plus the mechanism (local index, then official connectors as fallback), so an agent knows this is a general legislation search rather than a source-specific sibling. It does not explicitly name or contrast with buscar_normas_cvm/buscar_normas_bcb/pesquisar_jurisprudencia, which would have made it 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?

No when-to-use or when-not guidance is given. The agent is not told how this general legislation search relates to the source-specific siblings (buscar_normas_cvm, buscar_normas_bcb) or to obter_dispositivo; the fallback behavior is internal mechanism, not a selection rule.

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 behavioral burden. It does disclose one real side effect ('Pode gravar cache local'), which is genuinely useful, but says nothing about permissions, result volume, rate limits, or freshness of cached 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?

Two short sentences with the purpose front-loaded and no padding, but the brevity reflects under-specification rather than tight editing.

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 described, but for a 2-parameter search tool with 0% schema coverage and no annotations, the definition omits query syntax, the meaning of 'tipo', and any routing guidance to sibling search tools.

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. The description never explains 'q' (query syntax, length limits) or 'tipo' (what values are accepted, whether it filters by norm type), so it fails to compensate for the coverage gap.

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

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

States a specific verb+resource ('Busca normativos no BCB/CMN'), which is clear and scoped to BCB/CMN regulations. The domain scope implicitly distinguishes it from the sibling buscar_normas_cvm, though no sibling is named 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?

No when-to-use guidance, no preconditions, and no mention of alternatives such as buscar_normas_cvm or buscar_legislacao. The agent must infer that this is the BCB/CMN-specific search from the tool name alone.

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

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

With no annotations, the description carries the full burden, and it does disclose one non-obvious behavior: the tool may write a local cache ("Pode gravar cache local"), which signals a side effect and possible staleness. It omits auth requirements, rate limits, result-size limits, and whether the cache is user-visible, so the disclosure is partial.

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 the purpose front-loaded and the behavioral note second; no wasted words. It is arguably too terse for a two-parameter search tool, but the sizing itself is efficient.

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 described, but with zero annotations, 0% parameter coverage, and no routing guidance against three close siblings, the description leaves too much for the agent to infer before calling.

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%: neither "q" nor "tipo" is documented in the schema or the description. The verb "busca" lets an agent weakly infer that "q" is a query string, but "tipo" (a type filter) is completely unexplained and its valid values are unknown.

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?

"Busca normas na CVM" gives a specific verb (search) and resource (CVM regulations), so the agent knows the domain immediately. It does not, however, distinguish itself from siblings like buscar_normas_bcb or buscar_legislacao, leaving the agent to guess which regulator's corpus this covers.

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 statement of when to use this tool versus the very similar buscar_normas_bcb or buscar_legislacao siblings, and no prerequisites or exclusions. The agent must infer selection from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden. It discloses the conceptual shape of the result (a timeline) but says nothing about whether the operation is read-only, how far back history goes, ordering, pagination, or what happens when the citation is ambiguous or unresolvable.

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 short sentence with the scope front-loaded and no filler. It is appropriately sized, though it is arguably too terse for a tool with no annotations and an undocumented parameter.

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. However, with no annotations, a 0%-covered parameter, and no usage guidance among many similar legal-research siblings, the definition is only minimally sufficient to invoke the tool 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 0% for the single 'citacao' parameter. The phrase 'dispositivo citado' hints that the argument is a citation to a provision, but no format, syntax, examples, or resolution behavior (e.g., whether a bare article reference is accepted) are given to compensate for the undocumented 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 resource and scope: a timeline of versions ('redações') and events for the cited provision, which is distinct from obter_dispositivo (current text) and resolver_citacao (citation resolution). It is a noun phrase rather than a verb+resource statement, and it does not explicitly contrast itself with any sibling, but an agent can still infer what it returns.

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 guidance, no prerequisite, and no mention of the obvious alternatives (obter_dispositivo for the current text, resolver_citacao for normalizing the citation). The agent must guess that this tool is the one for historical/versioning questions.

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 behavioral burden. 'Lista' implies a read operation, but nothing is said about permissions, side effects, freshness, or whether it hits live systems. With an output schema present, return values needn't be restated, but the remaining behavioral gaps are unfilled.

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 with no wasted words; the verb and resource lead. It is terse rather than padded, though it stops short of adding any 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 zero-parameter listing tool with an output schema, the description gives enough to call it correctly and names the three data points returned. Only the when-to-use context relative to the sibling tools 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, which is the baseline 4 case. The schema is empty and the description correctly implies a no-argument listing.

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 ('Lista') and resource ('conectores') and specifies exactly what is exposed: declared coverage, último health, and circuit state. This clearly distinguishes it from the legal-research siblings by resource, though it never explicitly contrasts itself with them.

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 guidance on when to call this tool versus alternatives, nor any prerequisite or trigger condition. The agent must infer its role from context alone.

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

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

Annotations are absent, so the description carries the full behavioral burden. It adds some real context by characterizing the result as 'texto oficial delimitado' and stating a 50,000-character ceiling, hinting at truncation behavior. It does not, however, disclose read-only nature, auth needs, or how offset/pagination interacts, leaving meaningful gaps.

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

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

Two short lines with the purpose front-loaded and no filler; every sentence is brief. The second line is partly redundant with the schema (parte enum, max_chars maximum), which slightly dilutes it, but overall it is tight and 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?

An output schema exists, so return values need not be explained, and the description covers the two most user-facing parameters. It is nonetheless incomplete for a 4-parameter tool because offset and its interaction with max_chars are never addressed.

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

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

Schema description coverage is 0%, so the description must compensate for four parameters. It explains parte's options and reiterates the max_chars ceiling (already in the schema's maximum), but leaves id and, critically, offset completely unexplained, so the pagination semantics remain undocumented in both places.

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 (obtém) and resource (decisão), and distinguishes the two main content forms (ementa vs. inteiro teor), which is more than a tautology. It does not, however, explicitly differentiate itself from siblings like pesquisar_jurisprudencia or obter_evidencia, leaving the agent to infer that this fetches a single known decision by id.

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 when-to-use or when-not-to-use guidance, nor any reference to the alternative sibling tools. The listing of parte values implies a choice exists, but that merely restates the enum already in the schema rather than advising the agent on when this tool is the right one.

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 behavioral burden. It says only that it returns the text of a 'selected' provision, but does not explain how the selection is made, whether the four optional parameters are alternatives or combinable, or what happens when none is supplied. Minimal disclosure for a tool with zero structured hints.

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 short sentence with no wasted words, but the brevity is under-specification rather than precision. It is front-loaded but contains almost no actionable content.

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 described. However, with four optional parameters at 0% coverage, no annotations, and no usage routing among many sibling retrieval tools, the description leaves too much unspecified for an agent to invoke the tool 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 description coverage is 0% across four optional parameters (data, caminho, citacao, work_id), and the description never mentions any of them. It does not clarify that these are alternative selectors (date/path/quote/work id) for locating the provision, leaving the agent with four undocumented optional inputs and no guidance on which to use.

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 (obtém) and resource (o texto da redação selecionada), but 'redação selecionada' and 'documento oficial delimitado' are vague in English/Portuguese legal-tool terms and do not distinguish this tool from siblings like obter_decisao, obter_evidencia, or resolver_citacao. An agent can guess it retrieves legal text but cannot confidently place it in the family.

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 statement of when to use this tool versus the many retrieval siblings (resolver_citacao, verificar_citacao, obter_decisao, obter_evidencia). No prerequisites, no selection conditions, no exclusions. Only implied usage from the verb.

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. It does disclose that results are paginated and that the document text is delimited, which is useful, but says nothing about what a 'captura' is, permission requirements, error behavior for invalid capture_id, or how metadata and text are combined in the response.

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 short and front-loads the content type, which is good. However, the second line duplicates the schema maximum for max_chars and adds no new information, so the space is not fully earned.

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?

Although an output schema exists (so return structure need not be explained), this is a 3-parameter tool with 0% schema coverage and no annotations. The description does not explain the required capture_id or the offset/max_chars contract, leaving key invocation details 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 coverage is 0%, so all three parameters depend on the description. The word 'paginado' hints at how offset and max_chars interact, but the max_chars sentence merely restates the schema maximum (50.000), and capture_id — the only required parameter — is entirely unexplained.

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+resource (obter_evidencia) and describes the payload: capture metadata plus paginated extracted text from a delimited official document. It does not explicitly differentiate from siblings like obter_dispositivo or obter_decisao, so it falls 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?

There is no statement of when to use this tool versus alternatives such as obter_dispositivo or obter_decisao, no prerequisites, and no exclusions. The agent must infer applicability from the name alone.

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

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

With no annotations, the description carries the full burden. It does disclose one non-obvious behavior ('Pode gravar cache local') and a hard limit (limite máximo: 50), which are genuine additions. However, there is no mention of auth needs, rate limits, pagination behavior despite a cursor param, or cost of the operation.

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?

It is short and the purpose is front-loaded, with no filler sentences. The constraint list is choppy and fragmented ('limite máximo: 50. tribunais: stj|...') rather than integrated, and the brevity comes at the cost of useful detail.

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, which relieves some burden. Still, for a 7-parameter tool with 0% schema coverage and no annotations, the description leaves key inputs (date range, cursor, authority filter) undefined, making correct invocation a guess.

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

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

Schema description coverage is 0%, so the description must compensate for 7 undocumented parameters. It only mentions 'limite' and 'tribunais', and both facts (max 50, the enum values) are already present in the schema constraints, so no real meaning is added. The core q, ate, desde, cursor, and autoridade_min remain entirely unexplained.

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') and names the source courts (STJ, TCU, TJSP, CVM Colegiado). This distinguishes it from buscar_legislacao (legislation) by resource, though the verb overlaps with several sibling search tools. Clear but differentiation from siblings is left largely 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 when-to-use guidance, no prerequisites, and no named alternatives. The list of courts hints at scope but does not tell an agent when this tool is the right choice versus buscar_legislacao or 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?

With no annotations, the description carries the full burden. It does disclose two real behavioral traits: on-demand capture (a network/fetch side effect) and a possible local cache write. It says nothing about failure modes (unresolvable citation), latency, permissions, or whether the cache write is idempotent, which is a meaningful gap for a tool with a filesystem 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?

Two short sentences, front-loaded with the core purpose and then the side effect. No padding or restated boilerplate, though the parenthetical could be phrased more informatively rather than as a terse aside.

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 correctly needn't detail return values, and it does summarize the key outputs plus the cache side effect. What remains missing is guidance on failure cases and the distinguish-from-siblings role that a 1-param resolver among 11 related tools really needs.

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% for the single 'citacao' parameter, so the description must compensate. It characterizes the input as a 'citação normativa' and reveals what the resolution yields (work_id and path), which adds real meaning — but it never gives the accepted citation syntax or format, so the agent cannot know what a valid string looks like.

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: it resolves a normative citation into work_id and path, which is concrete and actionable. However, it does not differentiate itself from the close sibling verificar_citacao (verify citation), leaving an agent to guess which one to call for a citation-related task.

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 parenthetical '(captura sob demanda)' hints that this tool fetches material when it isn't cached, but there is no explicit when-to-use guidance, no stated preconditions, and no routing away from verificar_citacao or buscar_legislacao. Usage must be inferred entirely.

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: it may write a local cache (a side effect), support remains not_assessed (a partial-verification caveat), and proposicao is only echoed rather than processed. These are exactly the kind of non-structural facts an agent needs. It stops short of permissions or failure semantics.

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, front-loaded lines with no filler; the purpose statement leads and the caveats follow. Telegraphic style is efficient, though the terse fragments slightly reduce readability for a non-Portuguese reader.

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 no explanation, and key behavioral quirks (cache write, not_assessed support, echoed proposicao) are covered. What is missing is the parameter-level semantics for data/trecho/citacao and any routing guidance versus the many sibling verification tools.

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

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

Schema description coverage is 0%, so the description must compensate for all five parameters. It only touches two: modo (redundant with the enum) and proposicao (the echo note, which is genuinely useful). data, trecho, and citacao receive no semantic explanation anywhere, leaving the majority of inputs undocumented.

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 (verifica) and resource (citação) plus the exact dimensions checked (identity/text/temporal/support) and the reference source (captura oficial). This is far more concrete than a bare 'verify' statement. It does not, however, explicitly distinguish itself from siblings like resolver_citacao or verificar_texto, so an agent must infer 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?

There is no when-to-use guidance and no mention of when to prefer resolver_citacao, buscar_legislacao, or verificar_texto instead. The only usage-adjacent line lists modo values, which merely restates the schema enum rather than advising selection.

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 it does add two genuine behavioral facts absent from the schema: the 100k-character and 200-citation limits, and that it 'pode gravar cache local' (may write a local cache). It still omits permissions, whether the cache write is consequential, and failure behavior when limits are exceeded.

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/sections with the core purpose front-loaded and limits promptly stated. No filler; marginally hurt by the terseness that leaves 'data' and sibling differentiation unaddressed.

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 described, and limits plus cache behavior are covered. Still incomplete: the required-vs-optional role of 'data' is opaque and the overlap with the sibling verificar_citacao is unresolved, which matters for correct selection.

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 documents a constraint on 'texto' (≤100,000 characters, matching the schema maxLength) but says nothing about the optional 'data' parameter, whose purpose and expected format are entirely unexplained in both schema and description.

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: it extracts and verifies citations from a supplied text, framed as an anti-hallucination check. However, it never distinguishes itself from the sibling 'verificar_citacao', which sounds near-identical, so an agent cannot confidently choose between them from the text alone.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as verificar_citacao (single citation) or resolver_citacao. The anti-hallucination framing implies a context, but the agent must infer that this tool is for whole-document checking rather than one citation.

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