Skip to main content
Glama
milaniseb12-png

inpi-marcas-mcp-server

by milaniseb12-png
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Buscar marcas figurativas por código de Viena

inpi_search_by_figurative_code
Read-onlyIdempotent

Search Brazilian figurative and mixed trademarks in INPI's pePI by Vienna Classification code to check logo or graphic element collisions, not text matches.

Instructions

Busca marcas figurativas/mistas no pePI (INPI oficial) pelo Código de Viena (a classificação internacional de elementos figurativos — ex: 27.05.01 para letras estilizadas). Use quando estiver checando colidência de logotipo/elemento gráfico, não de texto.

Cada campo (viena_1/2/3) é um código COMPLETO (grupo.divisão.seção). Preencher mais de um campo busca marcas que tenham TODOS os códigos ao mesmo tempo (AND), não é mais preciso — na dúvida, use só viena_1.

A Classificação de Viena completa está em https://www.gov.br/inpi — se não souber o código, descreva o elemento gráfico ao usuário e peça para consultar a tabela oficial antes de buscar.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viena_1NoPrimeiro código da Classificação de Viena (grupo.divisão.seção), ex: 27.05.01
viena_2NoSegundo código, ANDado com o primeiro (só use se precisar que a marca tenha os dois elementos)
viena_3NoTerceiro código, ANDado com os outros dois
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.
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.
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
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools