Legal MCP (alternativa ao Jusbrasil)

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

Annotations already indicate idempotentHint=true and non-destructive. Description adds context about browser login and token handling, which is useful beyond annotations. No contradictions.

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 sentences covering purpose and usage, front-loaded. Could be slightly more structured but wastes no words.

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?

Covers main flows but does not describe response format or error cases. Without output schema, more detail on what 'get the link' returns would improve completeness.

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 only defines 'token' as optional string. Description explains its role (session login with JWT) and the alternative of no args to get a link. Fully compensates for 0% schema coverage.

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's purpose: authentication via token. It distinguishes itself from sibling tools (all data lookup tools) by focusing on login functionality.

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 explicit guidance on two usage scenarios: permanent config setup and session-only token paste, with clear instructions for each. No alternatives mentioned but the context is well defined.

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, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds specifics on returned data but not additional behaviors like rate limits or auth—adequate but not extra.

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 well-structured sentences. Front-loaded with core function, then lists returned fields and a usage hint. No wasted words.

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 lookup with one parameter, it adequately describes purpose, return data, and context. Missing parameter format details slightly reduces completeness, but overall sufficient.

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?

Only one parameter (cnpj) with 0% schema description coverage. The description does not specify input format (e.g., with/without punctuation) or validation rules, leaving the agent without guidance beyond the 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 clearly states it consults CNPJ registration data, listing specific fields returned (razão social, nome fantasia, etc.). It distinguishes from sibling tools like cnpj_processos by focusing on the cadastral query.

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 suggests using this before searching for processes (Útil pra identificar a empresa e seus sócios antes de buscar processos). Does not compare to other siblings or give when-not-to-use, but context is clear.

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 destructiveHint, so the description adds value by explaining the resolution and search steps. It could mention limitations like invalid CNPJ handling, but overall consistent.

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 a single dense sentence that packs key information. It is front-loaded with the action, though slightly verbose. Could be broken into two sentences for clarity.

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 no output schema and low param coverage, the description provides a good overview of functionality and usage flow. It does not specify return format or pagination, but is adequate for a 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 coverage is 0%, but the description implicitly covers both parameters: 'resolve o CNPJ' for cnpj and 'opcionalmente inclui os processos dos sócios' for incluir_socios, adding meaning beyond the bare 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 clearly states it resolves CNPJ to company name and partners, then searches for processes by name in the Diário (DJEN). It distinguishes from siblings like cnpj_consultar and processos_buscar_por_documento.

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 indicates the tool is free and provides complete process numbers, with a suggestion to enrich with datajud tools. It does not explicitly list alternatives or exclusions, but context is clear.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context by explaining the two distinct output scenarios (authenticated vs missing credentials), which helps the agent understand what to expect without contradicting 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?

The description is two sentences with no wasted words. It front-loads the core purpose ('Returns connection status and URLs') and then succinctly explains the two output cases. Every sentence is necessary and clear.

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 no parameters and no output schema, the description covers the main output states (authenticated vs missing credentials) adequately. It could mention additional edge cases (e.g., partial connection), but the simplicity of the tool makes this sufficient.

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?

There are no parameters (0), so schema coverage is 100% by default. The baseline is 4, and the description does not need to add parameter information. It provides no param-specific guidance, but none is required.

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 that the tool returns connection status and URLs, with specific output variants for connected vs missing credentials. This uses a specific verb+resource and distinguishes itself from siblings like 'authenticate' by focusing on status checking.

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 implicitly suggests use for checking connection status by describing output cases, but does not explicitly state when to use this tool versus alternatives like 'authenticate'. No when-not or exclusion criteria are provided, leaving some ambiguity for the agent.

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?

Discloses key behavioral traits beyond annotations: the tool is free but depends on name resolution, and without a name and paid broker it returns instructions. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent and description adds valuable context.

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 concise with three sentences, front-loaded with the main action. However, the use of all caps and slight verbosity could be streamlined without losing clarity.

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?

Covers usage conditions well but lacks description of return values (what the tool outputs on success). Without an output schema, the agent needs to know the structure of returned processes. Also, no differentiation from siblings is provided.

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?

With 0% schema description coverage, the description fully compensates by explaining the role of each parameter: 'cpf' is the identifier, 'nome' is recommended to resolve CPF to name, and why it is important. This adds significant meaning beyond the 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 clearly states the tool searches for legal processes by CPF using the person's name in DJEN, and emphasizes it is free. It distinguishes from CNPJ-based tools, but does not explicitly differentiate from similar siblings like 'djen_processos_por_parte'.

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 explicit guidance: use the 'nome' parameter when possible, explains failure modes (broker dependency) and fallback behavior. However, it lacks comparison to other search tools in the sibling list.

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 idempotentHint. The description adds valuable context: it does not reveal the CPF holder's identity, which is an important privacy guarantee. It also mentions that it checks for an available identity broker, disclosing a non-obvious behavior beyond validation.

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 extremely concise: two sentences that front-load the primary action and immediately add a critical behavioral note. There is no superfluous text; every word 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?

Given the tool's simplicity (one parameter, no output schema), the description lacks important context: expected input format (e.g., '12345678909' vs '123.456.789-09'), what the identity broker is, and what the response looks like. It covers the core purpose but leaves agents uncertain about practical usage.

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% parameter description coverage, and the description only implies that the 'cpf' parameter is a CPF string. No format hints (e.g., whether digits only or with punctuation) are provided, which is essential for correct usage. The description does not compensate adequately for the missing schema details.

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 that the tool validates CPF check digits (mod 11) and informs about identity broker availability, distinguishing it from sibling tools like 'cpf_processos' which likely deal with legal processes. The verb and resource are specific and the additional feature (broker info) adds clarity.

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?

No explicit guidance on when to use this tool versus alternatives such as 'cpf_processos' or 'authenticate'. Usage is implied from the purpose, but there is no mention of prerequisites, context, or typical scenarios, leaving the agent to infer without support.

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 readOnly and idempotent. Description adds that it returns a URL to a PDF, providing some behavioral context beyond 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?

Single sentence, front-loaded with key info, no fluff.

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?

Adequate for a simple retrieval tool with one parameter and no output schema; covers input source and return type.

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?

Only parameter 'hash' has 0% schema description coverage; description explains it's the hash from the search, adding crucial meaning.

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?

Description clearly states the tool returns the URL of a PDF certificate for a DJEN communication using the hash, distinguishing it from sibling search 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?

Explicitly links the hash to the search result field, guiding the agent to use it after a search. No exclusions but context is clear.

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?

As anotações já declaram readOnly, idempotente e não-destrutiva; a descrição soma contexto valioso: cobertura apenas de publicações no Diário a partir de 2020, semântica do count_processos 0, bloco ausencia, e caráter grátis/sem captcha. Não há contradição com as anotações.

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 descrição é densa mas sem desperdício: propósito, escopo, limitação, alternativa e próximo passo em poucas frases. A informação mais importante vem primeiro e cada oração adiciona valor operacional.

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?

Apesar de não haver output schema e o esquema de entrada ter 0% de descrição, a descrição explica o formato do retorno (lista, count_processos, bloco ausencia) e as limitações. Ainda assim, não documenta os parâmetros opcionais de paginação/filtro, o que a impede de ser totalmente completa para um chamada avançada.

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?

Com cobertura do esquema em 0%, a descrição precisa compensar, mas só dá semântica ao parâmetro nome_parte ('busca por NOME de parte'). Os demais parâmetros (pagina, data_inicio, sigla_tribunal, itens_por_pagina) não são explicados nem no esquema nem na descrição. O valor agregado além do esquema é mínimo para a maoria dos parâmetros.

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?

A descrição abre com verbo específico e recurso ('DESCOBERTA por NOME de parte') e define o retorno (lista de processos agrupados por número, com partes e tribunal). Ela também diferencia a ferramenta de alternativas ao dizer que entrada por CPF/CNPJ ou processos dormentes deve usar as tools processos_*.

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?

A descrição é explícita sobre quando usar: busca pelo nome, grátis e sem captcha. Ela também dá condição de não-uso: para CPF/CNPJ ou processos dormentes, usar processos_*. Ainda orienta o próximo passo ('enriqueça com datajud') e aler ta sobre falso-negativo com count_processos 0.

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 readOnly, idempotent, and non-destructive behavior. The description adds substantial value beyond that: coverage starts in 2020 and varies per tribunal, empty results return an `ausencia` block with possible reasons, and each returned item contains the full communication text. No contradiction with 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?

The description is dense but well-organized: purpose first, then item content, then important caveats and empty-result behavior. Every sentence contributes meaning, and nothing is repeated 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 read-only search tool with no output schema, it is unusually complete: it covers scope, coverage limits, empty-result structure, and how to confirm absence of a process. It falls just short of full completeness because several input parameters remain under-specified and the non-empty result structure is only outlined, not detailed.

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?

