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

With no annotations, the description carries the full behavioral burden. It does disclose the rich return content (full text, partes, advogados, tribunal link, certidão PDF) and the volume behavior of broad queries, but it never explicitly confirms read-only / side-effect-free behavior, rate limits, or pagination semantics — the remaining gaps are notable given zero annotation coverage.

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?

Three short paragraphs: purpose, return content, then the query constraint. The most important routing information is front-loaded and every sentence carries weight — no repetition of schema field descriptions.

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?

Given an 11-parameter tool with full schema descriptions and an output schema, the description covers purpose, output shape, and the key filtering constraint. The main missing piece is any confirmation of read-only behavior and pagination expectations, which matters because annotations are absent.

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, but the description adds meaning the schema does not: it groups which parameters actually function as search filters (OAB, advogado, parte, número do processo) and notes that tribunal and dates are legal but low-precision alone. That is useful semantic framing beyond the per-field descriptions.

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 specific verb and resource ('Busca publicações e intimações no DJEN') and clarifies the differentiator versus DataJud (only metadata). However, it never differentiates from the closest sibling, listar_intimacoes, so an agent has to infer which one to pick from the name alone.

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 final paragraph gives actionable query guidance ('Informe pelo menos um filtro: OAB, advogado, parte ou número do processo') and warns that tribunal+dates alone return 'volume enorme', which steers the agent toward effective usage. It stops short of explicitly naming alternate tools or exclusions, but the when/how guidance is concrete.

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?

With no annotations, the description carries the full burden and does well: it discloses the upstream public API, that parties are NOT available from DataJud, that DJEN supplementation is best-effort ('quando houver'), and the 92-tribunal coverage scope. It omits error/not-found behavior and any rate-limit or latency expectations, which keeps it short of a 5.

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 short paragraphs, front-loaded with the core action and followed by source, limitation, and coverage. Each sentence contributes distinct information 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?

For a 3-parameter lookup with an output schema present, the description covers source, return shape, data limitations, and tribunal coverage. Only failure modes (invalid CNJ number, unsupported tribunal) are unaddressed.

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, but the description adds real meaning beyond the schema for incluir_partes_djen: it explains that parties may be absent because they come from DJEN publications, which the schema text does not convey.

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 ('Busca os dados de um processo judicial pelo número CNJ') and immediately names the source (DataJud) and the returned contents (metadados, classe, assuntos, órgão julgador, instâncias, movimentações). An agent can distinguish it from siblings like listar_movimentacoes or buscar_comunicacoes_djen without opening the schema.

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 implies the use case (retrieve full process data by CNJ number) and explains the incluir_partes_djen condition, but never names an alternative tool or an explicit when-not-to-use case, leaving 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?

With no annotations at all, the description carries the full burden and it does disclose genuinely useful behavior: the legal rules applied (art. 219 úteis, art. 224 termo inicial, art. 220 recesso 20/dez–20/jan). It does not state that omitting data_intimacao_iso triggers an external DataJud lookup, nor anything about failure modes when the process or tribunal calendar is unavailable.

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 core capability is front-loaded in the first sentence, with the legal basis enumerated compactly afterward. Every line earns its place; the only minor cost is that the statutory citations are terse enough that an agent gets the rule names but not the resulting counting semantics.

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 and the input schema is fully documented, so return-value explanation is not needed. The description covers the calculation basis well; the remaining gap is operational context — the implicit DataJud dependency and what happens when the deadline computation cannot be resolved — for a tool with five parameters and external calendar rules.

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%, so the schema already documents every parameter including the fallback behavior of uf, tipo_ato and data_intimacao_iso. The description adds no parameter-level meaning beyond what the schema provides; baseline 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?

The description opens with a specific verb and resource: 'Calcula o próximo prazo processual em dias úteis com calendário forense.' That is unambiguous and clearly separates it from the retrieval-oriented siblings (buscar_processo_por_numero, listar_movimentacoes, etc.), none of which perform deadline computation, 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 implied by the tool's nature — an agent needing a deadline date will reach for this — but there is no explicit when-to-use/when-not-to-use guidance, no statement of prerequisites (e.g., a process must exist in DataJud), and no routing advice relative to siblings such as listar_intimacoes.

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?

With no annotations supplied, the description carries the full burden and delivers: it discloses that the action registers official ciência with a CNJ timestamp, STARTS the procedural deadline clock, and cannot be undone via API. It further documents the dry-run default and the two-condition safety gate plus required OAuth credentials, which is exactly the behavioral detail an agent needs before invoking an irreversible operation.

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?

