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

Beyond the read-only annotations, it discloses pagination semantics (per category plus screen cards), cursor continuation rules, that the summary and general alerts appear only on the first page, that grouped suggestion counts are omitted, that totals respect filters and declare each category, the Brasília time reference, and that query failure is an error rather than an empty queue. It also states it does not mutate anything. These are exactly the behaviors an agent would otherwise guess wrong.

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 first sentence is a long comma-spliced enumeration that is hard to parse, and paging/error semantics are stacked into the same paragraph without grouping. Most sentences carry real information, but the lack of structure (no separation of scope, paging, limits) costs readability. Front-loading the use case is a plus.

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 shapes need not be described, and the description still covers the parts an agent cannot infer: paging across categories, first-page-only content, omitted counts, filter/total interaction, and error-vs-empty behavior. Nothing needed 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?

Schema coverage is only 33% (cursor and categorias have no schema descriptions), so the description must compensate, and it does: it explains that categories are filtered while the cursor is carried forward and that filters must be maintained across pages. The data parameter is already explained in the schema, and the timezone/window note adds a useful semantic. It does not clarify cursor format or the relationship between maxItems and paging.

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 use case ('Use para saber o que exige atenção') and enumerates the resources covered: KPIs, gráficos, decisões, avisos, sugestões, minutas, falhas, prazos, audiências, processos recentes. That distinguishes it from siblings like listar_prazos or minutas_a_redigir, which cover single categories. It is clear but the long enumeration blurs the single-sentence 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?

It gives one positive trigger ('saber o que exige atenção') and explicit capability exclusions ('Não aprova, descarta, resolve, envia mensagem nem retoma execução'), which implicitly routes follow-up actions elsewhere. However, no sibling tool is named as an alternative for acting on an item, and no condition tells the agent when a narrow tool such as listar_prazos would be preferable.

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