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

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Só lê, não altera nada' mostly restates structured data. The description does add real behavioral context by disclosing that entries carry origin, before/after values, evidence, and undo availability — but return-field detail is also covered by the output schema, and no auth, scoping or pagination behavior is explained.

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 purpose and the returned-dimension list are front-loaded and reasonably tight, but the trailing sentence about a non-existent 'desde' field does not earn its place and actively misleads. The read-only sentence duplicates the annotations.

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

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

An output schema exists, so explaining return values is not strictly required, and the tool is simple (three params). However, with 0% schema coverage an agent still lacks any explanation of `cursor` pagination and is given a phantom `desde` parameter, leaving gaps that matter for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it only half does: 'Filtre por campo' maps to `campo`, but `cursor` is never mentioned and `processoId` is left implicit. Worse, it describes a field named 'desde' ('O campo desde diz a partir de quando o registro existe') that does not exist in the input schema, which can send an agent looking for a parameter it cannot pass.

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

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

States a specific verb and resource: 'Mostra o histórico de alterações do cadastro de uma pasta', then enumerates the recorded dimensions (author, time, origin, channel, before/after, evidence, undo state). This makes it distinguishable in practice from siblings like linha_do_tempo or listar_acoes_reversiveis, 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?

Usage is only implied ('Filtre por campo' tells how to narrow, not when to reach for this tool). There is no statement of when to prefer it over linha_do_tempo, listar_acoes_reversiveis, or saude_do_cadastro, and no exclusions or prerequisites beyond the read-only note.

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