With schema_description_coverage at 0%, the description must compensate for the schema. It explains the main semantic filter dimensions (OAB, lawyer, process number, tribunal, date) but does not clarify parameters like `meio`, `texto`, `pagina`, `nome_parte`, or `itens_por_pagina`. Partially helpful, but with clear gaps.

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/intimações no DJEN') and lists concrete filter dimensions: OAB, lawyer name, process number, tribunal, and date. It also explicitly distinguishes this tool from jurisprudence/ementa databases and process registries, clearly separating it from siblings like jurisprudencia_buscar and processos_buscar_por_nome.

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 states when to use the tool (search published DJEN communications by the given criteria), when not to use it (not for jurisprudence, not a process registry), and names an alternative (datajud_get_processo) for historical confirmation when results are empty. This is explicit and actionable routing guidance.

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 indicate readOnly, idempotent, and non-destructive behavior. The description adds substantial behavioral context beyond that: null fields mean absence of information in the source, not a defect; zero results do not prove non-existence and are often due to vocabulary or over-narrow filters; and full texts are accessible via jurisprudencia_documento. These are exactly the kind of non-obvious behaviors an agent needs to interpret results correctly.

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 a single dense paragraph with no filler; every sentence adds information. It front-loads the main purpose and return structure before caveats. It is slightly long but each clause earns its place, so it remains appropriately sized and structured.

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 tool with seven parameters and no output schema, the description covers a lot: return fields, full-text access, null semantics, broad-search behavior, and zero-result interpretation. Missing explanations for date ranges, 'tipo', and 'max' are the main gaps, but the most critical usage contexts are addressed.

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 carries the burden of explaining parameters. It explains 'termo' ('por termo ou tese') and 'tribunais' ('para restringir a busca; sem isso a pesquisa é ampla'), but it does not explain 'tipo', 'data_de', 'data_ate', 'ordenar', or 'max'. An agent would have to guess their meanings or formats, which is a significant gap given the parameter count.

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 clear verb and resource: 'Busca jurisprudência (acórdãos, súmulas, orientações jurisprudenciais, temas) por termo ou tese.' It lists what each returned record contains and explicitly distinguishes itself from jurisprudencia_documento by explaining that full texts are read through that sibling. This gives an agent a precise understanding of what the tool does and how it differs from related 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 tells the agent when to use jurisprudencia_documento instead: when a record has 'texto_integral_disponivel: true'. It also advises to inform 'tribunais' to narrow the search and warns that an unfiltered search is broad. It does not explicitly contrast with jurisprudencia_sumulas, but the main routing guidance is present.

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?

As annotations já cobrem readOnly, idempotência e não-destrutividade. A descrição adiciona contexto valioso: retorna o texto completo, exige disponibilidade de inteiro teor, e expõe onde encontrar outras decisões do processo. Poderia detalhar erros ou formato de retorno, mas as annotations reduzem a barra.

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?

O texto é enxuto e bem estruturado: a frase principal aparece primeiro, seguida de instruções de uso e do suporte a lote. Cada sentença cumpre uma função e não há repetição do que já está nas annotations.

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?

Sem output schema e com quatro parâmetros sem descrição no schema, a definição deveria cobrir mais. Ela informa o retorno principal e a listagem de outras decisões, mas deixa indefinidos o parâmetro tribunal, a relação exata entre id, ids e numeracao, e o comportamento quando nenhum argumento é passado.

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?

Com cobertura de schema em 0%, a descrição precisaria compensar mais. Ela explica bem os parâmetros id e ids e alude ao número CNJ, mas não nomeia nem esclarece o papel de numeracao e tribunal, nem as combinações ou obrigatoriedade entre parâmetros. A compensação é apenas parcial.

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?

A descrição começa com verbo e recurso específicos: 'Lê o INTEIRO TEOR de uma decisão (texto completo do acórdão, não o resumo)'. Isso distingue claramente o propósito do sibling jurisprudencia_buscar, que trabalha com resumos, e deixa evidente o que a ferramenta faz.

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?

