MCP próprio, NLWeb ou nada: a matriz de decisão

Em 7 de setembro de 2026, a resposta certa para a maioria das empresas de médio porte é nada além de HTML bem estruturado. Nem servidor MCP, nem instância NLWeb. Não porque agente de IA seja modismo, mas porque a evidência publicada de que publicar um desses dois aumenta citação ou tráfego é fraca ou inexistente, enquanto o custo de engenharia e de manutenção é real e recorrente.

Esta é a matriz que decide, em uma reunião, entre três opções técnicas e uma quarta opção que ninguém propõe em voz alta porque parece pouco: continuar sem nada além do HTML que o site já deveria ter. Ela serve para quem foi cobrado de cima, sem critério, a "abrir o site para agentes de IA", e precisa devolver uma decisão defensável em vez de um projeto de três meses que ninguém sabe medir depois.

Minha tese, e ela é impopular porque contraria o próprio mercado que eu ajudo a construir: publicar servidor MCP ou instância NLWeb é trabalho de engenharia de verdade, com superfície de segurança nova, e não há estudo publicado até hoje que isole o efeito de ter um desses dois sobre citação em IA ou sobre tráfego. O que aumenta citação, com evidência publicada, continua sendo conteúdo público bem estruturado e entidade consistente. A peça entrega o critério de quando essa resposta muda, porque ela muda, só não muda pela pressão de um vice-presidente que leu uma manchete.

Quatro caminhos aparecem em qualquer reunião sobre "deixar o site pronto para agentes". Cada um resolve um problema técnico diferente, e confundir um pelo outro é o primeiro erro de quem decide sob pressão.

• Servidor MCP próprio. Um processo que expõe ferramentas e dados da empresa por JSON-RPC 2.0 a um cliente de modelo, no protocolo aberto lançado pela Anthropic em novembro de 2024 e hoje sob governança da Agentic AI Foundation, com autorização por OAuth 2.1 obrigatória desde a especificação de março de 2025.
• Instância NLWeb. Um endpoint /ask que recebe pergunta em linguagem natural e responde com resultados estruturados a partir do schema.org já publicado nas páginas, e que, pela especificação de referência mantida hoje na organização nlweb-ai, também nasce exposta como servidor MCP em um endpoint /mcp.
• Feed ou API pública documentada. Um catálogo de dados (produto, preço, disponibilidade, conteúdo editorial) publicado em formato aberto e estável, com contrato de campos versionado, que qualquer cliente HTTP consegue ler sem negociação prévia e sem que a empresa precise adotar um protocolo de agente específico.
• Nada além de HTML bem estruturado. Manter o site com marcação semântica correta, dados estruturados em schema.org coerentes com o conteúdo visível, tempo de resposta e crawl liberado para os bots corretos, sem adicionar nenhuma camada nova de protocolo de agente.

As quatro opções não competem pelo mesmo orçamento nem pelo mesmo prazo. É por isso que a matriz da próxima seção compara cada uma nas mesmas seis dimensões, lado a lado, em vez de tratar a decisão como binário entre "fazer alguma coisa" e "fazer nada".

A tabela abaixo é o objeto que eu levaria para a reunião em que a cobrança chegou de cima sem critério. Ela não recomenda uma linha só; ela mostra o preço de cada uma nas seis dimensões que importam para quem assina o orçamento e para quem sustenta o sistema depois.

Fonte da coluna de evidência: dossiê comparativo MCP versus NLWeb versus feed público, compilado em 6 de setembro de 2026 a partir de reportagens técnicas de agosto e setembro de 2026 sobre o MCP Registry oficial, o diretório de conectores da Claude, e o guia de implementação de NLWeb; método: leitura direta das fontes primárias listadas na seção de referências, sem inferência de números não publicados.

Repare no padrão: as duas primeiras linhas concentram o esforço de engenharia mais alto e a evidência de ganho mais fraca ao mesmo tempo. Isso não é coincidência editorial minha, é o que sobra depois de eu tentar achar o estudo que faltava e não achar.

