processo-mcp

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 a meaningful side effect: the PDF opens in the user's browser rather than returning data. However, it omits other behavioral facts an agent needs, such as what happens with an out-of-range page, whether this requires the case/file to be prepared first, or any failure 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?

A single front-loaded sentence with no filler. The core action, target, location, and intent are all packed efficiently with zero 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?

The presence of an output schema means return values need not be explained, which the description correctly omits. Still, with 0% parameter coverage and no annotations, the definition leaves the required "caso" argument and error/permission behavior undocumented, so it is only minimally complete for a three-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 description coverage is 0%, so the description must compensate. It only loosely signals the pagina parameter ("página indicada") and implies arquivo ("PDF original"), but says nothing about the required caso identifier and gives no format or validity details for any of the three 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?

States a specific verb (abre), resource (PDF original), target page, and destination (navegador / tela do usuário), which clearly separates it from a content-fetching sibling like obter_pagina. It does not name that sibling explicitly, but the browser-screen framing makes the action 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?

"para conferência visual do documento" implies the use case (human visual inspection), so usage is inferable but never stated as a when-to-use rule. There is no exclusion or guidance distinguishing it from obter_pagina, which is the obvious alternative for retrieving page content.

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 disclose useful behavior: results include file and exact page, it works by meaning and by identifier, and 'arquivo' scopes the search to one PDF. It omits permission/rate-limit behavior but adds a verification workflow that shapes safe usage.

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 and then the output/citation contract, with the 'arquivo' usage note last. Dense but mostly efficient; the examples add value rather than padding.

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-value detail is not needed, and the citation/verification workflow compensates well. However, top_k and rerank materially affect search results and are unexplained in both schema and description, leaving a real gap for a semantic-search 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 0% and only one of five parameters is explained: 'arquivo' (optional, restricts to a single PDF, useful in multi-volume cases). caso, query, top_k, and rerank carry no meaning beyond their bare titles, leaving the retrieval-tuning parameters 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 (busca) and resource (documentos do caso), and clarifies the dual mode 'semântica + literal' with concrete examples. It also names the sibling relationship with obter_pagina for verification, so an agent can distinguish its role from the other case-level tools.

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 clear operating context: always cite '(arquivo, p. N)' and verify with obter_pagina before asserting sensitive facts, and use the 'arquivo' filter for multi-volume cases. It stops short of explicit when-not-to-use or direct alternative routing (e.g., vs indice_pecas or cronologia).

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 two real behavioral traits: results are ordered by the PJe footer signature date, and the piece 'Tipos' are heuristic rather than authoritative. It still omits permissions, whether prior indexing is required, and output size/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 short, front-loaded sentences with no filler; the purpose and the ordering rule come first and the reliability caveat follows. Slightly terse — 'Tipos são heurísticos' leaves 'tipos' unexplained.

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-value detail is unnecessary, and the tool is low-complexity with one parameter. The description covers purpose, ordering, and a data-quality caveat, but leaves the 'caso' argument format and any indexing prerequisite 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 0% and the description never mentions the single required parameter 'caso' at all — no indication whether it expects an ID, case number, or name. The description adds no semantics beyond what the bare 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?

States a specific resource (cronologia/linha do tempo do processo) and a precise ordering rule (data de assinatura do rodapé PJe), which distinguishes it from index-style siblings like indice_pecas. It never names indice_pecas or resumo_caso explicitly, so sibling disambiguation is only partial.

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 closing clause 'confirme peças-chave com obter_pagina' points to an alternative tool and implicitly tells the agent this output is not authoritative for key pieces. However, it gives no positive guidance on when to reach for cronologia versus indice_pecas or resumo_caso, and no prerequisite conditions (e.g. whether indexar_caso must run first).

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 cost semantics (estimate shown with confirmar=False, nothing spent without confirmar=True), the mandatory user-confirmation protocol, incremental-by-hash behavior, rebuild semantics (full reset, e.g. model change), background execution for large cases, and per-PDF commit atomicity so partial work is not lost. These are exactly the irreversible/spend traits an agent must know.

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 clause, followed by the safety-critical spending rule, then the incremental/rebuild distinction, then the background/monitoring note. Every sentence carries decision-relevant information with 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?

An output schema exists, so return-value explanation is correctly omitted. Given the tool's mutation-and-cost profile with three parameters, the description covers spend gating, confirmation ownership, idempotency/rebuild, execution mode, and progress monitoring — nothing needed to invoke it safely 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%, and the description compensates for two of three parameters with real meaning beyond the schema: confirmar (dry-run vs. actual spend, user-gated) and rebuild (rebuild from scratch, e.g. after a model swap). The 'caso' parameter is left implicit but is self-evident as the target case identifier, leaving only a minor 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?