Há orientação explícita de quando usar: fornecer o id vindo de jurisprudencia_buscar com texto_integral_disponivel:true ou usar o número CNJ. Também informa o fallback: resultado sem id não é legível nesta ferramenta, devendo-se abrir a url. A nota sobre múltiplas decisões completa o cenário de uso.

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, idempotentHint, and destructiveHint. The description adds value beyond those by explaining that full enunciado text appears in the ementa when available and that canceled/revoked enunciados are marked in the text itself. This is useful behavioral context not present in the structured fields.

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: three sentences, each earning its place. The main purpose is front-loaded, the sibling relationship is explicit, and the behavioral note is concise. Minor structure loss because there is no section separation, but overall it is efficient.

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 no output schema and zero parameter descriptions, the description must carry the full context burden. It explains one result nuance (ementa text and revocation marking) but does not describe the response shape, pagination, max behavior, or what happens when full text is unavailable. The tool is simple, but key operational details are 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 0%, so the description must compensate for the bare schema. It only clarifies 'termo' indirectly through 'por termo' and says nothing about 'max' — its behavior, default, or limits. This leaves the optional parameter essentially undocumented from the agent's perspective.

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 action and resource: 'Busca SÚMULAS (incluindo vinculantes) por termo'. It also identifies itself as a specialized shortcut of jurisprudencia_buscar with a fixed tipo=Súmula, which clearly distinguishes it from the sibling search tool.

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 explicitly positions the tool as 'Atalho do jurisprudencia_buscar com tipo=Súmula', giving the agent a clear cue for when to select it. It does not spell out when not to use it, but the context is strong enough to guide correct selection.

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?

While annotations declare readOnlyHint=true, the description states 'Atualiza o estado' (updates state), which contradicts the read-only claim. The description adds bulk support info but fails to resolve this inconsistency, leading to misleading behavioral expectations.

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 plus a line for bulk support, all front-loaded with key actions. No redundancy; every sentence adds value.

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?

No output schema, and the description only says 'returns what changed', which is vague. Prerequisites (e.g., existing monitors) are implied but not stated. Overall adequate but not complete for a new user.

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 has 0% description coverage, but the description explains 'watch_id' for specific and 'watch_ids' for batch, adding significant meaning. It does not detail parameter format or constraints, but coverage is adequate.

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 checks for novelties in monitoring immediately, distinguishing from the automatic cycle. It specifies usage for a specific watch_id or all monitors. Among siblings like 'legal_listar_monitoramentos' and 'legal_monitorar', this tool's purpose is distinct.

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 indicates when to use (immediate check) and how to pass parameters (specific or all), but does not explicitly contrast with siblings or provide when-not-to-use scenarios. Usage context is clear but lacks explicit alternatives.

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?

The description adds value beyond annotations by warning that data may be incomplete/outdated and advising confirmation on official court websites. Annotations already indicate read-only, idempotent behavior, so the description's caveat about data quality provides useful behavioral context.

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 concise (3 sentences) and well-structured: purpose first, then accepted inputs, return format, and a warning. Every sentence adds value, and no filler is present.

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 explains the main input options and return format (list of processes with number, parties, court) and includes a quality warning. However, with 11 parameters and no output schema, it leaves several parameters unexplained and does not detail the output structure beyond a list and warning. Moderate completeness.

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 description only explains 5 of 11 parameters (nome, cnpj, cpf, nome_titular, numero_processo), with schema description coverage at 0%. Parameters like max_processos, incluir_socios, sigla_tribunal are left undocumented, requiring the agent to infer from names. This is insufficient given the schema's lack of 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 provides a legal X-ray of a person or company, discovering lawsuits and optionally progress. It specifies accepted identifiers (name, CPF, CNPJ, or case number) and the return format. However, it does not explicitly differentiate from sibling tools like cpf_processos or processos_buscar_por_documento, which have overlapping functionality.

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 instructs to provide only one identifier ('informe APENAS um') but offers no guidance on when to use this tool versus alternatives (e.g., for CPF-specific queries). There is no mention of prerequisites or context-specific use cases, leaving the agent to infer usage.

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 idempotentHint, so the safety profile is known. The description adds no extra behavioral context, such as what 'monitoramentos' entails or any potential side effects, leaving the agent with minimal additional insight.

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 very concise with one sentence, but it could be more informative without being verbose. It is front-loaded but lacks substance like explaining what a 'monitoramento' is or the output format.

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 lack of an output schema, the description should explain what the tool returns (e.g., a list of monitoring IDs or names). It fails to do so, leaving the agent uncertain about the output's structure. The context of 'monitoramentos ativos' is minimally explained.

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?

There are no parameters, and schema coverage is 100%. The description does not need to add parameter information, and the baseline score of 4 is appropriate since the schema already handles everything about parameters.

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 verb 'Lista' and the resource 'os monitoramentos ativos do workspace', making it clear what the tool does. However, it does not differentiate from sibling tools that list other types of data, like 'processos_buscar_por_nome' or 'djen_search_comunicacoes', but within the context of monitoring it is specific.

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 no guidance on when to use this tool versus alternatives, such as using 'legal_checar_novidades' to check for updates, or when not to use it. The context is implied by the tool's purpose but not explicitly 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?