Content is front-loaded with purpose, then risk, then gate conditions, then credentials, which is the right order for a dangerous write. The boxed ASCII banner consumes significant vertical space for three bullet points, which is heavier formatting than necessary, though each line still carries distinct, decision-relevant information.

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 irreversible, credential-gated mutation the description covers effect, reversibility, gating, defaults and required environment variables; an output schema exists so return-value detail is correctly omitted. Nothing an agent needs to avoid an accidental legal filing is absent.

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%, so the baseline is 3 and the schema already explains confirmar, id_intimacao and numero_processo in detail. The description reinforces the confirmar gate and adds credential/audit context (DJE_BEHALF_OF_CPF), but adds no new per-parameter format or semantics beyond what the schema properties state.

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 specific verb+resource: 'Confirma a leitura de uma intimação no Domicílio Judicial Eletrônico', which is unmistakably distinct from sibling listing tools like listar_intimacoes and buscar_comunicacoes_djen. An agent knows exactly what action is being taken and against which system.

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 states precisely when the call has real effect (confirmar=True plus DJE_PERMITIR_CONFIRMACAO_LEITURA=true) and that otherwise it returns a safe simulation, which is strong conditional guidance. It also points to listar_intimacoes as the source of id_intimacao. What is missing is explicit when-not-to-use advice, e.g. verifying the intimação is the intended one before confirming.

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?

With no annotations supplied, the description carries the full load and does well: it declares read-only operation with no legal effect, discloses that secret-of-justice items have suppressed content with metadata only, and lists the required OAuth2 credential env vars including the audit CPF. It omits pagination/rate-limit behavior for the limite parameter.

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?

Front-loads the resource and the read-only guarantee, then the return content and redaction caveat, then credentials. The credential block is a few lines of boilerplate but genuinely needed since no annotations exist to convey auth requirements.

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 shape need not be explained, and the description covers the remaining decisions an agent faces: read-only safety, secret-of-justice redaction, auth prerequisites, and default filtering. Only pagination behavior is left unaddressed.

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 parameter meaning is already fully documented there, giving a baseline of 3. The description adds only indirect context — that results are scoped to the CNPJ/CPF in DJE_BEHALF_OF_CPF, an env var rather than a parameter — and nothing about how limite interacts with 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?

States a specific verb and resource ("Lista comunicações processuais do Domicílio Judicial Eletrônico") and enumerates what types are returned (intimações, citações, notificações). It does not differentiate itself from the close siblings buscar_comunicacoes_djen or processos_por_parte_djen, so purpose is clear but sibling routing is absent.

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?

Implies the tool's context (listing DJe communications for the registered CPF/CNPJ) but never states when to prefer it over buscar_comunicacoes_djen or how it relates to confirmar_leitura_intimacao. Usage must be inferred from the sibling names.

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?

With no annotations, the description carries the full behavioral burden; it does disclose that results are aggregated across all instances and sorted newest-to-oldest, which is genuinely useful context. It does not state that the operation is read-only, whether any access restrictions apply, or how pagination/truncation behaves beyond what the schema and output schema already say.

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, front-loaded with the purpose and followed by the returned fields and ordering. No filler, no repetition of the tool title.

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 simple three-parameter read with full schema coverage and an output schema, the description covers what the tool does and the shape/ordering of results. The one remaining gap is a lack of explicit differentiation from adjacent tools that also surface case information.

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%, including the rationale for the required tribunal and the 20-default/50-max limit, so the structured field already does the heavy lifting. The description adds no parameter-level meaning beyond the schema, making the baseline 3 correct.

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 (listar movimentações de um processo judicial) and adds scope detail: it merges all instances (G1, G2) and orders newest-first. It stops short of naming a sibling it is not (e.g., resumir_andamento or listar_intimacoes), so an agent must infer the boundary itself.

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 by the purpose – 'list recent movements' suggests consulting a case history, but there is no explicit when-to-use/when-not guidance or routing to alternatives like resumir_andamento or listar_intimacoes. No prerequisites or exclusions are stated.

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?

With no annotations, the description carries the burden and does disclose key traits: results come from snapshots persisted in memory and disk, and the payload is limited to process numbers rather than full data. It does not address ordering, volume limits, or whether listed processes include those no longer monitored.

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?

Three short sentences with the primary behavior front-loaded, then the return shape, then the pointer to the resource for detail. Nothing is repeated and no sentence is 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 a zero-parameter list tool with an output schema, the description covers the essentials: what is listed, what comes back, and where to get details. Minor gaps remain around result ordering and whether the list reflects only actively monitored processes.

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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly implies the call needs no input and returns an unfiltered set of process numbers.

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 states a specific verb and a scoped resource: it lists only processes that have a saved snapshot, and clarifies the return is process numbers. This implicitly separates it from broader siblings like buscar_processo_por_numero or listar_movimentacoes, 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?

