Legal MCP (alternativa ao Jusbrasil)

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

The description discloses behavioral traits beyond annotations, such as the option to call without args to get a login link, and the distinction between permanent (config) and session-only (paste) authentication. No contradictions with annotations (idempotentHint=true is 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 concise (three sentences) and front-loaded with the tool's purpose. 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?

For a simple authentication tool with no output schema, the description covers the main behaviors and usage contexts. It could mention error handling or response format, but overall it is 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?

Schema coverage is 0%, but the description adds meaning by explaining the 'token' parameter: it expects a JWT token and describes how to obtain it. This compensates well for the lack of 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 clearly states the tool's purpose: authentication for MCP.AI IDE agents. It uses specific verbs ('log in', 'authenticate') and distinguishes from sibling tools, which are all about legal, business, or document processing functions.

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 the tool (for authentication) and explains the two methods (permanent config vs session-only paste). It recommends the best practice without excluding alternatives, but lacks explicit 'when not to use' 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 (readOnlyHint, idempotentHint, destructiveHint) already indicate safe read operation. Description adds value by specifying it's free and listing returned data fields, aligning with 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?

Single sentence with bullet-like list, efficient but could be more structured. Front-loads purpose. 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?

For a simple tool with one parameter and no output schema, the description covers purpose, data fields, and usage context (free, before searching processes). Provides enough for an agent to decide when and how to use it.

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 'cnpj' is a string with no schema description or format guidance. Description does not clarify expected format (e.g., digits only, punctuation). Schema coverage is 0%, so description should compensate but does not.

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 verb 'Consulta' and resource 'CNPJ', listing specific data fields (razão social, nome fantasia, situação cadastral, etc.). It distinguishes from sibling tools like cnpj_processos and legal_dossie by focusing on cadastral 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 states utility: 'Útil pra identificar a empresa e seus sócios antes de buscar processos', implying a common workflow with cnpj_processos. No explicit 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=true, idempotentHint=true, and destructiveHint=false. Description adds 'grátis' and 'com número de processo completo' but does not contradict annotations. Adequate given annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with core purpose, zero waste. Each sentence adds unique information: main action, result, and follow-up suggestion.

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 two-parameter tool with no output schema, description covers the what, source (DJEN), optionality (incluir_socios), and next steps. Could mention return format (list of process numbers?) but adequate overall.

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 compensates by linking 'cnpj' to resolution of CNPJ to name/partners, and 'incluir_socios' to optional partner process inclusion. Adds meaning beyond schema names, though could specify format or defaults.

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 resolves CNPJ to company name and partners, then searches for processes by name in DJEN. Distinct from sibling tools like cnpj_consultar (likely just CNPJ lookup) and processos_buscar_por_nome (process search alone). Specific verb+resource+scope.

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?

Implied usage for discovering processes from a CNPJ. Suggests complementary use with datajud tools. No explicit when-not-to-use or alternatives despite sibling tools like processos_buscar_por_nome being available.

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 read-only, idempotent behavior. The description adds useful context about conditional responses (authenticated vs missing credentials), aligning with annotations and providing 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?

Two sentences efficiently convey purpose and key behavioral differences. No extraneous text; front-loaded with the core function.

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?

Despite no output schema, the description fully explains the two possible response states (authenticated with empty pending vs connect_url). For a simple status tool, this is complete and actionable.

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 no parameters, the description correctly omits parameter details. Schema coverage is 100% (empty), and no additional param information is needed.

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 returns connection status and URLs, and details the response format for different states. It distinguishes itself from siblings like 'authenticate' by focusing on status rather than credential input.

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 to check connection status before other operations, but does not explicitly state when to avoid using it or provide alternatives. However, the context is clear enough for an 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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about being free, requiring a paid broker for name resolution without 'nome', and returning instructions if name is missing. 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 and front-loaded with the core action. The 'IMPORTANTE' note is effective. Slightly unstructured but no redundant information; 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?

The description covers the main purpose, dependencies, and fallback behavior. However, it lacks an explicit comparison to many similar sibling tools and does not mention output format. Given the complexity and number of siblings, more context 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?

With 0% schema description coverage, the description explains why 'nome' is important and the consequence of omitting it, adding meaning beyond the schema. However, it does not describe parameter formats (e.g., CPF with/without punctuation) or provide full detail for both 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 tool searches for a person's processes by CPF in the DJEN diary, with an emphasis on needing the 'nome' parameter. However, it does not explicitly differentiate from sibling tools like 'processos_buscar_por_nome' or 'cnpj_processos', though the CPF entry point implies uniqueness.

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 good guidance: recommends providing the 'nome' parameter, explains free usage, and notes the paid broker fallback. Lacks explicit 'when not to use' or direct comparisons to siblings, but gives sufficient context for correct 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=true and idempotentHint=true. The description adds the important behavioral trait that identity is not revealed, which is critical for privacy. However, it does not explain what 'broker of identity' means or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action, no unnecessary words. 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?

With one parameter and no output schema, the description covers the basic purpose but leaves gaps: no hint about the return value format (e.g., boolean, string), and 'broker of identity' is undefined. More context on output 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 description coverage is 0% and the description does not clarify the expected format of the 'cpf' parameter (e.g., with/without punctuation). The tool name implies it's a CPF number, but missing format guidance could lead to errors.

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 validates CPF check digits (mod 11) and checks for an identity broker, and distinguishes itself by noting it does not reveal the holder's identity. This is a specific verb-resource pair that differentiates from sibling tools like cpf_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?

No explicit guidance on when to use this tool versus alternatives. The context of CPF validation is implied but not compared to other CPF-related tools. An agent might infer it is for validation only, but clear when-to-use or when-not-to-use is absent.

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 read-only and non-destructive behavior. The description adds value by specifying that the output is a URL (not the PDF itself) and that the hash comes from a previous search, extending 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?

A single sentence that includes all essential information: action, resource, input, and origin of input. No unnecessary 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 tool with one required parameter, no output schema, and safety annotations, the description sufficiently covers what the tool does, the input needed, and the output format. It is complete for 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?

With 0% schema description coverage, the description compensates by explaining that the hash parameter should come from the search result's `hash` field, providing context beyond the schema's type-only definition.

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 (returns), resource (URL of certidão PDF), and input (hash). It distinguishes from siblings like djen_search_comunicacoes, which returns search results, not a specific document URL.

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 after a search by referencing the hash field from search results, but it does not explicitly state when to use or not use this tool, nor does it mention 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context: free, no captcha, covers only processes with Diário publication. No contradictions. Could mention pagination or rate limits, but not required.

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, front-loaded with key info in caps, no wasted words. Efficient and well-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?

No output schema, but description states return format: list of processes with parties and court. Covers scope limitations (only published processes). Mostly complete for a simple read operation.

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 explains the main required parameter (nome_parte) implicitly but does not describe optional parameters like pagination, date ranges, or tribunal filter. Adds minimal meaning 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?

The description clearly states the tool searches DJEN by party name and returns processes with parties and court. It distinguishes from siblings by noting it covers only published processes and directing CPF/CNPJ queries to processos_* 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?

Explicit guidance: use for party name searches; for CPF/CNPJ or dormant processes, use processos_* tools. Also suggests enriching results with datajud using the returned processo numbers.

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 the tool as read-only and idempotent. The description adds that each result includes the full text of the communication, which is useful beyond the annotations. However, it does not explain pagination behavior or result format, which is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, front-loaded with the core purpose. Efficient and well-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?

Given high complexity (12 parameters, no output schema, no param descriptions), the description only partially covers the parameter space and does not explain return values or pagination. The clarification about DJEN not being jurisprudence is helpful but insufficient for complete 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?

With 0% schema description coverage for 12 parameters, the description must compensate but only mentions 5 parameters (OAB, lawyer name, process number, court, date). Critical parameters like 'meio', 'texto', 'pagina', 'uf_oab', 'nome_parte', and 'itens_por_pagina' are not explained, leaving significant 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 states it searches publications/summons in the DJEN and explicitly distinguishes from jurisprudence/abstracts databases, differentiating it from sibling tools like jurisprudencia_buscar.

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 states it is not a jurisprudence database, guiding the agent against using it for case law queries. This provides clear when-not-to-use guidance relative to sibling 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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, making the tool's safety profile clear. The description adds value by specifying the scope (covers superior courts and others) and the fields returned (title, type, date, authority, summary, URL), which provides behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the purpose and return format. Every sentence adds value without redundancy. No unnecessary 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?

Given the tool's complexity (search with 3 params, no output schema), the description covers what it searches, what it returns, and filtering. However, it omits the 'max' parameter entirely and does not mention pagination, ordering, or error handling. This is adequate but incomplete.

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 3 parameters with 0% description coverage. The tool description explains 'termo' (search by term/tese) and 'tipo' (filter by type like Acórdão, Súmula), but fails to mention the 'max' parameter. Thus, it adds meaning for 2 out of 3 parameters, partially compensating for the lack of schema descriptions but leaving a gap.

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 'Busca' (searches) and the resource 'jurisprudência' (jurisprudence) within the public LexML collection. It specifies that it covers superior courts and others, and distinguishes itself from the sibling 'jurisprudencia_sumulas' which likely focuses on summaries only.

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 searching jurisprudence across multiple court levels with optional type filtering. It does not explicitly state when to use this tool versus alternatives like 'jurisprudencia_sumulas', but the context is clear enough. A more explicit exclusion or comparison would improve the score.

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 idempotentHint=true. The description adds the search scope (LexML) but no additional behavioral traits beyond what annotations provide. Adequate but minimal incremental value.

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, each serving a clear purpose: first states the core function, second clarifies it's a shortcut. No extraneous words, efficient and 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 search tool with no output schema, the description omits what the result contains (e.g., list of laws, citations). It is minimally complete given simple parameters and annotations, but could be richer.

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% and description provides no detail on parameters beyond implying 'termo' is used. The 'max' parameter is not mentioned at all, leaving the agent with no guidance on its semantics or constraints.

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 SÚMULAS (including binding) by term in LexML, and explicitly calls itself a shortcut of jurisprudencia_buscar with type=Súmula, distinguishing it from the general sibling.

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 this is a shortcut, implying use when only Súmulas are needed. It does not explicitly state when not to use it, but the context from sibling comparison is sufficient.

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, destructiveHint false. Description adds that it 'updates state and returns changes', which is consistent with internal bookkeeping. No 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?

Two succinct sentences, front-loaded with the main action, no wasted words. Bulk support noted efficiently.

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 core functionality and parameter usage. Lacks details on return format/behavior when no changes, but given no output schema, the explanation 'returns what changed' is adequate.

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; description explains watch_id for specific monitor, watch_ids for bulk, and that omitting checks all. Adds 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?

Description clearly states it checks for news in monitors, distinguishes from siblings like legal_listar_monitoramentos (listing) and legal_monitorar (monitoring setup). Mention of specific watch_id vs all adds specificity.

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 (immediate check) and how to target specific or all monitors. Does not explicitly exclude cases but context from siblings implies 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context: it returns a list of processes plus a warning, and explicitly warns that data may be incomplete or outdated. This goes beyond annotation defaults.

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 only four short sentences. It front-loads the purpose, then lists accepted inputs, describes the return structure, and adds a critical warning. Every sentence adds value without 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 11 undocumented parameters and no output schema, the description covers only the main input identifiers. It does not explain the optional boolean flags or the output format beyond 'list of processes + warning'. Users lacking local knowledge will be underinformed.

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 11 parameters with 0% description coverage. The description explains the main identifier parameters (nome, cnpj, cpf, numero_processo) but does not explain the other 7 parameters such as max_processos, incluir_socios, sigla_tribunal, etc. Many parameters remain opaque, requiring guesswork.

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: providing a legal X-ray of a person or company, discovering processes and optionally their progress in a consolidated report. It lists accepted identifiers. However, it does not explicitly differentiate from sibling tools like cpf_processos or cnpj_processos, which serve more specific purposes.

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 specifies that only one identifier should be used (nome, cnpj, cpf with nome_titular, or numero_processo). It also provides an important note about verifying data on the official court site. However, it does not give guidance on when to prefer this tool over siblings or 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the scope 'ativos' (active), but no further behavioral details beyond what annotations cover.

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, focused sentence with no extraneous words. Front-loaded of verb and resource. Perfect conciseness.

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 no parameters, the description is minimal. It states the tool lists active monitorings but does not describe the output format, pagination, or if any filtering is possible. Adequate but lacking detail for full 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?

There are no parameters. Baseline for 0 parameters is 4. The description is not required to explain parameters, and it doesn't.

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 directly states the verb 'Lista' (lists) and the resource 'monitoramentos ativos do workspace'. It clearly differentiates from sibling tools 'legal_monitorar' (create) and 'legal_remover_monitoramento' (remove) by specifying listing active monitorings.

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?

While not explicit about when not to use or alternatives, the description clearly implies this tool is for viewing active monitorings. Sibling names provide context, making usage straightforward.

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 explains the tool creates a monitoring that sends alerts via webhook. Annotations (readOnlyHint=false, destructiveHint=false) are consistent. No contradictions, but it could mention potential side effects like rate limits or data persistence.

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 covering purpose and delivery. No redundant information; every part 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?

Covers main monitoring types and alerting but does not explain all parameters (label, tribunal, interval) or what to do after creation (e.g., list, remove). Relies on sibling tools for completeness, but gaps remain for a standalone understanding.

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 description must compensate. It provides meaning for numero_processo, nome/cnpj, oab+uf but omits label, sigla_tribunal, and intervalo_horas. Partial semantic coverage, leaving some parameters unexplained.

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 creates a monitoring for legal news, specifying three types of triggers (new movement, new process, new publication). It contrasts with sibling legal_checar_novidades, making the purpose 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 explicitly indicates when to use this tool (to set up monitoring) and when to use the alternative (legal_checar_novidades for immediate checks). It also explains alert delivery via webhook.

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 are minimal (destructiveHint: false) and the description does not clarify behavioral traits beyond the action. It lacks details on side effects, authorization needs, whether the removal is reversible, or what happens to related data. The description carries the burden since annotations are sparse.

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: the first states the core action and identifier, the second adds bulk support. No unnecessary words, efficiently 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?

Given the tool's complexity (removal/deactivation), no output schema, and minimal annotations, the description is incomplete. It does not specify what happens on success, error cases, idempotency, or prerequisites (e.g., monitoring must exist). There are significant gaps for an agent to use it 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?

Input schema has 0% description coverage, so the description should compensate. It mentions 'watch_id' and 'watch_ids' but provides no format, constraints, or relationship between them (e.g., whether watch_id is ignored when watch_ids is used). The description adds little beyond the schema field names.

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 ('Remove (desativa)') and the resource ('um monitoramento') with the identifier 'watch_id'. It also mentions bulk support, and the tool name differentiates it from siblings like 'legal_monitorar' (create) and 'legal_listar_monitoramentos' (list).

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. The description implies its use for removal or deactivation but does not state prerequisites, when not to use it, or reference sibling tools for comparison.

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 important behaviors: invoke works even if MCP not installed, returns connect/checkout links for auth/payment, and one-off use without adding to toolkit. Annotations are consistent with description; 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?

The description is lengthy but each sentence adds value, covering multiple actions and flows. It is front-loaded with the main purpose, though could be more structured for readability.

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 (multiple actions, no output schema), the description provides comprehensive context: core flow, when to use each action, credential handling, billing, and notes on installed status. It is sufficient for an agent to select and 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 has 0% parameter description coverage. The description explains some parameters in context (action, tool_id, arguments, immediate) but does not detail all 13 parameters (e.g., limit, query, message, tier_slug, conversation, request_name, report_context, request_details). Partial compensation.

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 marketplace is the official catalog and runtime for MCPs, and lists specific actions (search, describe, invoke, install, etc.), distinguishing it from sibling tools which are individual MCPs or specific actions like report_bug.

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 this tool first before external registries, prefer invoke for one-off use, install for permanent addition, and notes that writes require workspace owner/admin. Also explains when to use each action and how to handle credentials/billing.

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 adds async behavior and identity resolution beyond annotations. Annotations already declare readOnlyHint=true, so no 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?

Description is short and front-loaded with key purpose. Could be more structured but 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?

Adequately explains async return but lacks parameter details and output schema info. For an async tool with one required param, somewhat complete but has 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 coverage is 0%. Description only explains the required 'documento' param implicitly. Does not describe 'platforms', 'tribunais', or 'max_results', leaving their meaning unclear.

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 discovery by CPF/CNPJ, resolving to names then searching. Distinguishes from sibling 'processos_buscar_por_nome' which searches directly by name.

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?

Explains when to use (having a document number) and async behavior with polling. Notes limitation that CPF/CNPJ are not public court keys. Not explicit about alternatives, but implied.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool scrapes public portals (ESAJ/PJe/eproc/Projudi), is asynchronous (returns job_id), and slow, providing behavioral traits beyond the annotations with 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?

The description is well-structured: starts with 'DESCOBERTA' label, then states purpose, async behavior, and follow-up steps. It is front-loaded with the most critical information. Could be slightly more concise, but overall effective.

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 4 parameters, no output schema, and rich annotations, the description covers the main purpose, async flow, result retrieval, and suggestions for further enrichment. It lacks full parameter details but is complete enough for a search/scraping tool with sibling 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?

With 0% schema description coverage, the burden on the description is high. It explains the required 'nome' parameter (search by name), and the scraping context hints at the 'platforms' parameter (which portals it covers). However, it does not explain 'tribunais' or 'max_results', leaving gaps. Adds some value 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?

The description clearly states the tool searches for legal processes by the name of a party (pessoa or empresa), using verb 'busca' and resource 'processos'. It differentiates from siblings by noting datajud only searches by number and djen by OAB/advogado, establishing a clear niche.

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 when datajud/djen cannot), that it is asynchronous and slow, how to retrieve results via processos_get_resultado, and recommends enriching obtained CNJ numbers with datajud_*/djen_*. Provides clear context and 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?

Annotations declare readOnly, idempotent, non-destructive. Description adds polling behavior (repeat until 'done'), partial progress, and slow speed, which annotations do not cover.

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 one line on bulk support, front-loaded with purpose. 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?

No output schema, but description fully explains return structure, status values, items content, and polling loop. Sufficient for a polling 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 description mentions job_id by context and job_ids for bulk support. Does not describe each parameter in detail but sufficient for understanding.

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 polls a job from processes_buscar_por_nome/documento, lists return fields and statuses, and distinguishes it from the search siblings.

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 tells when to use (after initiating search, poll until done) and mentions bulk support. Implicitly excludes initial search, but lacks explicit when-not to 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is known to be safe and non-destructive. The description adds value by stating that results include excerpts and a URL to the gazette, providing transparency on output format 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?

The description is concise (four sentences) and well-structured: purpose, use case, output details, and a tip. Every sentence adds essential information without redundancy or 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?

For a tool with 5 parameters and no output schema, the description is incomplete. It explains the output (excerpts + URL) and one parameter tip, but fails to document date range, territory filter, or size parameters. This leaves significant gaps for correct agent 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?

With 0% schema description coverage, the description should compensate. It only implicitly covers 'termo' (search term) and gives a usage tip about quotes. Parameters like size, data_inicio, data_fim, and territory_ids are completely undocumented, leaving agents without guidance on their meaning or 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 the tool searches in municipal official gazettes (milhares de prefeituras) by term/name. It specifies examples of use (licitações, nomeações, etc.) and explicitly distinguishes itself from the judicial DJEN tool, making its purpose and scope 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 explicitly says this tool complements DJEN (judicial), guiding when to use it (municipal gazettes) vs. the judicial alternative. It also provides a tip for exact searches using quotes. While not exhaustive for all siblings, the contrast with the most relevant sibling is clear and helpful.

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 non-read-only, non-destructive, and idempotent behavior. The description adds the reproduction hint but does not elaborate on what happens after reporting (e.g., storage, confirmation). It provides some value 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, front-loaded sentences with no redundant information. Every sentence carries necessary guidance.

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 purpose and what to include but lacks details on the context parameter and return behavior. For a simple tool with no output schema, it covers the essentials but leaves 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 has 0% parameter descriptions. The description only mentions the conversation parameter, leaving context and message underspecified. It adds partial meaning but insufficiently compensates for the lack of schema 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 clearly states the tool reports bugs, missing features, or feedback. It uses a specific verb and resource, and none of the sibling tools serve a similar purpose, ensuring clear 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?

The description instructs to include the conversation array for reproduction, providing clear context. It does not explicitly exclude scenarios or mention alternatives, but given the unique purpose, this is well-calibrated.

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, and destructiveHint=false. The description adds 'current' implying no side effects, but does not disclose additional behavioral traits 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?

The description is a single, front-loaded sentence with no extraneous words, perfectly concise for the tool's purpose.

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 version retrieval tool with no parameters and no output schema, the description is sufficient. It could optionally mention that it returns version strings, but the lack of output schema is compensated by the clear purpose.

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 zero parameters and schema description coverage is 100%, so the baseline is 4. The description does not need to add parameter information.

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 the specific verb 'show' and identifies the resource as 'current MCP platform and adapter versions', which is clear and distinguishes it from all sibling tools (none of which are version-related).

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 implies use when needing version info; although no explicit when-not or alternatives are given, the tool's simplicity and unique purpose among siblings make this acceptable.

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 description adds value by specifying exactly what state is returned. It does not contradict annotations and provides relevant behavioral details.

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 the returned data, no filler. Every word contributes 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 metadata tool with no parameters, the description is complete enough. It lacks output schema details but the description conveys the core information sufficiently for an agent to use 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?

No parameters exist, so baseline is 4. The description adds no parameter info because none is needed.

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 'Returns the current toolkit state' with specific details: installed MCPs, connection status, and catalog tool counts. It is a specific verb+resource that distinguishes this introspection tool from the many data-retrieval 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 implies usage for checking toolkit status, but does not explicitly state when to use or alternatives. However, the context of sibling tools makes it self-evident, so it is clear if not exhaustive.

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 adds context beyond annotations: specifies the tool returns function/organ/period. Annotations already declare readOnly, idempotent, non-destructive; description avoids contradictions and adds value.

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 purpose, 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 PEP check with one parameter and no output schema, description covers purpose and result type. Could benefit from describing output format (e.g., boolean or list) but sufficient for basic use.

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% coverage on cpf parameter. Description confirms CPF is the input but does not add format or validation hints (e.g., expected length or digits). Minimal added 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 verifies if a CPF belongs to a Politically Exposed Person (PEP) and returns function/organ/period, distinguishing it from siblings like cpf_validar or transparencia_sancoes.

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?

Mentions compliance/KYC context, implying when to use. However, it lacks explicit exclusionary guidance (e.g., when not to use) or alternatives among 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: it consolidates multiple databases, returns specific fields, and mentions the type of sanctions. There is 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, front-loaded with the action, and each sentence adds essential information (what, sources, returns). No unnecessary 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 query tool with one parameter, the description covers the purpose, data sources, and return format. Lacks error handling context, but overall 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?

Schema description coverage is 0%, so the description must compensate. It indicates the parameter takes CPF or CNPJ, which adds meaning beyond the schema's type-only specification. However, it lacks details on format or validation, 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 states the tool consults sanctions by CPF/CNPJ, lists the consolidated databases (CEIS, CNEP, CEPIM), and specifies the returned fields (tem_sancao + list with type, organ, rationale, dates). The use case 'Due diligence / compliance' further clarifies its purpose. This distinguishes it from sibling tools like transparencia_pep.

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 it versus alternatives (e.g., transparencia_pep). No when-not or exclusion criteria are provided.

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