Libelus

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses two critical behavioral traits an agent could not otherwise know: it does not return rulings (only access instructions), and it is gated behind paid plans. This prevents a major misuse expectation and is exactly the kind of context annotations don't carry.

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, front-loaded with the purpose and then the availability/limitation constraint. Every sentence carries distinct information with no padding; only minor gains possible.

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?

With an output schema present (no need to describe returns), full parameter coverage, and safety annotations, the description's job is to cover the gaps — which it does by flagging the paid-plan requirement and the fact it doesn't return acórdãos. Adequate and near-complete for a single-parameter informational 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 100% and the single parameter already documents itself ('Resumo do caso. Não é lido nem armazenado; não inclua dados pessoais'). The description adds no further parameter semantics, so the baseline of 3 applies.

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 (buscar jurisprudência) and immediately clarifies the surprising scope limitation: it does NOT return acórdãos, it only informs how to access the search. This is far more than restating the name, and it lets an agent distinguish it from what the name superficially implies.

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 description gives a precondition ('Disponível nos planos pagos') and clarifies the tool's limited output, which implies usage context. However, it never states explicitly when to use this versus consulting the actual search, nor when not to call it, leaving the routing to inference.

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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the exact skip rules (weekends, national holidays, the Dec 20–Jan 20 recess) and the caveat that it is only an estimate excluding local holidays and court suspensions.

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 sentences, front-loaded with the core function and legal basis, followed by the accuracy caveat. Every clause earns its place and nothing is repeated from the schema.

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?

With an output schema present, returns need not be explained, and the annotations cover the safety profile. The description supplies the counting rules and limitation disclosures an agent needs to interpret results correctly, leaving only minor gaps such as how the estimate surfaces in the output.

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 adds meaning beyond the schema by explaining the counting regime that governs the 'contagem' parameter (business vs calendar days, statutory suspension window) and the legal reference for 'diaDoComeco' not being counted, which the schema only partially conveys.

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 (estima/calcula) and resource (data final de um prazo processual civil), with the legal grounding (arts. 219, 220 e 224 do CPC). This clearly distinguishes it from every sibling, which are all lookups/validators rather than a deadline calculator.

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 description makes the use context clear: computing a procedural deadline in business days or calendar days. It also sets expectations by declaring what it will not cover (local holidays, court-ordered suspensions), which guides correct usage. It does not name an explicit alternative, but no sibling tool competes for this task.

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?

Annotations already declare readOnlyHint and openWorldHint, so the bar is lower, yet the description still adds real behavioral context: it discloses that party names are omitted and that a high-demand response should be retried once after a short wait. It does not describe pagination or rate limits beyond that single retry hint.

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 sentences, zero filler, with the core purpose and scope limitation front-loaded and the routing/retry guidance following. Every clause 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?

With an output schema present, return-value detail is not required, and the description still flags the key output caveat (no party names) plus the retry protocol for a one-parameter read tool. Slightly incomplete only in that it does not mention any output shape constraints beyond that caveat.

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 100% and the single parameter already documents the CNJ format with or without punctuation. The description adds nothing about the parameter, so the baseline 3 applies since the schema does all the work.

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 o andamento processual público de um número CNJ') and immediately bounds the scope by noting it does not return party names. It also distinguishes itself from the sibling buscar_jurisprudencia by routing jurisprudence queries there.

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 names the alternative for jurisprudence ('para jurisprudência, use buscar_jurisprudencia') and gives retry guidance for the high-demand case. It does not, however, address when to reach for decodificar_numero_cnj or validar_cpf_cnpj, so routing is only partially covered.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond them by stating it does not consult case progress, telling the agent the result is derived purely from the number rather than fetched state.

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 states the validate-and-explain behavior with the scope-limiting clause positioned to prevent misuse. Every element earns its place with no redundancy.

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, and the description covers inputs, behavior, and the non-consultation scope. It is essentially complete for a single-parameter decoder, with only the explicit sibling routing omitted.

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 100% and the single parameter's CNJ format is fully documented in the schema. The description mentions the decoded parts but adds no format or syntax detail for the input beyond what the schema already provides, so the baseline of 3 applies.

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?

Names a specific verb-and-resource pair (validates a CNJ process number and explains its parts) and enumerates exactly what is decoded (year, segment, court, origin). The closing clause 'sem consultar o andamento' cleanly carves it away from the sibling consultar_processo.

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 phrase 'sem consultar o andamento' gives a clear usage boundary against the consultar_processo sibling, implying this tool is for structural decoding only. It stops short of naming the alternative tool explicitly or stating a positive 'use this when' trigger, so it is clear context rather than full when/when-not routing.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds that this is a purely local, format-only validation with no external data retrieval, and that alphanumeric CNPJ is supported. That is meaningful context beyond the annotations, though it does not cover error behavior for malformed input.

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 sentences, no filler, and the core action is front-loaded with the scope caveat immediately after. Every clause carries information an agent needs.

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 single-parameter, read-only validation tool with an output schema that already defines the return shape, the description supplies everything needed: what is validated, what input variants are accepted, and what the tool does not do. Nothing material 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 100% and the single parameter already documents accepted formats (11-digit CPF, 14-character alphanumeric CNPJ, with or without punctuation). The description repeats the CPF/CNPJ distinction without adding new syntax or format guidance, so the baseline of 3 applies.

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 precise verb+resource: it verifies the check digits of a CPF/CNPJ, including the alphanumeric CNPJ variant. It also delimits scope by clarifying that no holder data is consulted, which separates it from lookup-style tools. It does not name or contrast any sibling tool explicitly, so it lands at 4 rather than 5.

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 clause "Não consulta nenhum dado sobre o titular" functions as a when-not guide, steering the agent away from using this for data enrichment or holder lookups. It gives clear context for the tool's narrow purpose but names no alternative tool for the cases it excludes.

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