It gives a useful follow-up rule (use resource processo://{numero}/snapshot for full data), which tells the agent what to do next. However, it never states when to call this instead of monitorar_processo or buscar_processo_por_numero, so selection guidance is only implied.

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?

With no annotations, the description still discloses that the list is a complete fixed catalog (92 entries) held by the MCP, implying no filtering, pagination, or side effects. It does not explicitly state that the call is read-only or static/cacheable, which would have closed the remaining gap.

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, front-loaded with what is returned, then immediately the practical consequence. Nothing is redundant or padded.

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 zero-parameter catalog tool with an output schema that already defines the return shape, the description covers purpose, cardinality, and downstream usage. An agent has everything needed to call it correctly and interpret the result.

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?

The tool takes zero parameters, so the baseline is 4. The description usefully characterizes the output values as valid inputs for the 'tribunal' parameter elsewhere, which is extra semantic value not present in the empty input schema.

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 gives a specific verb and resource ('Lista as siglas de tribunais') plus the exact cardinality (92), which lets an agent recognize this as the enumeration/lookup tool rather than a search tool. It is clearly distinguishable from all listed siblings, none of which return reference codes.

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 states the practical use: the returned siglas feed the 'tribunal' parameter of the other tools, which tells the agent to call this first when a court code is unknown. It does not spell out when not to call it (e.g. when the sigla is already known) or name a specific alternative, so it falls short of a full 5.

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?

With no annotations present, the description carries the full burden, and it does disclose two genuinely useful traits: the data comes from DataJud and results are not real-time (polling), with a planned move to push notifications. It says nothing about rate limits, authorization needs, or cost of repeated calls, which matter for a polling tool.

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 core purpose is front-loaded in a single clear sentence, and the follow-up lines are short. The Fase 2 / Fase 3 roadmap sentences are partly engineering-facing, but they do convey the non-real-time behavior, so they are not pure waste.

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 simple three-parameter read tool with a fully described schema and an output schema that explains the return shape, the description covers what the tool does and how fresh the data is. The remaining gap is what exactly constitutes an 'atualização', which would help the agent interpret results.

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%, so each of the three parameters is already documented in the schema. The description adds only the notion of a reference date ('após a data informada'), which loosely maps to desde_iso, but provides no format, timezone, or matching semantics beyond the schema's ISO 8601 note.

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 states a specific verb and resource: it checks whether a given process (processo) had an update after a supplied reference date. This is distinct enough from the sibling names, but it never contrasts itself with close siblings like listar_movimentacoes or buscar_processo_por_numero, so the agent must infer when this check is the right call.

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 implied by the check semantics and the note that this is polling-based with no real-time behavior, which tells the agent it must call repeatedly rather than expect a subscription. However, no alternative tools are named and no conditions for preferring this over listing movements directly are given.

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?

With no annotations, the description carries the behavioral burden and does disclose the key trait: results are limited to cases that appeared in DJEN publications, with sigilosos and pre-DJEN cases excluded, and output grouped by process number. It does not discuss cost/latency of scanning pages or whether matching is fuzzy or exact.

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?

Three short sentences, front-loaded with the core action and immediately followed by the mechanism (busca por publicações, agrupamento por número) and the disclaimer. No filler or redundant restatement of the title.

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 explained, and the main caveat about DJEN coverage is disclosed. Minor gaps remain around match precision and the effect of max_paginas on recall, which matter for a scan-based search 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%, so each parameter (nome_parte, tribunal, datas, max_paginas) is already documented. The description only reinforces that the search is by nome and does not add format or matching semantics beyond the schema, so the baseline 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 and resource — finding a person's or company's lawsuits — and names the search key (nome da parte) and data source (publicações do DJEN), which implicitly separates it from number-based sibling buscar_processo_por_numero and from buscas de comunicações como buscar_comunicacoes_djen.

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?

Gives explicit when-not conditions: it does not cover processos sem publicação no DJEN, sigilosos ou anteriores ao DJEN. It lacks a direct pointer to the alternative sibling (e.g., buscar_processo_por_numero when the number is already known), so guidance is strong but not complete.

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?

No annotations exist, so the description carries the full behavioral burden. It does disclose two valuable traits: it queries DataJud as an external source, and its output contains prompt instructions aimed at the LLM rather than a finished summary. It does not state that the operation is read-only, nor what happens on DataJud lookup failure or when the process number is not found.

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?

Three short sentences, front-loaded with the core behavior and followed by the one non-obvious contract (summarization happens in the model, not the MCP). Slight redundancy between the first two sentences, but 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?

An output schema exists, so return values need not be explained. The description supplies the one thing an agent could not infer: the response is data plus summarization instructions rather than a ready summary. Only error and availability behavior is left uncovered, which is a minor gap for a two-parameter read 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%, so both parameters (numero_processo in CNJ format, optional tribunal) are already documented in the schema. The description adds no format, default, or fallback details beyond that, 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?

The description uses a specific verb and resource ('Retorna dados estruturados de um processo') and adds a crucial scope clarification: this tool does not produce the summary itself, it returns data formatted with instructions so the model can generate it. That distinguishes it meaningfully from siblings like buscar_processo_por_numero, though it never names that sibling 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 implied: call this when you need the underlying data to write a summary of a process. The statement that semantic processing 'fica no modelo, não no MCP' implicitly tells the agent it must do the summarization step itself. However, there is no explicit when/when-not guidance nor a named alternative such as buscar_processo_por_numero, which returns process data for other purposes.

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