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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds that it queries official pePI data and requires an internal CodPedido, but it does not discuss auth, rate limits, or the optional local file-writing behavior beyond what the parameter schema explains.

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 focused paragraphs: the first states what detail is returned, and the second gives the critical ID prerequisite. The field enumeration earns its space by setting expectations, and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description summarizes the returned content: Nice classes, owners, legal representative, deposit/grant/validity dates, unionist priority, and petition history. Optional save/update behavior is covered by the input schema, so the main context is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the optional flags are already documented. The description adds critical meaning for cod_pedido: it comes from a specific search-result field and is an internal pePI ID, not the public process number.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Busca') and resource ('detalhe completo de um processo de marca'), enumerates the returned data, and distinguishes itself from search siblings by requiring a CodPedido from prior search results rather than the public process number.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a strong prerequisite: cod_pedido must come from a previous search, and it is not the public process number. It does not explicitly name the alternative sibling to use when only the public process number is available, but the routing 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?

The description discloses key behaviors: no own cache, pagination of the last session search, and automatic live re-send if the previous search was cached. It also details optional side effects for salvar_html and salvar_evidencia. However, the readOnlyHint annotation contradicts the file-writing side effects, and error/rate-limit behavior is not covered.

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 tight paragraphs with no redundant text. It front-loads purpose and usage, then explains caching behavior concisely.

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 definition covers purpose, usage, caching, and optional evidence/report saving, giving enough context for an agent to call it correctly. It lacks return format details and error handling, but for a pagination tool with no output schema this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema itself provides clear descriptions for 'pagina', 'salvar_html', and 'salvar_evidencia'. The description does not add parameter-specific details beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the verb 'Avança para outra página' and the resource 'busca de marcas já realizada no pePI', specifying it is for pagination of search results. It distinguishes itself from search tools by stating it should be used after a search when more pages are indicated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use: 'Use depois de qualquer uma das ferramentas de busca quando a resposta indicar que há mais páginas.' It also explains the prerequisite of a prior search and cache behavior, including automatic re-send to live pePI if the previous search came from local cache.

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 cover read-only/safe/idempotent profile. The description adds non-obvious behavioral context the schema annotations don't: AND semantics across viena fields, the need to know the Vienna code first, and where to find the classification. However it doesn't state anything about result format, the cache freshness for ordinary searches, or rate limits.

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 tight sentences front-loaded with purpose, then semantics, then precondition. No wasted filler; the URL reference is the only slightly disruptive element and still earns its place as 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?

Annotations cover safety, schema documents all 8 params with examples, and the description supplies the when-to-use, the AND-semantics warning, and the code-precondition. Missing only a note about output shape/pagination behavior, which is not critical given the read-only annotation and complete schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% – each field is documented, including examples. The description adds the AND-across-fields semantics which mirrors the schema's own wording, plus a short-form-code reminder. Baseline 3 is appropriate since the schema already does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Busca marcas figurativas/mistas no pePI pelo Código de Viena') and explicitly distinguishes itself from text-based sibling searches ('Use quando estiver checando colidência de logotipo/elemento gráfico, não de texto'). An agent can tell this apart from inpi_search_by_mark without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it (figurative/graphic element collision checks) and implicitly when not (text searches). Advises using only viena_1 when unsure and consulting the official Vienna table before searching, but the descriptions of the sibling tools aren't referenced as 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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context: it queries the official INPI pePI source, supports exact/radical matching, and is intended to reveal registration status and titulars. It omits caching/rate-limit details, but those are covered in the schema.

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 paragraphs front-load purpose and search modes, then give usage and the sibling alternative. Every sentence supports tool selection or parameter understanding, with no wasted text.

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 full schema coverage and no output schema, the description supplies source, search modes, Nice filter, intended discovery use, and an explicit alternative. It is complete enough for an agent to call correctly; return details are reasonably implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all seven parameters are documented in the schema. The description repeats the main search semantics (exact/radical and Nice filter) but adds little syntax or meaning beyond what the schema already provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb 'Busca marcas' and resource 'pePI (INPI oficial)' by mark text, and distinguishes exact versus radical search plus Nice filter. It also names the advanced sibling for broader scope, so an agent can differentiate the 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 says to use this search to discover whether a name is registered and who the titulars are. It also states that for advanced search with apresentação, natureza, or boolean operators, use inpi_search_by_mark_advanced, providing a clear alternative.

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 annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context (boolean vs. fuzzy mode, active-process filtering, equivalence to the official advanced search), but it omits any mention of the optional file-writing side effects (salvar_html, salvar_evidencia) that are documented only in the parameter descriptions. Given the readOnlyHint, that omission is a noticeable gap, though the schema does disclose it.

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

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

