mcp-juridico-brasil

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

With no annotations provided, the description carries the behavioral burden. It adds meaningful context by revealing the tool consults the public DataJud API, covers 91 tribunals, and becomes slower when no tribunal is specified. It does not disclose potential failure modes, rate limits, or authentication expectations, but for a read-style public API lookup the disclosed context is reasonably helpful.

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 description is compact and front-loaded. The first sentence states the purpose, the second describes the data source and return contents, and the third gives relevant scope coverage. Every sentence contributes useful information with 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?

Given that an output schema exists and the input schema fully documents both parameters, the description is largely complete for direct invocation. It covers data source, scope, and return categories, though it does not provide explicit sibling-routing guidance or failure/error expectations.

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 both parameters. The description reinforces the CNJ-number concept but adds no parameter-level meaning beyond what the schema provides, such as format requirements or the performance implication of omitting tribunal.

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: 'Busca os dados de um processo judicial pelo número CNJ' and enumerates the returned data (metadados, classe, assuntos, órgão julgador, partes, movimentações). It is clear, but it does not explicitly differentiate this tool from closely related siblings such as listar_movimentacoes, which may also expose movement data.

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 tool is used to look up process data by CNJ number and provides useful operational guidance about the slower search when tribunal is omitted. However, it never states when to prefer this tool over alternatives like listar_movimentacoes or resumir_andamento, nor does it mention exclusions or complementary use.

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 behavioral burden. It discloses the key calculation behavior: business days, next-day start term, and judicial recess suspension from 20 Dec to 20 Jan. It does not describe fallback behavior or errors, but the core behavior is explicit and non-destructive.

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 with the core purpose front-loaded and the legal details compactly presented. Every phrase contributes value and 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?

The description is complete for a calculation tool: it states the legal rules, the calendar scope, and the calculation behavior. The input schema thoroughly documents all parameters, and an output schema exists, so return values do not need to be explained in the description.

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. The description adds legal context but does not provide parameter-level semantics beyond what the schema already documents for uf, tipo_ato, tribunal, and data_intimacao_iso.

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 names a specific verb and object: 'Calcula o próximo prazo processual em dias úteis com calendário forense.' It also cites the exact CPC articles implemented, clearly distinguishing it from sibling tools such as buscar_processo_por_numero and listar_movimentacoes.

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 intended use obvious: calculate a procedural deadline using business days and forensic-calendar rules. It does not explicitly list exclusions or alternative tools, but none of the sibling tools appear to offer the same deadline-calculation function.

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 are provided, so the description carries full burden. It discloses critical behaviors: dry-run mode by default, requirement for explicit confirmation, irreversibility, starts legal deadline, returns simulation if safety conditions not met. All behavioral traits are transparently stated.

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 description is well-structured with ASCII art and bullet points, front-loading the risk and purpose. It is longer than average, but every sentence is informative. Minor room for trimming, but the thoroughness is justified by the high-risk nature.

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 the tool's complexity (high-risk, double gate, auth requirements), the description covers all necessities: use case, prerequisites, safety mechanism, output behavior (simulation vs real), and irreversibility. It is complete without needing output schema details.

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%, yet the description adds significant value: 'confirmar' parameter is tied to the safety gate and operator awareness, 'id_intimacao' notes it comes from a sibling tool, and 'numero_processo' shows an example CNJ format. This goes well beyond the schema's brief 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 clearly states the tool confirms reading a judicial summons (intimação) via DJe, with specific verb ('confirmar') and resource ('leitura de intimação'). It distinguishes itself from siblings like 'listar_intimacoes' by emphasizing the irreversible legal effect, making its purpose unique and clear.

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 provides explicit guidance on when to use (confirming reading, with operator awareness of legal effect) and when not (for viewing only). It details prerequisites (environment variables) and the double safety gate, including that without 'confirmar=True' and the environment variable, only a simulation runs. This covers exclusions and alternatives implicitly.

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 provided, the description carries the behavioral disclosure burden. It explicitly states 'Operação SOMENTE LEITURA - sem efeito jurídico', discloses that secret-justice intimações have suppressed content, and lists required credentials. It does not cover pagination or error handling, but the disclosed traits are meaningful and not redundant.

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 description is front-loaded with the main purpose and read-only safety notice, followed by return behavior and a compact bulleted credential list. There is no redundant or filler text, and each sentence contributes essential 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?

