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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds the scope of retrieved data, but the genuinely behavioral trait (6h local cache, forcar_atualizacao override) lives only in the schema parameter description, so the body adds limited behavioral context.

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

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

Front-loaded with what the tool returns, then the critical identifier caveat. Slightly long in the field enumeration but every listed field is informative, 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 compensates by enumerating the returned data. Combined with the schema-level handling of salvar_html and forcar_atualizacao, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100% (baseline 3), but the description earns extra credit by clarifying that cod_pedido is not the public process number but an internal pePI ID obtained from a prior search result — a distinction an agent would otherwise get wrong.

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 o detalhe completo de um processo de marca) and enumerates the exact payload: classes de Nice, titulares, procurador, datas, prioridade unionista e histórico de petições. It also clearly positions itself as the detail-fetch that follows a search, distinguishing it from the inpi_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?

It establishes the precondition clearly: you must first run one of the search tools and take the CodPedido from their 'CodPedido (use em inpi_get_process_detail)' field. No explicit when-not or named sibling alternative, but the workflow dependency is 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?

Goes well beyond the annotations (which only cover read-only/idempotent/destructive/openWorld) by disclosing that there is no local cache, that it paginates the LAST search stored server-side, and that a cache-sourced prior search is automatically re-sent live first. These are exactly the stateful behaviors an agent must know to avoid paginating the wrong result set.

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-loaded with the action and the usage trigger before the caching detail. The cache paragraph is slightly long but every sentence carries distinct, decision-relevant information, so waste is minimal.

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 pagination tool with no output schema, the description supplies the trigger, the session-state model, and the cache-recovery behavior. Nothing an agent needs to call it 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 description coverage is 100%, so both parameters (pagina, salvar_html) are already fully documented in the schema. The description adds only the pagination concept, not parameter-specific syntax, so the baseline 3 applies.

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

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

States a specific verb (advances/paginates) and resource (another page of an already-performed trademark search) and clearly separates itself from the search siblings, which start searches rather than continue them. An agent can distinguish it from every sibling 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?

"Use after any of the search tools when the response indicates there are more pages" gives an explicit trigger condition and names the alternative tool category. The prerequisite (a prior search in this session) is stated, leaving nothing to inference.

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

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

Annotations already fully cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuine behavioral context beyond that: multiple viena fields combine as an AND filter that narrows rather than refines, and it directs the agent to gather the code externally before calling.

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?

Purpose is front-loaded, followed by the AND-semantics caveat and the code-lookup prerequisite. It runs to three short paragraphs and every sentence carries weight, though slightly more text than strictly necessary for a search tool.

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?

Purpose, usage, retrieval guidance and parameter interpretation are all covered, and pagination is handled by the resultados_por_pagina enum plus the inpi_next_page sibling. The one gap is that, with no output schema, the description never characterizes the shape of returned results.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents each field. The description adds interpretive value by clarifying that viena_1/2/3 are complete codes, that stacking them is an intersection (not increased precision), and by pointing to the authoritative Vienna table.

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 (marcas figurativas/mistas no pePI) qualified by the Vienna Code, and explicitly contrasts itself with text-based search ('não de texto'), which cleanly separates it from inpi_search_by_mark/mark_advanced.

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 ('checando colidência de logotipo/elemento gráfico') and when not (text search), plus operational advice to use only viena_1 when unsure and to consult the official Vienna table before querying if the code is unknown.

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 safe, idempotent, non-destructive open-world read, so the safety bar is covered. The description adds useful behavioral context: the data source is official INPI/pePI and results mirror the official site's 'Marca' tab, which sets expectations about provenance and result parity. It does not cover caching, rate limits or pagination behavior in the prose (those live only 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 tight paragraphs: the first front-loads purpose plus search-mode and filter semantics, the second handles when-to-use and routing to the sibling. Every sentence earns its place with no filler.

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

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

With six parameters fully documented, complete annotations, and an explicit alternative-tool route, the definition is nearly self-sufficient. The main gap is that no output schema exists and the description only hints at return contents ('titulares'), leaving the result shape partly unspecified.

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

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

Schema description coverage is 100%, so both the exact/radical toggle and the Nice classification filter are already fully documented in the schema. The description restates search-mode and filter semantics but adds no syntax or format detail beyond what the schema provides — baseline 3 applies.

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

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

States a specific verb and resource ('Busca marcas no pePI ... pelo texto da marca') and names the distinguishing scope (exact vs radical, optional Nice filter). It explicitly distinguishes itself from the sibling inpi_search_by_mark_advanced, so an agent can tell the two apart 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?

Gives a concrete use case ('descobrir se um nome já está registrado e quem são os titulares') and names the alternative with the condition that selects it (advanced presentation/nature/boolean searches → inpi_search_by_mark_advanced). Nothing is left to inference.

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

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

Annotations already declare readOnly/openWorld/idempotent/destructive=false, but the description adds real behavioral context beyond them: a 6h local cache, the forcar_atualizacao bypass, and that salvar_html writes a readable HTML report to disk and returns its path. It does not describe pagination or return shape, so it is strong but not exhaustive.

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 tight paragraphs with the capability summary front-loaded and the routing guidance second; the long parenthetical enumerations of apresentação/natureza are informative rather than wasteful. Slightly dense but no filler sentences.

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 9-parameter search tool with no output schema, the description covers what it searches, how to select it, cache/save behavior, and the live-data scope. Return-format details are the only meaningful omission, and those are minor for a search tool whose annotations establish it as a safe read.

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% and each parameter is already well documented (boolean vs fuzzy, enums, Nice class, page sizes). The description's parameter mentions largely restate the schema rather than adding new syntax or format detail, so the baseline of 3 applies.

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

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

States a specific verb (Busca avançada) and resource (marcas no pePI/INPI), and explicitly positions itself as the advanced counterpart to the basic search. An agent can distinguish it 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 names the sibling inpi_search_by_mark and the conditions that select this tool instead (basic search too imprecise, or need to filter by apresentação/natureza), including a concrete example of checking collision among mistas in one class. Nothing left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds meaningful behavior beyond them: the two-stage name search that must be re-invoked with a 'pos' value, plus the fact that the real pePI enforces this flow with no workaround. Minor gaps remain (e.g. no explicit discussion of pagination across the 6h cache beyond what the schema says).

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

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

Three short paragraphs, front-loaded with what the tool does, then the critical two-step caveat, then use cases. Every sentence contributes; only the due-diligence sentence is arguably optional color.

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

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

There is no output schema, so the description must convey return behavior — and it does, describing the candidate-owner list with 'pos' numbers before detail retrieval. Together with the annotations this is enough to call the tool correctly, though a note on how results are paginated/limited would make it fully self-contained.

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 parameters are already documented. The description nonetheless adds real semantic value by explaining the stateful relationship between 'nome' and 'pos' across two calls, which is the most error-prone part of invocation and is only tersely captured in the schema field text.

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: it lists registered trademarks belonging to an owner, retrievable by CNPJ/CPF or by name. The 'por titular' framing implicitly separates it from the name-based sibling searches, but no sibling is named explicitly, so the differentiation is inferred rather than stated.

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 clear operating context: CNPJ/CPF search is direct, while name search requires a two-step flow with no shortcut, and it names concrete scenarios (M&A due diligence, checking a client's prior registrations). It does not tell the agent when to prefer inpi_search_by_mark or inpi_get_process_detail instead, so routing is left implicit.

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

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

Annotations already declare readOnly/idempotent/openWorld, so safety is covered; the description adds the returned field set (número, marca, situação, titular, classe) and the routing to the detail tool. It does not restate the 6h cache behavior (that lives in the schema), but the behavioral picture is otherwise clear.

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 tight paragraphs: the first front-loads what/when, the second the return shape and the follow-up tool. No filler sentences.

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?

Though there is no output schema, the description enumerates the returned fields and points to inpi_get_process_detail for full detail, which is exactly what an agent needs to act and chain calls.

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 baseline is 3, but the description adds real meaning beyond the schema by emphasizing that exactly one number type should be supplied — exclusivity that the flat schema does not express.

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/INPI) plus the exact key types accepted (processo, GRU, protocolo, Madri). It clearly distinguishes itself from the sibling search tools by being the number-based lookup.

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 it ('quando você já sabe o número', 'a forma mais direta') and names the alternative for the follow-up need: inpi_get_process_detail with the returned CodPedido. It also warns to use exactly one of the number types.

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