The description is front-loaded with purpose and key capabilities, then moves to usage guidance. It is dense but not bloated, and every sentence serves a clear role. Minor room for tightening the long first sentence, 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?

Given the rich schema (100% coverage), three annotations, and no output schema, the description provides enough context to select and invoke the tool correctly. It covers the core search modes and filters; return format and pagination are left to the schema, and the only notable omission is a reconciliation of the file-writing flags with the readOnlyHint annotation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents all 10 parameters, including their enums, defaults, and behaviors. The description adds a high-level summary of the filter categories (presentation, nature, active processes, boolean/fuzzy), but no syntax or semantics beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Busca avançada de marcas no pePI'), lists the defining capabilities (boolean/fuzzy search, presentation and nature filters, active-process restriction), and explicitly distinguishes itself from the basic sibling 'inpi_search_by_mark'. An agent can tell exactly what this tool does differently from the basic search without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit condition for use: when the basic search ('inpi_search_by_mark') is too imprecise or when filtering by presentation/nature is needed. It also supplies a concrete example ('checar colidência só entre marcas mistas na mesma classe'), making the routing decision unambiguous.

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 read-only, open-world, idempotent, and non-destructive behavior. The description adds critical workflow context: name searches are two-stage and require a second call with 'pos', with no shortcut.

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

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

Front-loads the core purpose, then explains the non-obvious two-stage name search, then gives useful scenarios. The paragraphs are compact and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter, no-output-schema, open-world search tool, the description covers the core purpose and tricky two-stage retrieval well. Minor gaps remain around sibling routing, pagination, and optional file-saving behavior, though those are partly covered by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all seven parameters. The description reinforces the name/pos two-step behavior but does not add meaning beyond the schema for other parameters such as salvar_html, salvar_evidencia, forcar_atualizacao, or resultados_por_pagina.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Lista as marcas registradas por um titular no pePI (INPI oficial)'. It clearly distinguishes this tool as an owner-based trademark search using CNPJ/CPF or 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?

Provides clear usage context: portfolio research, M&A due diligence, and checking previous client registrations. It also explains the CNPJ/CPF direct path versus the two-stage name path, but it does not explicitly compare against sibling search 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 this as a read-only, idempotent, open-world, non-destructive operation, so the safety bar is met structurally. The description adds value beyond that by listing the fields returned (número, marca, situação, titular, classe) and by pointing to the detail tool, useful since there is no output schema.

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 paragraphs: the first front-loads the identifier constraint, the second states return fields and the escalation path. No filler, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately covers the return shape and the hand-off to inpi_get_process_detail. Caching and evidence-save behavior live in the schema parameter docs, so nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds a constraint the schema does not convey: the identifier parameters are mutually exclusive and exactly one must be supplied (all are individually optional in the schema, with no oneOf). That is genuine semantic value beyond the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Busca) and resource (marca no pePI) plus the four accepted identifier types, and distinguishes itself by routing detail lookups to inpi_get_process_detail. An agent can tell it apart from the broader search siblings (by_mark, by_owner) without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use exactly one of these numbers and that this is the most direct way when you already know the number. It names the follow-up alternative (inpi_get_process_detail), but gives no guidance for the reverse case (what to use when you don't know the number), which the other search_* siblings cover.

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