The description is complete for an agent to invoke the tool correctly: it explains the operation's read-only nature, the credential requirements, the filtering context, and the secret-justice special case. Since an output schema exists and the input schema is fully documented, nothing critical 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%, so all three parameters (limite, numero_processo, apenas_pendentes) are already documented with defaults and examples. The description does not add parameter-level semantics beyond the schema, though it adds useful environment-variable context for authentication. A baseline 3 is appropriate.

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: 'Lista comunicações processuais do Domicílio Judicial Eletrônico (DJe)', and clarifies the scope by enumerating intimações, citações e notificações. The focus on DJe communications and the read-only qualifier make it distinguishable from siblings like listar_movimentacoes and confirmar_leitura_intimacao.

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 clearly conveys that this is the read-only listing operation for DJe communications and specifies the required credential environment variables. It does not explicitly state when to prefer an alternative or when not to use this tool, so it falls short of a 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the output fields, ordering, and the performance rationale for the required tribunal parameter. However, it does not mention failure modes, pagination beyond the limit parameter, or any other side effects, though none seem likely for a read-only listing 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 description is two short sentences, front-loaded with the main purpose and followed by a concise statement of the return format and ordering. There is no fluff, and every sentence 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?

For a simple listing tool with three parameters, complete schema coverage, and an output schema, the description is largely sufficient. It explains what is returned and the ordering. The only gap is the lack of explicit behavior around errors or edge cases, but these are less critical given the low complexity and read-only nature of the 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 is already documented in the input schema. The tool description adds context about what is returned but does not add additional meaning to the parameters themselves. A baseline of 3 is appropriate when the schema already provides complete parameter documentation.

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 clear verb ('Lista') and a specific resource ('movimentações de um processo judicial'), and goes on to specify the returned fields and ordering. It does not explicitly differentiate from siblings like listar_intimacoes or resumir_andamento, but the resource is unambiguous enough that an agent can tell what the tool does.

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 intended use is implied by the description: list recent movements for a judicial process. However, there is no explicit guidance on when to choose this tool over alternatives such as resumir_andamento or listar_intimacoes, nor any mention of exclusions or prerequisites. The tribunal parameter note adds a performance constraint but not usage 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?

With no annotations provided, the description carries the behavioral burden. It discloses the in-memory, session-scoped nature and exactly what the tool returns (numbers list and total), making it evident that this is a read-only listing 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?

The description is compact and informative, with the key scoping information front-loaded. However, the first two sentences largely restate the same idea ('Lista processos com snapshot' vs 'Retorna os números... snapshot salvo'), introducing minor 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?

For a zero-parameter listing tool with an output schema, the description is fully sufficient. It explains what the tool does, what it returns, and how to obtain full snapshot data, leaving no critical gap for correct invocation.

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 input schema has 0 parameters, so the baseline is 4. The description adds no parameter syntax, but none is needed; it still clarifies the output shape the agent should expect.

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 ('Lista') and resource ('processos com snapshot em memória na sessão atual'). It clearly distinguishes itself from siblings like monitorar_processo by narrowing the scope to session-scoped saved snapshots and pointing to the processo://resource for full data.

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 clearly defines its context: a session-limited listing of snapshots. The instruction to use the processo://{numero}/snapshot resource for full data provides a useful boundary, though it does not explicitly name alternative tools or state when not to use this tool.

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?

