MCP para fabricantes: um guia prático

O que é MCP, em termos simples?

O Model Context Protocol é uma forma padronizada de um assistente de IA chamar o sistema de outra empresa e receber de volta uma resposta tipada e estruturada.

A Anthropic abriu o código em 25 de novembro de 2024, descrevendo-o como "um novo padrão para conectar assistentes de IA aos sistemas onde os dados vivem". Em 9 de dezembro de 2025, a Anthropic doou o MCP à Agentic AI Foundation, um fundo dirigido dentro da Linux Foundation, cofundado com Block e OpenAI e apoiado em nível platina por AWS, Bloomberg, Cloudflare, Google e Microsoft. Naquele momento, o MCP já havia ultrapassado 97 milhões de downloads mensais de SDK e mais de 10.000 servidores publicados, com suporte de cliente de primeira classe em ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot e VS Code.

Para quem decide sem ser desenvolvedor, a distinção que importa é esta. Quando um assistente lê o seu site, ele está interpretando um documento: pode ler mal uma tabela, perder uma nota de rodapé ou misturar duas variantes. Quando um assistente chama o seu servidor MCP, ele está consultando um sistema: pede a peça, recebe os campos e os informa. O primeiro modo produz respostas plausíveis. O segundo produz respostas corretas — desde que os dados por trás dele estejam corretos, que é onde está a maior parte do trabalho de verdade.

Quem já lançou um neste setor?

Isso já não é especulativo, e os exemplos são variados de um jeito útil:

• Microchip Technology lançou um servidor MCP público e gratuito em 6 de novembro de 2025, expondo especificações de produto verificadas, datasheets, inventário, preços e prazos de entrega sobre MCP Streamable HTTP, com respostas codificadas em JSON voltadas a copilotos, chatbots e agentes corporativos.
• Siemens opera um servidor público em mcp.siemens.com cujos plugins documentados — ativos, portal do desenvolvedor, busca e conteúdo web — estão disponíveis sem autenticação.
• Zoovu lançou um servidor MCP em 11 de dezembro de 2025, dando aos agentes acesso governado aos dados de produto, posicionado em torno da exatidão em perguntas de compatibilidade e de aplicação.
• ECIA lançou o Inventory AI Agent Service da TrustedParts.com em 11 de junho de 2026, disponibilizando o inventário autorizado de componentes eletrônicos dentro do Microsoft Copilot, do ChatGPT e do Claude.
• Shopify expõe um servidor Storefront MCP nas lojas em https://{shop}.myshopify.com/api/mcp, com ferramentas como search_catalog, lookup_catalog e get_product, e sem autenticação exigida no nível storefront.

Dois padrões merecem atenção. Cada um deles se apoia sobre um repositório de dados autoritativo já existente. E cada um deles traça uma linha entre os dados públicos do catálogo e tudo o que é comercialmente sensível.

Ferramentas ou recursos — o que um servidor de peças deve usar?

A especificação é explícita quanto à diferença, e errar nisso produz um servidor que os modelos usam mal.

As ferramentas são controladas pelo modelo. A especificação afirma que as ferramentas "são projetadas para ser controladas pelo modelo, o que significa que o modelo de linguagem pode descobrir e invocar ferramentas automaticamente com base em sua compreensão contextual e nos prompts do usuário". A descoberta é tools/list; a invocação é tools/call. Cada ferramenta carrega um inputSchema (JSON Schema 2020-12 por padrão), um outputSchema opcional, e devolve structuredContent em conformidade com esse esquema.

Os recursos são orientados pela aplicação. A especificação afirma que os recursos "são projetados para ser orientados pela aplicação, com as aplicações hospedeiras determinando como incorporar contexto conforme suas necessidades" — normalmente um seletor, uma lista ou a inclusão automática pelo host. Cada recurso é identificado por um URI, e os templates permitem URIs parametrizados.

Um catálogo é um espaço de consulta, não um conjunto fixo de documentos. Ninguém quer rolar um seletor de recursos com 40.000 peças. Por isso, a maior parte de um servidor de peças deve ser composta de ferramentas, com dois refinamentos: use blocos de conteúdo resource_link para apontar para datasheets e arquivos CAD em vez de embutir payloads grandes, e reserve recursos de verdade para um punhado de documentos estáveis, como um dicionário de classificação ou um log de alterações.

Dois detalhes da especificação atual compensam a atenção. As listas de ferramentas não devem variar por conexão, mas podem variar conforme a autorização apresentada na requisição. E os servidores deveriam devolver as ferramentas em uma ordem determinística, porque a ordenação estável permite que os clientes façam cache da lista e melhora a taxa de acerto do cache de prompt.

O que mudou na especificação 2026-07-28?

Esta revisão remodelou o transporte, e qualquer projeto escrito com base em material de 2025 estará errado em pontos específicos.