Description discloses that the tool creates a monitoring that sends alerts via webhook, adding behavioral context beyond annotations. It does not contradict annotations (readOnlyHint=false, destructiveHint=false). No hidden effects are missing.

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 purpose, but dense. Could be slightly more concise, but 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?

Covers three monitoring types and webhook event, but omits description of several parameters (label, sigla_tribunal, intervalo_horas) and doesn't mention that monitors can be listed/removed. Not fully complete for an 8-parameter 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?

Despite 0% schema coverage, the description explains the monitoring criteria (numero_processo, nome/cnpj, oab+uf) but does not cover all parameters like label, sigla_tribunal, intervalo_horas. Some meaning added, but incomplete.

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?

Description clearly states it creates a monitoring for new movements, processes, or publications, using specific parameters. It distinguishes itself from sibling tools like legal_checar_novidades (check immediately) and legal_listar_monitoramentos (list monitors).

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 says when to use this tool (to set up monitoring) and when to use legal_checar_novidades (to check immediately). Also describes how alerts are delivered (via webhook event). Provides clear context for usage.

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 indicate non-destructive and non-read-only behavior. The description adds that bulk support is available, but does not elaborate on side effects, permissions, or reversibility.

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, no unnecessary words. The action and key parameters are front-loaded, making it efficient for an AI agent to parse.

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 removal tool, the description covers the basic functionality. However, it lacks information about return values or error handling, which is not required but would improve completeness. The existing annotations and sibling context partially compensate.

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%, but the description explains 'watch_id' as the monitoring ID and mentions bulk support via 'watch_ids'. This adds meaning beyond the raw schema, but lacks detailed descriptions for each parameter.

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 of removing/deactivating a monitoring by its ID, and the name reinforces this. It distinguishes from siblings like 'legal_listar_monitoramentos' and 'legal_monitorar', which are listing and creating, respectively.

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?

No explicit guidance on when to use this tool versus alternatives. No mention of prerequisites or context for when to choose it over other monitoring tools.

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?

The description discloses key behaviors beyond annotations: 'invoke works even when the MCP is NOT installed — it runs the tool pontualmente, without adding the MCP to the toolkit,' 'Writes (install/uninstall/subscribe/cancel and the one-off install behind invoke) require workspace owner/admin,' and explains what happens when credentials are needed or wallet is empty. This is far richer than the minimal annotation hints.

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 long but information-dense, with every sentence adding meaningful context. It is structured around a core flow and then expands to edge cases and the prompt library. While it could benefit from bullet points, the front-loaded purpose and organized content make it easy to navigate.

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 high complexity (15 actions, 23 params, no output schema), the description covers the main flows, auth/billing behavior, and prompt library well. However, some actions like 'resume' and 'list_tools' are only mentioned, not explained, and return shapes for core actions like search/describe are omitted. It is a strong but not exhaustive effort.

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?

With 0% schema coverage, the description must compensate and largely does: it explains the meaning of the action parameter ('action=search discovers MCPs by intent → describe returns one MCP's full profile... invoke RUNS that tool'), and mentions mcp_id, tool_id, and prompt_* parameters in context. However, many parameters like limit, query, immediate, tier_slug, and conversation are not explicitly explained, leaving some ambiguity.

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 tool as 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It specifies the core flow (search → describe → invoke) and the tool's role in discovering and running MCPs, distinguishing it from sibling tools which are specific MCPs.

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 offers explicit guidance on when to use each action: 'prefer invoke for a single/occasional use,' 'Use install only to make an MCP PERMANENT in the active toolkit,' and explains when to use search vs describe vs invoke. It also notes write permission requirements and how to handle auth/payment links.

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?

The description discloses behavior not present in the annotations: CPF/CNPJ are not public court search keys, the service maps CNPJ→razão social automatically, CPF requires the caller to provide nome_titular, and the operation is asynchronous returning { job_id }. These are substantive behavioral traits beyond readOnlyHint/idempotentHint/destructiveHint, and there is no contradiction with 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?

The description is dense but every sentence carries critical information: what the tool does, the name-resolution caveat, the required nome_titular condition, the alternative tool, and the asynchronous polling flow. Key constraints are front-loaded and explicitly marked.

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 job-submission tool with no output schema, the description covers the core lifecycle: input, precondition, async response, and follow-up polling. It is slightly incomplete because the optional scoping parameters (platforms, tribunais, max_results) are not explained and the eventual result payload from processos_get_resultado is not previewed, but the most decision-relevant context is present.

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 schema has 0% property description coverage, so the description must compensate. It does explain the two least obvious parameters—documento as CPF/CNPJ and nome_titular as mandatory for CPF—but it leaves platforms, tribunais, and max_results semantically undiscussed beyond their names and enum/type. This is partial compensation, not full.

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: 'DESCOBERTA por CPF ou CNPJ' and clearly explains the actual behavior—resolving the document to name(s) and searching by name. It also distinguishes itself from the sibling tool by stating the CPF-nome limitation and pointing to processos_buscar_por_nome as the alternative.

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 states exactly when to use this tool (when you have a CPF/CNPJ), what precondition applies (CPF requires nome_titular), and explicitly names the alternative for the case where the CPF holder's name is unknown: 'Sem o nome do titular do CPF, use processos_buscar_por_nome.' It also gives the follow-up action: poll with processos_get_resultado(job_id).

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?

Discloses asynchronous, slow operation, scraping behavior, and job_id return pattern. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent; description adds context beyond annotations without contradiction.

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 sentences, each adding value: purpose and differentiators, async behavior, enrichment suggestion. No wasted words, front-loaded with key 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?

Covers async behavior and integration with other tools, but lacks details on parameters beyond nome. For a tool with 4 params and no output schema, the description is sufficient for basic understanding but incomplete for full correct invocation without further schema info.

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 description must compensate. Only 'nome' is explained (search by name), but 'platforms', 'tribunais', and 'max_results' are not described at all. The description leaves significant ambiguity about optional parameters.

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?

Clearly states the tool searches for legal processes by party name (pessoa or empresa) scraping public court portals. Explicitly distinguishes from siblings datajud (by number) and djen (by OAB/lawyer), fulfilling specific verb+resource and sibling differentiation.

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 states when to use (search by name, covering a gap not met by datajud or djen) and how to use it asynchronously (call processos_get_resultado for results). Provides clear context and alternative tools.

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 mark the tool as readOnly, idempotent, and non-destructive. The description goes well beyond annotations by explaining polling behavior, status transitions, degraded 'done' responses, the meaning of vinculacao_nome 'nao_confirmada', and the interpretation of tribunais_inacessiveis. This is rich behavioral context that an agent cannot infer from the schema or annotations alone.

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?

Though dense, every sentence carries operational value. It front-loads the core purpose, states the return structure, gives the polling loop, and then provides essential data-quality warnings. No filler is present, and the structure moves naturally from basic behavior to critical caveats.

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?

There is no output schema, so the description correctly explains the response fields, statuses, and item contents. It also covers the most important safety caveats around degraded results. The main gaps are the undocumented job_ids parameter and the lack of guidance for what to do on status 'error' instead of only 'done'.

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 undocumented parameters, but it does not. It never explains job_id vs job_ids, whether job_ids is a batch alternative, how the required job_id is obtained, or how parameters affect polling. The generic phrase 'de um job de busca' is the only hint, which is insufficient for two parameters with zero schema 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: 'Polling de um job de busca' and explicitly ties the tool to processos_buscar_por_nome/documento. It clearly describes what the tool returns and distinguishes it from the search tools themselves, so an agent can understand its role without confusion.

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 clear operational guidance: 'Continue chamando até done' and 'a busca é lenta', which tells the agent when and how often to call. It also warns about degraded 'done' results and when not to present data confidently. However, it does not explicitly state when not to use the tool or mention any alternative polling mechanism, though the source-tool reference makes the intended context clear.

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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds significant value beyond these: it discloses that the tool is ASYNCHRONOUS (returns job_id requiring polling), returns TEMPORARY links that expire (nothing is archived), and notes empty list for processes without public decisions. It also clarifies it's a read-only fetch of public data per CNJ Res. 121/2010. The only minor gap is not detailing auth/captcha specifics beyond a passing mention.

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 dense but well-organized: it leads with the core action, then scope limitations, then async behavior and return format, then input sourcing and edge case. Every sentence adds value. Slightly long but for a complex async tool it's justifiable; each 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?

For a complex async tool with 4 parameters, 0% schema coverage, and no output schema, the description does substantial work: it covers the async pattern, return payload shape (markdown/pdf_url/expires_at), the polling sibling tool, the CNJ legal scope, and the empty-result edge case. Missing: no explicit explanation of peca_ids and tribunal parameters, and no detail on error cases beyond empty results. Strong but not perfect.

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 carry the full burden for parameters. The description explains numero_cnj (source: processos_get_resultado/datajud) and formato (markdown/pdf implied by conversion to Markdown). However, peca_ids (array) and tribunal are not explicitly explained anywhere in the description. Despite a strong description, these two parameters remain undocumented.

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 downloads public decisions (acórdãos/inteiro teor) from a legal process, converts PDF to Markdown, and returns the decision text with a temporary link. It's very specific about verb (DOWNLOAD/busca/baixa/converte), resource (decisões públicas de um processo), and clearly distinguishes from siblings by stating it does NOT return full case files. The term 'processos_obter_pecas' is made concrete.

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 states when to use (for public decisions), when NOT to use (petitions/documents require lawyer credential), and mentions the polling pattern with processos_get_resultado(job_id). It also specifies the async nature (captcha per search), and guides on using numero_cnj from processos_get_resultado/datajud. This is exceptionally thorough for usage guidance.

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 indicate readOnly, idempotent, non-destructive. The description adds that it searches municipal gazettes (scope) and returns excerpts/URLs (output format). No contradictions; provides useful behavioral context beyond 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?

Two concise sentences, front-loaded with the main action, include examples and a usage tip. No wasted words.

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 adequately covers purpose and output format (excerpts + URL), but lacks parameter explanations for 4 of 5 parameters. With no output schema, more detail on response fields would improve completeness.

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 has 5 parameters with 0% description coverage. The description only explains 'termo' (required) and suggests using quotes. It does not explain 'size', 'data_fim', 'data_inicio', or 'territory_ids', leaving significant gaps.

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 searches municipal official gazettes for terms/names, provides concrete examples (bids, appointments, contracts, sanctions), and distinguishes it from DJEN (judicial). It also notes output includes excerpts and URLs.

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 context: useful for non-judicial mentions, complements DJEN. It advises using quotes for exact names. However, it does not explicitly compare to other sibling tools like 'processos_buscar_por_nome' or state when not to use it.

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 indicate this is not read-only, not destructive, and idempotent. The description adds one behavioral hint (include conversation) but does not explain what happens after submission or other behavioral traits. No contradiction with 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?

The description is two sentences long, front-loading the purpose and then providing a key usage instruction. Every sentence is necessary and no words are wasted.

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 simplicity and lack of output schema, the description covers the main purpose and one parameter. However, it does not state what the user can expect after submission (e.g., confirmation or response), which would enhance completeness.

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. It adds meaning for the 'conversation' parameter ('include... with recent messages') but does not clarify 'context' or 'message' beyond their names. The value added is partial.

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's purpose: 'Report a bug, missing feature, or send feedback.' It uses a specific verb ('report') and resource ('bug/feedback'), which distinguishes it from the sibling tools that focus on legal and CPF/CNPJ queries.

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 explicitly instructs to 'Include the conversation array with recent messages for reproduction,' which guides usage. However, it does not provide when-not-to-use or alternative tools, though among siblings this is the only feedback tool, making it reasonably clear.

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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds minimal context (specifics about what versions are shown), but does not contradict 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?

Single sentence, no fluff. Front-loaded with the action 'Show' and concise resource description.

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 read-only tool with no output schema, the description is sufficient. It fully explains what the tool does without needing additional context.

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?

No parameters exist, and schema coverage is 100%. The description adds value by specifying that it shows 'platform and adapter versions', clarifying the output beyond 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?

Description clearly states it shows current MCP platform and adapter versions, using a specific verb 'show' and resource 'versions'. No sibling tool has a similar purpose.

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?

No explicit guidance on when to use this tool vs alternatives. Usage is implied by its simple nature, but no context or exclusions are provided.

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, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds value by detailing what information is returned (installed MCPs, connection status, accounts, catalog tool counts), but does not disclose any additional behavioral traits such as network calls or potential delays. This is acceptable given the simple read-only nature.

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 a single, information-dense sentence that is front-loaded with the primary action ('Returns the current toolkit state') and efficiently lists the returned components. Every word adds value, with no unnecessary 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 tool is simple, has no parameters, and the annotations cover safety. The description enumerates all return categories, which suffices for understanding the tool's purpose and output. It does not mention edge cases like error handling or latency, but these are not critical for such a straightforward 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?

The tool has zero parameters and the schema coverage is 100% (vacuously). According to the rubric, a 0-parameter tool receives a baseline of 4. The description correctly need not explain any parameters, as there are none to document.

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's purpose with a specific verb ('Returns') and a specific resource ('current toolkit state'), enumerating the exact contents: installed MCPs, connection status, connected accounts, and catalog tool counts. This makes it unambiguous and distinguishes it from sibling tools like authenticate or search 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 implies the tool is for informational purposes but does not explicitly state when to use it versus alternatives. No exclusions or alternative tool references are provided, so the usage context is inferred rather than 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safety is known. The description adds context about scope (Federal Executive only) but no additional behavioral traits 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?

Description is concise, front-loads main purpose, and provides key details in a few sentences without redundancy. Could be slightly more structured but overall efficient.

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?

Description lists returned fields and distinguishes from sibling, but lacks explanation of pagination and ordering parameters. Adequate for core functionality but missing some context for full usage.

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 description partially compensates by explaining cpf_cnpj, ano, and fase (with default). However, 'pagina' and 'ordenacao' parameters are not mentioned, leaving gaps.

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 it lists expense documents (empenho, liquidação, pagamento) for a beneficiary, item-by-item, and distinguishes from the sibling tool for total aggregated 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?

Explicitly mentions default phase value and directs to sibling tool for aggregate totals, providing clear usage context. Does not elaborate on when not to use, but the alternative is clearly 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?

Annotations already mark the tool as read-only and non-destructive. The description adds valuable behavioral context: it sums received resources, breaks down by payer and month, and defaults to the last 12 months if no dates are provided. No contradictions with 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?

The description is a single paragraph with no wasted words. It front-loads the main purpose, then adds scope and default behavior efficiently. Every sentence adds distinct value.

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 read-only query tool with three parameters and no output schema, the description provides complete guidance: it explains the output structure (summed by payer and month), the default time range, and the federal scope. This is sufficient for an agent to invoke correctly.

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 0%, so the description must compensate. It mentions CPF/CNPJ and optional dates, and explains default date behavior. However, it does not specify the required format for CPF/CNPJ (e.g., digits only) or date formats (e.g., YYYY-MM), leaving some ambiguity for the agent.

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 retrieves total expenses received by a person or company from the Federal Government, broken down by paying body and month. It distinguishes itself by focusing on aggregated amounts and explicitly ruling out state/municipal coverage, making its purpose unambiguous.

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 explains when to use (for Federal Executive expenses) and notes default behavior (last 12 months without dates). However, it does not explicitly mention when not to use or compare with sibling tools like transparencia_despesas_documentos, missing an opportunity to guide selection.

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 indicate the tool is read-only and idempotent. The description adds that it returns function/organ/period, but does not address error handling or what happens if the CPF is not found. This is adequate but not comprehensive.

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 very concise with two sentences, no unnecessary words, and the most important information is front-loaded.

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 single-parameter tool with no output schema, the description covers the purpose and return fields. It lacks details on response structure and error cases, but is mostly complete given the tool's simplicity.

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 schema has 0% description coverage, so the description must compensate. It mentions CPF but provides no format details (e.g., digits only or punctuation). This leaves the agent uncertain about input formatting.

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 checks if a CPF is a Politically Exposed Person and returns function/organ/period. However, it does not explicitly distinguish it from similar tools like 'cpf_validar', which validates CPF format, leaving some ambiguity.

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 mentions 'Important for compliance/KYC', providing clear context for use. It does not specify when not to use it or offer alternatives, but the use case is well-defined.

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, idempotentHint, and destructiveHint. The description adds value by specifying the return structure (tem_sancao + list with tipo, órgão, fundamentação, datas) and the consolidated sources (CEIS, CNEP, CEPIM). No contradictions with 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?

The description is concise, using two sentences to convey purpose, data sources, and return information. Every sentence adds value 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?

Given one required parameter and no output schema, the description adequately explains the return structure and data sources. However, it lacks details on error handling, pagination, or format constraints for the parameter, leaving minor gaps.

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%. The description does not add any meaning beyond the schema, such as expected format for CPF/CNPJ (e.g., 11 or 14 digits) or validation rules. This is a gap for correct parameter usage.

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 it queries sanctions for a person/company by CPF/CNPJ from the Transparency Portal, consolidating multiple sanction lists. It specifies the return fields and context (due diligence/compliance), distinguishing it from sibling tools that handle other queries like CNPJ consultation or CPF validation.

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 usage for due diligence/compliance but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria for when not to use it. No explicit guidance is given.

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