Expor sistemas via MCP virou canal de distribuição: o que a IA não alcança some da conversa. Veja o que muda, o que costuma quebrar e por onde começar.
Especialista em inteligência artificial e transformação digital. Mais de 10 anos ajudando empresas brasileiras a implementar soluções de analytics e IA.
Faz duas décadas que empresa brasileira aprendeu a se perguntar se aparece no Google. A pergunta de agosto de 2026 é outra, e quase ninguém está fazendo: o que acontece quando o seu cliente para de abrir o seu sistema e passa a pedir a coisa ao assistente de IA dele? Se a resposta for "o assistente não chega até a gente", o seu produto sumiu de um canal inteiro sem aviso. Expor sistemas via MCP é o nome técnico da porta que evita isso.
Não é futurologia. O Apps SDK da OpenAI, lançado em 6 de outubro de 2025, foi construído em cima do Model Context Protocol e coloca aplicações de terceiros dentro da conversa do ChatGPT, com a própria OpenAI oferecendo aos desenvolvedores o alcance de "mais de 800 milhões de usuários". E em 26 de agosto de 2026, Salesforce e Anthropic anunciaram o Claudeforce, que leva 37 habilidades de vendas do CRM para dentro do Claude: o vendedor atualiza o funil conversando, e a ação volta para o CRM. O post sobre o que muda com o Claudeforce destrincha o anúncio.
Consumir MCP (plugar a IA nos sistemas que a sua empresa já usa) é assunto do post sobre o que é o Model Context Protocol e por que ele importa: se você ainda não sabe o que é MCP, comece por lá. Este post trata do lado da oferta, quando é o seu produto que precisa ser alcançável de dentro do assistente do cliente.
Por trinta anos, o produto e a tela foram a mesma coisa: você vendia software e vendia junto uma interface de menus, formulários e relatórios, e o suporte girava em torno de ensinar alguém a navegar aquilo. Uma fatia crescente das tarefas deixou de acontecer assim. O usuário abre o assistente que já usa para escrever e-mail, pede "confere se o pedido 4471 saiu para entrega e avisa o cliente", e espera que a máquina resolva. Ninguém navega nada: o modelo precisa descobrir sozinho que existe uma ferramenta capaz de responder aquilo.
É a mudança que a entrega por aplicativo fez com o restaurante de bairro: o salão continua aberto, mas parte do faturamento passou a entrar por uma porta que o dono não controla, que exige o cardápio descrito de outro jeito e ignora quem não a abriu. A sua tela não morre; deixa de ser a única entrada.
Expor um sistema via MCP é publicar um servidor que anuncia uma lista de ferramentas. Cada ferramenta, segundo a especificação oficial, tem quatro peças: nome, descrição em linguagem natural do que ela faz, esquema de entrada (quais campos recebe e quais são obrigatórios) e, opcionalmente, esquema de saída. O modelo lê a lista, escolhe, chama com os argumentos que montou e recebe um resultado estruturado.
Na prática: a transportadora que hoje tem uma tela de "consulta de prazo" expõe a ferramenta consultar_prazo_entrega, que recebe CEP de origem, CEP de destino e peso e devolve prazo e valor. Quando o cliente pergunta "quanto custa mandar 3 kg de São Paulo para Recife", o assistente chama essa ferramenta e responde com o número real, não com um chute.
Aqui mora a parte que pega todo mundo de surpresa: a descrição da ferramenta virou material de vitrine. O modelo escolhe o que chamar lendo texto, e nome ambíguo ou entrada que exige um código interno que ninguém conhece produzem ferramenta que existe e nunca é chamada. Uma ressalva: a especificação vigente em agosto de 2026 é a 2026-07-28, e o protocolo evolui em revisões datadas.
O erro clássico é tratar a decisão como pauta da equipe de tecnologia. Ela é de quem responde por receita, porque o que está em jogo é alcance. Os assistentes não viraram lojas de aplicativos por acaso: a OpenAI anunciou um diretório onde o usuário busca aplicações dentro do ChatGPT, e a Anthropic mantém um diretório de conectores para o Claude, em que o usuário liga a ferramenta com um clique. Estar listado ali é o equivalente, em 2026, a aparecer no resultado de busca.
No comércio o movimento é ainda mais explícito. Em 29 de setembro de 2025, a OpenAI lançou o Instant Checkout no ChatGPT com Etsy e Shopify, abrindo junto o Agentic Commerce Protocol, criado com a Stripe para o lojista vender dentro da conversa mantendo pedido, pagamento e entrega nos próprios sistemas. Esse padrão é outro, não é MCP, mas a direção é a mesma: quem quer aparecer onde a compra acontece publica uma interface que a máquina consiga operar.
Ferramenta que a IA não alcança não é neutra: é um caminho a menos até a sua empresa.
A corrida, porém, está no início. Um levantamento da Stacklok com a fundação de IA agêntica da Linux Foundation, em julho de 2026, com 100 engenheiros de software sêniores de empresas dos EUA e do Reino Unido, encontrou 41% dos entrevistados com MCP em algum estágio de produção, e só 5% em produção governada para a empresa inteira.
das empresas pesquisadas já tinham MCP em algum estágio de produção
Levantamento da Stacklok com a Agentic AI Foundation da Linux Foundation, julho de 2026, com 100 engenheiros de software sêniores em empresas dos EUA e do Reino Unido. Outros 86% do uso de MCP nessas organizações ainda é experimentação ou desenvolvimento local
Publicar as primeiras ferramentas é fácil. O trabalho está no que era implícito quando quem clicava era gente. Quatro pontos costumam doer.
No estado da especificação em agosto de 2026, um servidor MCP protegido atua como resource server de OAuth 2.1: precisa publicar metadados de recurso protegido (o padrão RFC 9728) para o cliente descobrir sozinho o servidor de autorização, validar que o token foi emitido especificamente para ele e recusar tokens de outro destino. Em português de gestor: chave de API colada numa tela de configuração serve ao desenvolvedor que integra o seu sistema, não ao usuário final que quer clicar em "conectar" dentro do assistente.
Modelos de permissão assumem uma pessoa logada com um perfil: vendedor, gerente, administrador. Agora o chamador é um agente agindo em nome de alguém, e costuma precisar de menos poder do que quem o acionou. A especificação resolve com escopos, informando no próprio erro de acesso negado quais permissões faltam. O seu sistema precisa responder "esse token lê pedidos, mas não cancela" com a naturalidade com que hoje esconde um botão.
Agente erra, tenta de novo, perde conexão e repete a chamada. Se a ferramenta que emite um documento fiscal, lança uma cobrança ou dispara uma transferência não for idempotente, a segunda tentativa vira prejuízo e cliente irritado. O protocolo não tem sessão: cada chamada é independente, e a proteção contra duplicidade é sua, não do modelo.
Um humano consulta o prazo de entrega uma vez. Um agente lista as ferramentas, tenta com um argumento, recebe erro, corrige e tenta de novo em segundos, e o seu limite de requisições, dimensionado para tráfego humano, começa a barrar cliente legítimo. Isso mexe no preço: cobrança por assento faz pouco sentido quando o assento é um agente que trabalha vinte e quatro horas. Decida cedo entre cobrar por chamada, por resultado ou por volume, tema ligado ao post sobre Service as a Software.
Quem publica as primeiras ferramentas costuma se irritar com a fricção: o assistente para, mostra o que vai fazer e espera aprovação em vez de executar. Não é limitação temporária, é desenho do padrão. A especificação diz que deve sempre haver um humano no circuito com a capacidade de negar a chamada, e que as aplicações devem exibir os argumentos antes de enviá-los ao servidor e pedir confirmação em operações sensíveis. Há ainda uma regra que muda a forma de escrever o seu servidor: o cliente deve tratar as anotações de comportamento da ferramenta como não confiáveis quando vêm de servidor desconhecido.
Trate a pausa como parte do produto: devolva uma prévia legível do que vai acontecer ("vou emitir uma nota de R$ 3.480,00 para o cliente X, confirma?") e use o mecanismo do protocolo que permite ao servidor pedir a informação que falta em vez de deixar o modelo adivinhar um CNPJ ou uma data.
Ferramenta que executa pagamento sem confirmação explícita não é conveniência, é a primeira manchete ruim sobre o seu produto.
Nenhuma empresa conecta o assistente dela ao seu sistema de cobrança sem explicar ao jurídico onde fica o botão de aprovação. Fricção bem desenhada é o que torna você conectável em operação sensível.
Três perguntas resolvem, e nenhuma é técnica.
O seu cliente já opera dentro de um assistente? Se o comprador do seu produto passa o dia no ChatGPT, no Claude ou no Copilot, a janela abriu. Se ele é o dono da oficina que usa WhatsApp e papel, há coisa mais rentável para fazer antes.
Existe uma pergunta que ele te faz toda semana e que hoje exige abrir a sua tela? Status, segunda via, saldo, prazo, histórico. Essa é a sua primeira ferramenta, de leitura, com risco quase zero.
Você tem API com autenticação decente? Se não tem, esse é o projeto anterior: o servidor MCP se apoia na camada de integração, não a substitui.
Um começo enxuto cabe em poucas semanas: três ferramentas de leitura, para um cliente piloto que já pediu isso, sem nenhuma escrita. Depois de um mês de uso real, entra uma única escrita, atrás de confirmação e com idempotência. Meça chamadas por semana, usuários distintos e quantas conversas terminaram com a tarefa concluída sem ninguém abrir o sistema. A ferramenta responde "o que dá para fazer"; "como fazer do jeito certo" é papel das skills de agentes de IA.
Todo argumento é entrada não confiável. Quem monta a chamada é um modelo que leu textos de origem incerta (um e-mail, uma página, um ticket), e a instrução maliciosa escondida ali chega como argumento normal. Validação de entrada, controle de acesso e limite de requisições valem como numa API pública exposta na internet, porque é isso que ela é.
Devolva o mínimo necessário. O princípio da necessidade do art. 6º da LGPD limita o tratamento ao indispensável para a finalidade. Devolver o cadastro inteiro porque era mais fácil que filtrar campos manda dado pessoal para o contexto de um modelo de terceiro à toa.
Registre quem chamou o quê. Log com o usuário, a aplicação cliente, a ferramenta e os argumentos (com dados sensíveis mascarados) é o que permite responder a um incidente e a um pedido de titular. Sem trilha, você não descobre o problema, descobre o prejuízo.
Ao expor um servidor, o assistente do cliente vira um elo no fluxo de dados, e o contrato precisa dizer qual é a base legal e o que fica registrado.
A API continua sendo a base, e o servidor MCP se apoia nela. A diferença é o público: a API é feita para um programador ler a documentação e escrever código; o MCP, para um modelo descobrir sozinho, em tempo de execução, o que existe e como usar. Sem essa camada por cima, nem a melhor API é encontrada por um assistente.
Não. Faz sentido para quem vende software, dados ou serviço operado por outras empresas, e tem uma consulta que os clientes repetem toda semana. Onde o cliente não opera nada dentro de um sistema seu, o esforço rende pouco hoje.
Só se você publicar sem autenticação, o que ninguém deveria fazer com dado de cliente. O padrão prevê o servidor como recurso protegido por OAuth 2.1, com escopos por operação: o usuário autoriza, o token carrega apenas as permissões daquele acesso, e você revoga quando quiser.
O protocolo e os kits são abertos e gratuitos. O custo real está em adaptar a autenticação para OAuth, tornar idempotentes as ações irreversíveis e manter a operação. Com API madura, um piloto de três ferramentas de leitura é trabalho de semanas.
O MCP começou como assunto de quem queria conectar a IA aos próprios sistemas, e é assim que a maioria ainda o enxerga. O outro lado quase ninguém está olhando: cada assistente vira um lugar onde uma decisão de compra ou uma tarefa operacional acontece, e só participa disso quem publicou uma interface que a máquina consegue operar.
Não é preciso apostar a empresa nisso: começa com três consultas de leitura, um cliente piloto e uma métrica honesta de uso. O erro caro é o oposto, descobrir daqui a dois anos que o concorrente estava dentro da conversa do seu cliente enquanto você aperfeiçoava a tela que ele parou de abrir.
Quer avaliar se o seu produto deveria ser operável por linguagem natural e por qual ferramenta começar? Vamos conversar. A Waxi ajuda empresas brasileiras a desenhar e implementar integrações de IA com governança, do diagnóstico à operação.
MCP, o Model Context Protocol, virou o padrão que conecta a IA aos sistemas da sua empresa. Veja o que é, o que muda na prática e como adotar com segurança.
Skills de agentes de IA guardam os procedimentos da sua empresa em arquivos que o agente segue. Entenda o que são, os limites reais e como criar a primeira.
Service as a Software inverte o modelo do SaaS: você compra o resultado, não a ferramenta. Veja de onde vem o termo, os dados e o que muda para a sua PME.