The description opens with a concrete verb+resource ('Indexa as páginas preparadas') and names the underlying mechanism (voyage-4-large + FTS5), which tells the agent this is the indexing step that consumes output from preparar_caso rather than a search or listing tool. Scope (entire prepared corpus of a 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?

It gives clear operational conditions: confirmar=False is a dry-run, confirmar=True is required to spend, and confirmation 'deve vir do usuário, nunca ser presumida'. It also routes background monitoring to status_caso. What it doesn't state explicitly is the prerequisite ordering (index after preparing) or any exclusion, so it stops just short of a full when/when-not/alternative statement.

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 load. It usefully discloses that the type is heuristic (unreliable and worth verifying), that the data comes from the PJe footer, and that the operation is local, free, and cached — meaningful context about cost, speed, and data quality. It stops short of explicitly stating read-only/purity or how stale the cache can be.

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 packs the purpose, the returned fields, the heuristic caveat, and the local/free/cached traits with no filler. The parenthetical tool reference is placed exactly where the risk it mitigates is mentioned.

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 with an output schema, the description covers output meaning, data provenance, the heuristic caveat, and cost/latency characteristics. The only real gap is the undocumented 'caso' argument, which keeps this from being fully self-sufficient.

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?

There is one required parameter (caso) with 0% schema description coverage, so the description must compensate — and it does not. It never explains what form the 'caso' identifier takes (number, internal id, slug) or where the agent obtains it, leaving the sole parameter 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 concrete noun+scope: an index of the case's peças (documents) reconstructed from the PJe footer, and enumerates the returned fields (document number, type, page range, date, signer). An agent can tell what it produces. It does not, however, distinguish itself from the similarly named sibling indexar_caso, which could be confused with it.

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 one indirect usage cue: confirm key peças with obter_pagina because the type field is heuristic. But it never says when to reach for this tool over indexar_caso, resumo_caso, or status_caso, so the routing guidance 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the returned content (status of PDFs, prepared pages, index, summary), which implies a read-only enumeration, but it never states side-effect freedom, permissions, or cost/latency characteristics explicitly.

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 sentences, front-loaded with the verb and scope, and the second sentence immediately positions the tool in the workflow. Nothing is redundant or padded.

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 detail return structure, and it correctly focuses on what gets listed and when to call it. Given zero parameters and a low-risk read operation, this is nearly complete; only an explicit read-only/safety note 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 — there is no argument semantics for the description to clarify. The schema is an empty object, consistent with a pure enumeration call.

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 ('Lista os casos') and adds scope ('subpastas de ~/Processos') plus the content surfaced (PDFs, páginas preparadas, índice, resumo), so the agent knows this is an inventory/listing operation. It does not name a specific sibling it is distinct from, relying instead on the generic 'ponto de partida' 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?

'Ponto de partida de qualquer conversa' gives clear context for when to reach for this tool — at the start, before drilling into a single case. There are no explicit exclusions or named alternatives (e.g. status_caso / resumo_caso), so it stops short of a full when/when-not rubric.

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 usefully discloses that the returned text is raw extraction/OCR (implying possible OCR noise) and that it is the authoritative source for validating citations. However, it says nothing about error handling, missing pages, permissions, or rate limits, so it adds only partial behavioral context.

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 with no filler: the first front-loads what is returned, the second combines the use case with the one non-obvious parameter detail. Everything 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?

An output schema exists, so return formatting need not be restated, and the description adds the key content-type characterization. The main gap is the undocumented 'caso' and 'pagina' parameters for a 3-required-param tool with no annotation support.

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% and all three params are required, so the description must compensate. It documents 'arquivo' well (accepts name, stem, or relative path as shown in the citation), but 'caso' and 'pagina' receive no explanation at all, leaving two of three parameters dependent on inference.

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 (page text), and specifies the return is literal/complete OCR text, which is more precise than the name alone. It links itself to the search flow ('a fonte que valida a busca'), giving some differentiation from siblings like buscar, though it never explicitly distinguishes itself from the very similar abrir_pagina 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?

Gives a concrete when-to-use directive with rationale: 'Use para verificar citações antes de afirmar.' This is a clear usage context rather than a mere implication, but no alternatives (e.g., abrir_pagina) or when-not conditions are 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?

With no annotations, the description carries the full burden and does well: it discloses that OCR runs locally and nothing leaves the machine (privacy), that the operation is free (cost), and that large cases execute asynchronously with a companion polling tool. It omits failure behavior, idempotency, and whether existing extracted text is overwritten.

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 action, then terse clauses for OCR/privacy, cost, async behavior, and the follow-up step. Every fragment earns its place and nothing is padded.

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 the description covers the async workflow and the next step in the chain. It leaves a gap on input prerequisites and the format of 'caso', which matters for a one-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?

One parameter, 'caso', has 0% schema description coverage, and the description only refers to it obliquely as 'cada PDF do caso'. It never clarifies whether 'caso' is an ID, a name, or a path, so an agent gets no added format semantics 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?

States a specific verb and resource: extracts text from every PDF in the case, page by page, with local OCR for scanned documents. It also names its downstream sibling (indexar_caso), so an agent can place it in the pipeline without opening other schemas.

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?

Explicit sequencing guidance: run this, then indexar_caso, and for large cases poll status_caso while it runs in background. It stops short of stating prerequisites (e.g., the case must already exist/have PDFs) or when not to call it, so it is strong but not exhaustive.

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 behavioral burden and does so well: it discloses output format (landscape formatted table), save location, the required pre-analysis workflow, and two hard constraints (never a statement without source, quotes must be validated first). It does not state overwrite behavior or permission requirements, leaving a modest 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?

Front-loaded with verb+resource+format, then workflow and constraints; nearly every clause carries operational value. It is dense with emphasis caps but not padded, though the run-on structure 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?

For a document-generating tool with an output schema (so return values need not be described) and no annotations, the description covers generation, location, required prior analysis, and integrity constraints. Only edge behaviors like file overwrite and permissions are 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 the description must compensate, and it substantially does: it defines the row shape {tema, autor, reu, situacao}, gives an example enum for situacao, and shows how caso maps to a path. However, the titulo and arquivo parameters are never explained, so half the surface remains 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 (Gera) and resource (Quadro de Controvérsias), plus concrete output format (.docx, paisagem, tabela formatada) and destination (<caso>/relatorios/). It also differentiates itself from siblings by naming the companion tools (buscar, obter_pagina, validar_citacoes) that surround this 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?

Explicitly tells the agent to perform the análise beforehand and to cross-reference inicial × contestação using buscar/obter_pagina, and mandates validar_citacoes before any literal quote. Routing is clear, but no 'when not to use' boundary or exclusion is given.

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 the overwrite semantics, the resumo.md.bak backup of the prior version, and the advice to read before overwriting and preserve what still matters. It omits anything about permissions or concurrent-write risk, which is the only 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 short sentences, front-loaded with the core concept (persistent memory) before the read/write mechanics and the usage nudge. Dense but every clause carries meaning; 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?

An output schema exists, so return values need not be described. For a file-backed read/overwrite tool with no annotations, the description covers the destructive behavior and backup path adequately; only the meaning of the required 'caso' argument remains 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 coverage is 0%, so the description must compensate. It explains conteudo's dual semantics thoroughly (absent = read, present = overwrite), but the required 'caso' parameter is never defined beyond the implied 'na pasta' phrasing. Partial compensation for a 2-param 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+resource: a persistent case memory stored as resumo.md in the case folder, with read-vs-overwrite behavior keyed on whether conteudo is supplied. It is clearly distinct from siblings like status_caso or listar_casos, though it never names 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?

Gives concrete usage context: 'Atualize ao final de sessões relevantes' tells the agent when to call it, and the read/write branching tells it which mode applies. It stops short of naming sibling tools as alternatives, so it is clear context without explicit 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?

No annotations are provided, so the description carries the full disclosure burden. It adds useful context about what is inspected (PDF preparation state, OCR page counts, indexing backlog, cost estimate), which implicitly frames it as a non-mutating diagnostic read. However it never states read-only behavior, permission requirements, or whether the cost estimate is authoritative — meaningful gaps for a zero-annotation 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?

One front-loaded sentence with the resource and scope up front and no filler. The parenthetical sub-clauses earn their place by naming the specific data points returned.

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 exact return shape needn't be restated. But with no annotations, no usage routing against eleven siblings, and an undocumented sole parameter, the definition is only minimally complete for an agent deciding when to call 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?

The single required parameter 'caso' has no schema description (0% coverage) and is never mentioned in the description — no identifier format, no name-vs-ID guidance. Since coverage is below 50%, the description was expected to compensate and does not.

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 ('Estado detalhado do caso') and enumerates the concrete outputs: per-PDF preparation state, OCR page counts, in-progress preparation, remaining-to-index items, and estimated cost. This distinguishes it from the summary-style sibling resumo_caso, though it never names that sibling 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 and no mention of alternatives such as resumo_caso (overview) or preparar_caso/indexar_caso (the mutating actions it reports on). The diagnostic intent is only implied by the reported fields; an agent gets no explicit trigger conditions or 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?

No annotations exist, so the description carries the full burden, and it does substantial work: it enumerates the five verdicts, tells the agent to consume the returned passagem_real on QUASE, to REJEITAR on DIVERGENTE, and warns that NÃO ENCONTRADA may indicate invention. It does not state cost, rate limits, or that the operation is purely read-only, which is the only real 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 dense sentences, front-loaded with the purpose and the pre-report workflow trigger, followed by the item shape and the verdict taxonomy. No filler or restatement of the tool name.

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 needn't be explained, yet the verdict semantics are still spelled out because they drive the agent's next action. Only the 'caso' parameter's expected format/value is left unspecified, a minor gap 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 description coverage is 0%, so the description must compensate, and it does for the critical parameter: the item shape {trecho, arquivo, pagina} is documented nowhere in the schema (citacoes is an untyped array of open objects). The 'caso' parameter is only implicitly identified as the case handle, leaving one 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 and resource ('Valida transcrições LITERAIS contra o texto real das páginas') with an explicit scope limitation (textual citations only, not paraphrases). It also names the sibling obter_pagina as the tool for the out-of-scope case, so an agent can separate it from the other 11 siblings.

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 explicit timing ('use antes de qualquer relatório/petição') and an explicit exclusion plus alternative ('Só valida citação textual; paráfrase deve ser conferida com obter_pagina'). Both when-to-use and when-not-to-use are covered.

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