Calcular prazo processual

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

Annotations already mark it as read-only, idempotent, non-destructive, and local (openWorldHint false); the description goes further by explaining that computation is local, that each skipped day is reported with its source, that the DJEN date is the disponibilização, and that unsupported tribunals trigger a warning plus national-holiday fallback. That is real behavioral context beyond the annotations.

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 and every clause carries information; the colon list of covered regimes is efficient. The single dense sentence could be split for readability, but there is 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?

For an 11-parameter, domain-heavy tool with no output schema, the description explains what is computed, what the result reports ('passo a passo', each skipped day with its source), and how coverage gaps behave. Only the shape of the returned step-by-step output and error/warning format remain under-specified.

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 100%, so the baseline is 3; the description still adds interpretive meaning by tying 'dias' to the pre-doubling value, explaining the 10-day ciência ficta window, the 20/12–20/01 recess and suspension, and the tribunal/comarca holiday sources. It stops short of clarifying every parameter (e.g., how 'consulta' interacts with the 10 days), so not a 5.

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: computes the due date of a procedural deadline, and enumerates exactly what regimes it handles (CPC business days, CLT, calendar days, DJEN publication, electronic intimation with 10-day fictitious notice, double deadlines, recess 20/12–20/01, court and municipal holidays). It is clearly distinguishable from simple counters like contar_dias_uteis or somar_dias_uteis.

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 usage context (procedural deadline in a specific court/comarca) is implied by the mentioned regimes, and it does warn that full calendars exist only for tribunals in tribunais_cobertos, falling back to national holidays otherwise. However, no sibling tool is named as an alternative, so an agent must infer when to prefer this over contar_dias_uteis or prazos_da_lei.

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