MCP server for the official Brazilian INPI trademark search system (pePI) — search process numbers, marks, owners and figurative codes with your own INPI login.
Server has 7 tools with complete input schemas and descriptions. Naming follows verb_noun pattern (search_*, get_*, next_page). Descriptions are present and moderately detailed (100-300 chars typical). However, parameter descriptions are repetitive across tools (salvar_html, forcar_atualizacao, salvar_evidencia appear identically in all 7 tools), suggesting copy-paste rather than thoughtful design. Output schemas are not explicitly documented in the code, responses are inferred from parser functions. Error handling is minimal; no recovery guidance or actionable error messages visible. Security: credentials injected via env vars (good), but no permission gates or audit logging. Composition is reasonable, each tool has a single responsibility, but pagination coupling (lastLiveSearchKey/lastServedSearchKey tracking) introduces subtle state management that complicates the stateless MCP model.
Obtém detalhes completos de um processo/pedido de marca (situação, datas, classes, titulares, petições, prioridade unionista, etc.)
Pagina para a próxima página de resultados da busca anterior
Busca avançada com múltiplos critérios (marca, classe, apresentação, natureza, precisão)
Busca por marca (nome, exata ou aproximada)
Busca por titular (pessoa física ou jurídica) — CNPJ/CPF ou nome
Busca por número (processo, GRU, protocolo ou registro internacional)
Output schemas not documented. Parser functions (parseProcessDetail, parseSearchResults) exist but their return types are not visible in tool definitions. LLMs cannot plan downstream calls without knowing what fields to expect.
Repetitive parameter descriptions. salvar_html, forcar_atualizacao, and salvar_evidencia are identical across all 7 tools. This suggests copy-paste and reduces clarity about tool-specific behavior. Each tool should explain why these options matter in its context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Busca por código de Viena (figurative marks — logos, desenhos, símbolos)
No error handling guidance. Code does not show error responses or recovery hints. If a search returns no results or authentication fails (PepiAuthError exists but is not handled in tool responses), the LLM has no actionable next step.
Pagination state management violates stateless MCP model. lastLiveSearchKey/lastServedSearchKey/lastServedReplay track session state across requests. MCP 2026-07-28 requires each request to be self-contained; this coupling risks inconsistency if requests arrive out of order or from different clients.
inpi_next_page lacks context. It accepts only 'page' number but does not require or document which search it paginates. If an LLM calls search_by_mark, then search_by_owner, then next_page(2), which search does it paginate? The tool description does not clarify this dependency.