Existe contagem de servidores registrados; não existe estudo de causa e efeito sobre citação ou tráfego. Essa é a distinção que separa o que dá para afirmar do que o mercado de MCP e NLWeb gosta de insinuar em 2026.

O que existe, com fonte: o MCP Registry oficial, em modo preview desde setembro de 2025, recebeu mais de 160 servidores registrados nos primeiros dias após o lançamento, segundo análise de governança publicada em 20 de agosto de 2026 pela NHIMG. O diretório de conectores da própria Claude listava mais de 950 servidores MCP em agosto de 2026, contra cerca de 800 no lançamento dos conectores, segundo o digest do Claude Marketplace de 17 de agosto de 2026. Isso é contagem de entradas em um catálogo, não é número de empresas com ganho medido, e as duas fontes não desagregam quantos conectores pertencem à mesma organização.

O que não existe, e falta dizer isso com todas as letras: nenhuma das fontes técnicas de 2025 e 2026 que eu revisei publica um desenho experimental, um antes e depois, ou um comparativo com grupo de controle relacionando presença de servidor MCP ou instância NLWeb a aumento de citação em resposta de IA ou a aumento de tráfego de referência. O próprio guia de implementação de NLWeb, publicado em 6 de setembro de 2026 pela GenReady, pergunta diretamente se o site deveria implementar o protocolo e responde que, para a maioria dos sites, não, porque falta volume de tráfego que justifique o esforço.

[FALTA EVIDÊNCIA: estudo controlado que isole o efeito de publicar servidor MCP ou instância NLWeb sobre taxa de citação em resposta de IA ou sobre tráfego de referência, com metodologia de amostra, período e significância declaradas]

Por que a ausência importa para a decisão, e não é só um detalhe acadêmico: quem aprova orçamento de engenharia com base em "todo mundo está fazendo" está confundindo contagem de registro com prova de retorno. Contar servidores é contar quantas empresas apostaram; não é medir se a aposta pagou. Enquanto essa lacuna existir, o ônus da prova é de quem propõe o projeto, não de quem pergunta se vale a pena.

Meu ponto de comparação, que uso na minha própria operação: schema.org sozinho não amplifica citação em IA sem o conteúdo por trás, e o mesmo raciocínio vale, com mais força ainda, para o protocolo por trás de um endpoint de agente. Protocolo não substitui conteúdo; na melhor hipótese, ele transporta o conteúdo que já é bom.

A resposta muda quando existe uma condição concreta, não quando existe uma tendência de mercado. Quatro condições, isoladas ou combinadas, empurram a decisão de "nada ainda" para "faça", e nenhuma delas é "o concorrente anunciou".

• Catálogo grande demais para caber em HTML navegável por humano. Quando o catálogo passa de dezenas de milhares de itens e a navegação humana já depende de busca interna robusta, um feed público estruturado deixa de ser opcional: é a mesma decisão que já se toma hoje para exportar dados para marketplace, só que agora servindo agente em vez de parceiro humano.
• Dado que muda o tempo todo. Preço, disponibilidade de estoque ou status de serviço que mudam várias vezes ao dia tornam o HTML estático, mesmo bem estruturado, uma fonte defasada no momento em que o agente lê. Aqui a API pública documentada, com contrato de atualização declarado, resolve o problema real; MCP só se soma quando o consumidor também precisa executar uma ação, não apenas ler.
• Contrato com parceiro que já consome agente. Se um parceiro comercial nomeado já opera um agente de compra ou de integração e pede explicitamente um servidor MCP ou uma instância NLWeb como condição de contrato, a decisão deixa de ser especulativa: virou requisito de receita, com prazo e responsável do lado de quem pede.
• Obrigação regulatória ou setorial. Quando um regulador ou um padrão setorial exige interoperabilidade programática com um formato específico, a conversa sobre "vale a pena" se torna irrelevante; o que resta é o prazo de implementação, não a escolha.

Note o padrão comum às quatro: em todas, alguém de fora da empresa, com um número ou uma cláusula concretos, está pedindo a integração. Nenhuma delas nasce de dentro da área de marketing querendo "estar pronta para o futuro". Se a condição que motiva o projeto é uma manchete e não um contrato, um catálogo ou uma obrigação, a resposta continua sendo nada ainda.

Para quem já decidiu que o gatilho existe, o mapa mais completo que eu publiquei sobre como montar essa camada, protocolo por protocolo, está em B2A na prática: como deixar o site pronto para agentes com MCP, NLWeb, A2A e AP2, e o caso setorial mais próximo do gatilho de catálogo e integração com parceiro está em indústria agent-ready em 90 dias sem trocar o ERP.

Expor uma ferramenta a um agente cria uma superfície nova de injeção de prompt e de exfiltração de dado, e essa superfície não existe hoje no HTML estático do seu site. Isso não é motivo para nunca fazer; é motivo para não fazer sem os controles abaixo já implantados.

Um servidor MCP aceita instrução em linguagem natural vinda de fora e a traduz em chamada de ferramenta. Se essa ferramenta tem acesso a dado sensível ou a ação com efeito real (criar pedido, alterar cadastro, mover dinheiro), o texto malicioso embutido em um documento, em um e-mail ou em uma página que o agente lê pode virar comando executado em nome de outra pessoa. É a mesma classe de risco que descrevo em detalhe no meu texto sobre segurança agêntica: site pronto para agentes sem virar vetor, e ela não desaparece por o protocolo ser NLWeb em vez de MCP puro, porque toda instância NLWeb também nasce exposta como servidor MCP.

Antes de publicar qualquer ferramenta a um agente, a lista mínima é esta:

1. Autorização por OAuth 2.1 com PKCE obrigatório, separando servidor de recurso e servidor de autorização, exatamente como a especificação passou a exigir desde a onda de atualizações de 2025.
2. Escopo mínimo por ferramenta: cada ferramenta exposta enxerga só o dado e a ação que precisa, nunca o cadastro inteiro ou a permissão administrativa por padrão.
3. Log e auditoria de toda chamada, com identidade do agente e da sessão que originou o pedido, porque sem log não há como investigar depois.
4. Confirmação humana explícita para qualquer ação com efeito irreversível ou financeiro, nunca automática.
5. Dono nomeado por ferramenta, responsável por revisar o que ela expõe a cada mudança de escopo do agente que a consome.

Se a resposta da empresa hoje é "nada ainda", essa lista não precisa existir ainda. Ela vira pré-requisito no dia em que o gatilho da seção anterior aparecer, e montá-la depois do incidente é sempre mais caro do que montá-la antes do primeiro deploy.

Decidir "nada ainda" não é decidir ficar parado. É decidir onde investir o mesmo tempo de engenharia com evidência de ganho maior e superfície de risco menor. Estes são os itens que cabem em um trimestre sem exigir protocolo novo.

• Auditar dados estruturados existentes. Confira se o schema.org publicado descreve exatamente o que está visível na página, sem inflar campo que o texto não sustenta; schema inflado é um dos anti-padrões que mais reprovam avaliação de qualidade em 2026.
• Liberar crawl para os bots corretos. Revise robots.txt e regras de WAF por user-agent, separando o bot que treina modelo do bot que indexa para citação e do bot que age em nome de um usuário que acabou de perguntar, porque bloquear os três juntos por reflexo fecha a porta para citação sem nenhum ganho de segurança real.
• Medir a linha de base antes de qualquer projeto novo. Rode uma auditoria dos dez sinais de prontidão que eu descrevo em os dez sinais de agent-readiness que auditei em 2026, porque a maioria das lacunas encontradas costuma estar na estrutura básica do site, não na ausência de protocolo de agente.
• Consolidar entidade e consistência de dado público. Nome de empresa, endereço, produto e afirmação numérica precisam bater entre site, perfil e fonte externa, porque é essa consistência, não o protocolo, que tem evidência publicada de sustentar citação.
• Publicar ou revisar o llms.txt como sinal opcional, não como talismã. Ele não é exigido pelo Google nem substitui conteúdo estruturado; mantenho o meu pela mesma razão que descrevo em llms.txt não é requisito para o Google e por que mantenho o meu mesmo assim, como sinal a mais, não como prova de prontidão.
• Mapear o modelo B2A que a empresa poderia adotar no futuro, sem implementar ainda. Ter o desenho pronto em business-to-agent encurta o prazo no dia em que o gatilho aparecer, sem gastar orçamento de engenharia antes da hora.

No fim do trimestre, a empresa não terá um servidor MCP publicado, e está certo que não tenha. Terá um site mais citável hoje e um plano pronto para o dia em que a condição concreta da seção anterior aparecer de verdade.

Cenário hipotético: chamo de Distribuidora Ferraz uma distribuidora industrial de médio porte cujo CTO, aqui chamado de Marcos, recebeu em agosto de 2026 a instrução do conselho para "colocar a empresa pronta para agentes de IA" sem nenhum critério além da manchete que motivou a reunião.

Cenário hipotético: o catálogo da Ferraz tem poucos milhares de itens, navegável por busca interna comum, sem parceiro comercial pedindo integração de agente e sem obrigação regulatória do setor exigindo protocolo específico. Passando a Ferraz pela matriz da terceira seção, nenhuma das quatro condições da seção de gatilho está presente: catálogo não é grande demais, preço muda semanalmente e não a cada minuto, nenhum parceiro contratualmente pede MCP ou NLWeb, e não há exigência regulatória.

Cenário hipotético: a decisão que eu levaria para o conselho da Ferraz é "nada ainda", com o plano de noventa dias da seção anterior anexado como entregável concreto do trimestre, e a lista de gatilhos como critério escrito para revisitar a decisão, não como promessa vaga de "monitorar o mercado". Se um comprador industrial relevante da Ferraz anunciasse um agente de compra próprio no ano seguinte, a segunda condição de gatilho (contrato com parceiro que já consome agente) se cumpriria, e a resposta mudaria; até lá, ela não muda por pressão de manchete.

O caso setorial mais próximo desse gatilho de catálogo industrial e integração com parceiro que já opera agente está descrito, com detalhe de implementação, em indústria agent-ready em 90 dias sem trocar o ERP.

Esta recomendação vale para leitura em 7 de setembro de 2026 e tem prazo de validade curto, porque o terreno factual que a sustenta está em movimento público e documentado. Reavalie a matriz se qualquer um destes três marcadores mudar: publicação de estudo controlado ligando presença de servidor MCP ou instância NLWeb a aumento medido de citação ou tráfego; saída do MCP Registry oficial do modo preview para uma versão estável de produção, hoje ainda em v0.1 com aviso de possíveis quebras de compatibilidade; ou publicação de contagem oficial e auditável de sites com instância NLWeb ativa, hoje inexistente.

Minha experiência de primeira mão aqui é de quem constrói e mede infraestrutura de citação para marcas no Brasil desde 2024 como founder da Brasil GEO, não de quem implementou pessoalmente um servidor MCP de produção para uma distribuidora industrial; o caso da seção anterior é rotulado hipotético justamente por isso. Onde a evidência publicada faltou, marquei com o rótulo de falta de evidência em vez de estimar um número que ninguém mediu.

Limitação adicional: a matriz compara MCP, NLWeb, feed público e HTML estruturado; ela não cobre A2A (comunicação entre agentes) nem AP2 (pagamento por agente) em profundidade, porque as fontes disponíveis em 2025 e 2026 não trazem, para nenhum dos dois, dado de adoção comparável ao que existe para MCP e NLWeb. Quem quiser o mapa dos quatro protocolos junto encontra em B2A na prática.

• MCP Registry preview raises the stakes for enterprise governance, NHIMG, 20 de agosto de 2026
• Claude Marketplace Digest, edição de 17 de agosto de 2026, Claude Marketplace Digest
• What is NLWeb, and should your site implement it?, GenReady, 6 de setembro de 2026
• NLWeb, verbete de glossário técnico, Glippy, 27 de agosto de 2026
• Arcade acquires Smithery to own the agent tool supply chain, Forbes, 10 de agosto de 2026
• MCP, A2A e interoperabilidade de agentes, Neural Partners, 9 de agosto de 2026
• A história do Model Context Protocol, MCP Blog, 25 de agosto de 2026