O formato do transporte agora é agradavelmente sem graça. O servidor expõe um único endpoint MCP que aceita POST — por exemplo, https://example.com/mcp. Cada requisição JSON-RPC é um POST próprio. Os clientes precisam enviar um cabeçalho Accept listando tanto application/json quanto text/event-stream, além de um cabeçalho MCP-Protocol-Version que precisa coincidir com o valor de _meta no corpo — caso contrário, o servidor precisa rejeitar com 400 e um erro HeaderMismatch. Os servidores precisam validar o cabeçalho Origin e responder 403 se ele estiver presente e for inválido.

A consequência prática para as equipes de infraestrutura: como não há sessão em nível de protocolo, o seu servidor MCP é implantado atrás de um balanceador de carga round-robin simples, como qualquer outro serviço HTTP stateless. Roots, Sampling e Logging agora estão descontinuados, com uma janela mínima de doze meses, e o antigo transporte HTTP+SSE também foi formalmente descontinuado.

Como restringir preço e estoque com OAuth?

A autorização é opcional no MCP, o que é exatamente o certo para um servidor de peças: o catálogo público não deveria exigir token nenhum, e somente as ferramentas comercialmente sensíveis deveriam desafiar o chamador.

Quando você a implementa, os requisitos são específicos. O servidor MCP atua como um resource server OAuth 2.1, seguindo o draft OAuth 2.1 do IETF. Ele deve implementar o Protected Resource Metadata (RFC 9728), e os clientes devem usar esses metadados para descobrir o servidor de autorização. Os clientes devem implementar os Resource Indicators (RFC 8707), enviando um parâmetro resource que identifica o URI canônico do seu servidor tanto nas requisições de autorização quanto nas de token, e o seu servidor deve validar que os tokens foram emitidos para ele como público-alvo pretendido. Os servidores de autorização deveriam devolver o parâmetro iss conforme a RFC 9207, e os clientes precisam validá-lo. O Dynamic Client Registration agora está descontinuado em favor dos Client ID Metadata Documents, embora continue disponível por compatibilidade retroativa.

O padrão que funciona para um distribuidor ou fabricante:

1. 01Nível não autenticado — especificações, busca paramétrica, alternativas, documentos de conformidade, links de CAD e preços de tabela onde você os publica.
2. 02Nível autenticado — preços de contrato, disponibilidade específica por cliente, criação de cotação. Desafie com um 403 e error="insufficient_scope", nomeando os escopos necessários para que o cliente consiga elevar o acesso em uma única ida e volta, em vez de várias.
3. 03Nunca use um identificador de cliente em um argumento de ferramenta como único controle de acesso. Um handle é um nome, não uma permissão; valide a autorização em toda chamada.

O que um servidor MCP de peças deve expor?

De seis a oito ferramentas é a ordem de grandeza correta. Acima disso, a seleção feita pelo modelo se degrada.

A definição de uma ferramenta deve parecer banal, e é justamente esse o ponto:

{
  "name": "search_parts",
  "title": "Parametric part search",
  "description": "Search the catalog by product class and typed parameter constraints. Returns matching parts with their key parametrics, units and last-verified date. Use get_part for the full record.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "product_class": { "type": "string", "description": "ETIM class code or class name" },
      "constraints": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "parameter": { "type": "string" },
            "operator": { "type": "string", "enum": ["eq", "gte", "lte", "between", "in"] },
            "value": {},
            "unit": { "type": "string" }
          },
          "required": ["parameter", "operator", "value"]
        }
      },
      "limit": { "type": "integer", "default": 20 }
    },
    "required": ["product_class"],
    "additionalProperties": false
  }
}

Repare no que a descrição faz: ela diz ao modelo o que a ferramenta devolve e quando recorrer a uma ferramenta diferente. Esse único hábito faz mais pela qualidade das respostas do que qualquer quantidade de polimento de esquema.

Um exemplo prático

Um engenheiro de projeto de um fabricante por contrato no Texas está substituindo uma peça em fim de vida em uma placa que também é enviada a um montador de painéis alemão. O assistente está com o servidor MCP do fabricante conectado.

Engenheiro: O MOSFET de canal N de 60 V do nosso estágio buck está entrando em fim de vida. Preciso de um substituto direto no mesmo encapsulamento, com R_DS(on) não pior que 12 miliohms sob acionamento de porta de 10 V, e preciso saber se ele está realmente disponível.

O assistente faz quatro chamadas.

→ tools/call  get_part
   { "part_number": "XYZ-60N12-D2PAK" }
← structuredContent
   { "package": "D2PAK", "vds_v": 60, "rds_on_mohm": 11.5,
     "vgs_meas_v": 10, "lifecycle": "EOL", "last_verified": "2026-08-04" }

→ tools/call  find_alternates
   { "part_number": "XYZ-60N12-D2PAK", "basis": "form_fit_function" }
← structuredContent
   [ { "part_number": "XYZ-60N10-D2PAK", "equivalence": "drop-in",
       "rds_on_mohm": 9.8, "differences": ["lower R_DS(on)", "higher Qg"] },
     { "part_number": "XYZ-60N14-D2PAK", "equivalence": "footprint",
       "rds_on_mohm": 13.5, "differences": ["exceeds R_DS(on) limit"] } ]

→ tools/call  get_availability
   { "part_numbers": ["XYZ-60N10-D2PAK"] }
← 403 Forbidden
   WWW-Authenticate: Bearer error="insufficient_scope",
     scope="stock:read", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

   [client performs step-up authorisation, then retries]

← structuredContent
   { "part_number": "XYZ-60N10-D2PAK",
     "stock": [ { "location": "US-TX", "qty": 14200 },
                { "location": "DE-BW", "qty": 3800 } ],
     "lead_time_weeks": 8, "as_of": "2026-08-09T06:12:00Z" }

→ tools/call  get_compliance_documents
   { "part_number": "XYZ-60N10-D2PAK", "types": ["rohs", "reach"] }
← content: [ { "type": "resource_link", "uri": "https://…/rohs-2026-03.pdf",
               "name": "RoHS declaration (issued 2026-03-11)" } ]

O assistente então responde: um candidato é um substituto direto, com resistência de condução melhor e carga de porta maior, o que vale conferir contra o driver de porta; o segundo atende ao footprint, mas não cumpre o limite de R_DS(on); o estoque é de 14.200 no Texas e 3.800 em Baden-Württemberg na manhã de hoje, com prazo de entrega de oito semanas; as declarações de RoHS e REACH vêm anexadas com suas datas de emissão.

Nada aqui é impressionante como engenharia. É impressionante como comércio. Três decisões de sourcing foram tomadas sem que nenhuma pessoa abrisse um navegador, e cada número é rastreável até um registro com carimbo de data/hora.

Quem consegue de fato alcançar o seu servidor hoje?

Seja honesto com a sua diretoria sobre isso, porque a resposta é mais estreita do que a maior parte do material dos fornecedores sugere.

Ou seja, o MCP alcança engenheiros com um assistente que eles mesmos configuram e compradores corporativos cuja área de TI registra o seu servidor. É uma população pequena para os padrões da web e muito grande para os padrões de um funil comercial.

Como os agentes descobrem o seu servidor?

Não existe descoberta em nível de DNS. Existem três mecanismos:

1. 01O registro oficial de MCP em registry.modelcontextprotocol.io, o repositório centralizado de metadados dos servidores publicamente acessíveis, apoiado por Anthropic, GitHub, Microsoft e PulseMCP. É de código aberto, suporta sub-registros e segue em preview antes da disponibilidade geral — portanto, espere mudanças.
2. 02Diretórios do lado do cliente, como o diretório de conectores do Claude e o diretório de aplicativos do ChatGPT, cada um com seu próprio processo de revisão.
3. 03A sua própria documentação. Hoje é assim que a maioria das conexões de fato acontece: uma página para desenvolvedores informa a URL do endpoint, a lista de ferramentas e os escopos de autorização, e um cliente a cola no assistente dele.

Publique o seu documento .well-known/oauth-protected-resource mesmo que a maioria das ferramentas seja pública, e versione o caminho do endpoint. Você vai mudar a sua superfície de ferramentas, e é melhor que isso seja uma migração deliberada, e não uma quebra silenciosa.

Um checklist de implementação

1. 01Consolide tudo em um registro canônico por peça, com atributos tipados, unidades, procedência e carimbo de data/hora da última verificação. Não comece pelo protocolo.
2. 02Escolha de seis a oito ferramentas e escreva descrições que digam quando não usar cada uma.
3. 03Declare esquemas de saída e devolva structuredContent. Inclua unidades e datas de verificação em todo payload.
4. 04Sirva um único endpoint POST, honrando os cabeçalhos Mcp-Method e Mcp-Name, validando Origin e definindo ttlMs e cacheScope nos resultados de listagem.
5. 05Separe as ferramentas públicas das restritas, implemente os metadados da RFC 9728, valide o público-alvo do token conforme a RFC 8707 e use desafios de escopo para elevar o acesso em uma única ida e volta.
6. 06Devolva uma ordenação determinística das ferramentas e nomes de ferramentas estáveis, para que os caches dos clientes funcionem.
7. 07Registre cada chamada — ferramenta, argumentos, latência e se a consulta foi resolvida. Um servidor MCP sem analytics é um canal que você não consegue gerenciar.
8. 08Monitore a exatidão contra a fonte de verdade, continuamente. Uma ferramenta que devolve com confiança um valor nominal desatualizado é pior do que nenhuma ferramenta.

A Partsgraph fornece isso como uma camada gerenciada: consolidamos o seu catálogo existente em um único Parts Graph verificado, hospedamos o endpoint MCP com OAuth nos níveis restritos e informamos quais agentes chamaram o quê e onde as respostas estavam erradas.

Se você quer saber em que pé está antes de escrever qualquer linha de código, passe o seu domínio pelo avaliador gratuito em /audit — ele verifica o que as máquinas conseguem alcançar hoje no seu catálogo e se um endpoint MCP teria algo confiável para servir.