Skip to main content
Glama
milaniseb12-png

inpi-marcas-mcp-server

by milaniseb12-png
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Busca avançada de marca (booleana/fuzzy, apresentação, natureza)

inpi_search_by_mark_advanced
Read-onlyIdempotent

Search Brazilian trademarks on INPI pePI with boolean or fuzzy matching and filters by class, presentation, nature, and active status.

Instructions

Busca avançada de marcas no pePI (INPI oficial), igual à Pesquisa Avançada do site oficial. Permite operadores booleanos (AND/OR) ou busca fuzzy, filtrar por forma de apresentação (nominativa/mista/figurativa/tridimensional/posição), natureza (produto/serviço/coletiva/certificação) e restringir a "Pedidos Vivos" (só processos ainda ativos).

Use quando a busca básica (inpi_search_by_mark) for imprecisa demais ou quando precisar filtrar por apresentação/natureza específica — por exemplo, checar colidência só entre marcas mistas na mesma classe.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marcaYesTexto da marca. Aceita operadores booleanos quando fuzzy=false, ex: GOOGLE AND CLOUD
naturezaNoNatureza da marcaqualquer
busca_fuzzyNofalse = busca booleana (padrão do pePI); true = busca fuzzy/aproximada
classe_niceNoFiltra pela Classificação de Nice, ex: 09, 42
salvar_htmlNotrue = também salva o resultado como um relatório HTML legível (tabela, sem depender de MCP) em disco e devolve o caminho do arquivo.
apresentacaoNoForma de apresentação da marcaqualquer
salvar_evidenciaNotrue = grava um PACOTE DE EVIDÊNCIA bruta em disco (HTML original do pePI, cópia offline com imagens/CSS baixados, manifest com sha256 de cada arquivo) — pra prova/auditoria, não só leitura. Diferente de salvar_html (que é só um relatório bonito). Sempre vai ao pePI ao vivo, ignorando o cache, porque a evidência precisa do HTML da requisição real.
forcar_atualizacaoNoIgnora o cache local (padrão 6h) e busca de novo no pePI ao vivo.
apenas_pedidos_vivosNotrue = só processos ativos (Pedidos Vivos); false = inclui arquivados/extintos
resultados_por_paginaNoResultados por página. Valores aceitos pelo pePI: 20, 40, 60, 80, 100.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.0
    • addedInput schema / properties / salvar_evidencia
      Added value: +{
+  "default": false,
+  "description": "true = grava um PACOTE DE EVIDÊNCIA bruta em disco (HTML original do pePI, cópia offline com imagens/CSS baixados, manifest com sha256 de cada arquivo) — pra prova/auditoria, não só leitura. Diferente de salvar_html (que é só um relatório bonito). Sempre vai ao pePI ao vivo, ignorando o cache, porque a evidência precisa do HTML da requisição real.",
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools