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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description only needed to add runtime nuance — and it does. It discloses that the ausencia block appears only when there are no results, carries the same diagnosis as datajud_get_processo, and is omitted when results exist. This conditional response behavior is genuinely useful beyond the annotations and matches the read-only claim ('Consulta').

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?

Four compact sentences with the core purpose and return fields front-loaded before the conditional behavior. Every sentence earns its place except the final one ('Com resultados, esse bloco não é retornado'), which restates the conditional nature of ausencia already implied early in the description. Minor redundancy, otherwise tight and well-ordered.

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 2-parameter, read-only query with no output schema, the description covers the essential ground: return shape, conditional ausencia behavior, primary use case, and a relationship to datajud_get_processo. Gaps remain — no CNJ number format, no error semantics beyond the ausencia block, and no explicit statement of which sibling to prefer in which scenario. Solid but not 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%, so the description must compensate for the schema's silence. It maps the two parameters conceptually ('número CNJ e tribunal'), but adds no format detail — most critically, it never specifies the expected CNJ number pattern for numero_processo, which is a string with zero structure in the schema. The tribunal enum structurally documents the court values, but the problematic parameter remains under-specified.

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 ('Consulta movimentações por número CNJ e tribunal') and enumerates the returned fields (tribunal, numeroProcesso, instancias[]). The passing reference to datajud_get_processo for the ausencia block hints at sibling differentiation, but the description never explicitly separates this from datajud_search or datajud_raw_query. Clear on what it does, though not fully differentiated from all 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?

Provides an implied use case ('Ideal para detectar movimentação nova'), which signals when the agent should reach for this tool. However, there is no explicit when-not-to-use guidance or alternative routing, aside from a passing note that datajud_get_processo yields the same absence diagnosis. The agent must infer the selection criteria against the other datajud siblings.

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