There are no annotations, so the description carries the behavioral disclosure burden. 'Lista' implies a read-only operation, and the description explicitly states it returns siglas usable downstream, clarifying the main behavioral and output contract. It does not mention pagination, ordering, or side effects, but for a simple zero-parameter enumeration tool this is sufficient.

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 description is two short sentences with no redundant content. It front-loads the core purpose (listing supported tribunals) and then explains the practical value of the return values. Every sentence 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?

For a simple zero-parameter list operation with an output schema available, the description fully covers what the tool does and why it matters. It states the total count, the output content (siglas), and the relationship to other tools' parameters. Nothing essential 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?

The tool has zero parameters, so the baseline is 4. There is no parameter description needed, and the description adds relevant context by explaining that the returned siglas feed into the 'tribunal' parameter of other tools, which is more useful than simply noting there are no inputs.

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 ('Lista') with a clear resource ('todos os tribunais suportados pelo MCP') and adds a precise scope detail (91 total). It also states what the tool returns and how that output is used, making it clearly distinct from the many other 'listar_*' sibling tools.

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 clearly indicates the tool's purpose: to provide valid court acronyms for the 'tribunal' parameter of other tools. This implies when an agent needs to know supported tribunals before calling other tools, this is the one to use. It does not explicitly state when not to use it or mention alternatives, but no competitors exist among the siblings.

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 of behavioral disclosure. It usefully states that this is a polling implementation with no real-time guarantee and that a push notification phase is planned. However, it does not cover failure modes, rate limits, or an explicit read-only guarantee.

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 description is two sentences, front-loaded with the main behavior and followed by a concise implementation note. Every sentence earns its place and there is no redundant 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 a simple check-oriented tool with fully documented parameters and an output schema, the description is mostly complete. It could be stronger on when to use alternatives and edge-case behavior, but the core invocation context, including the polling/no-real-time caveat, is covered.

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 input schema already documents all three parameters, including ISO format and CNJ format requirements. The description adds little beyond the phrase 'após a data informada', but the schema does the heavy lifting, so the baseline score of 3 is appropriate.

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 clearly states the action and resource: it checks whether a process had an update after a given date. This is specific enough to understand the core function, but it does not explicitly differentiate from siblings such as executar_monitoramento_em_lote or listar_movimentacoes.

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 tool to determine whether a process was updated after a date. The mention of polling via DataJud without real-time capability is useful context, but the description does not explicitly say when to prefer alternatives like executar_monitoramento_em_lote or listar_movimentacoes.

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 are provided, so the description carries the full burden. It clearly signals read-only behavior with verbs like 'Retorna', 'busca', and 'devolve', and usefully discloses that the output includes instructions and that the MCP does not perform semantic summarization. It does not discuss side effects, permissions, or rate limits, but the read-only nature is evident.

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 description is compact and front-loaded, with the core purpose in the first sentence and operational context plus the crucial MCP/model boundary in the following sentences. Every sentence earns its place; 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?

Given the simple parameter set, full schema descriptions, and the presence of an output schema, the description is complete enough for correct invocation. It states the data source, what is returned, and explicitly clarifies that summary generation is the model's responsibility, preventing a common misconception.

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 input schema already provides 100% parameter coverage, including CNJ format for numero_processo and the tribunal default behavior, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already states.

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 clearly identifies the operation: retrieving structured process data from DataJud for LLM-generated summaries. It distinguishes itself by stating that semantic summarization is intentionally left to the model, not the MCP, which separates it from raw-data-fetching or drafting siblings. However, it does not explicitly name sibling tools or exclusion criteria, so it falls just short of a 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?

Usage is implied: the agent should use this tool when it needs to produce a natural-language case summary, since the description says the data is returned 'para geração de resumo pelo LLM'. Yet there is no explicit when-to-use/when-not-to-use guidance and no reference to alternatives like buscar_processo_por_numero for raw process data.

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