Adicionei WebMCP a um checkout ao vivo do Stripe em ~40 linhas

A maioria das demonstrações de "um agente de IA compra algo em um site" são lojas de brinquedos construídas para a demonstração. Eu queria saber se WebMCP poderia ser aplicado a um produto que já aceita dinheiro de verdade — sem reconstruir o checkout e sem abrir uma brecha de segurança.

Então eu coloquei no meu loja de eSIM. Ela vende planos de dados, tem cobrança Stripe ao vivo e possui clientes pagantes. Aqui está o que isso levou.

O que é o WebMCP, em um parágrafo

Uma página da web chama document.modelContext.registerTool() para entregar a um agente de IA de navegação ações chamáveis — em vez de o agente ler seu HTML e adivinhar qual botão clicar. É um padrão do Grupo de Comunidade W3C; o navegador in-app do ChatGPT adicionou suporte em agosto de 2026. Sem arquivo .well-known, sem manifesto, sem servidor separado. É JS do lado do cliente.

As duas ferramentas

• list_esim_plans — retorna o catálogo de planos ao vivo (país, dados, duração, preço).
• buy_esim_plan — aceita um slug de plano, cria uma sessão de checkout real do Stripe, e retorna a URL para o agente. Nenhum dinheiro é movimentado até que um humano insira os detalhes do cartão na própria página do Stripe. A ferramenta inicia uma compra; não completa uma cobrança.

Um agente passa de "encontre-me um plano de dados do Reino Unido de 7 dias" para um checkout do Stripe totalmente formado em duas chamadas, sem raspagem de DOM.

O registro

Um componente cliente, montado na página. Ao ser montado, ele detecta a presença de document.modelContext e, se presente, registra as duas ferramentas. Se ausente — em qualquer navegador normal — é um no-op silencioso, então é enviado para produção com segurança. O arquivo inteiro tem ~40 linhas de registro mais duas funções execute() que cada uma faz um fetch.

Código fonte completo: https://github.com/flovoice53-tech/sms-florin-webmcp-demo

A única decisão de design que importava

Não o protocolo — o protocolo é pequeno. A decisão foi: o caminho do agente reutiliza o caminho humano.

O botão "Comprar" humano e a ferramenta buy_esim_plan chamam a mesma função createCheckoutSession(). Mesmo preço, mesma metadata, mesma configuração do Stripe. Não há um "checkout do agente" separado que possa ficar fora de sincronia com o real. O endpoint da ferramenta apenas retorna a URL da sessão como JSON em vez de fazer um redirecionamento do lado do servidor.

Segurança

• Detectado por recurso: sem efeito em qualquer navegador que não seja WebMCP.
• buy_esim_plan não pode movimentar dinheiro — o pior cenário é uma sessão do Stripe criada, mas não paga, que expira por conta própria.
• Os endpoints de suporte (GET /api/v1/esim-catalog, POST /api/v1/esim-checkout) não são autenticados — mesmo modelo de checkout para convidados que o formulário humano já utiliza — mas limitados por taxa de IP.

Resultado

Está ao vivo em https://flo-voice1.com/esim agora. Código de integração (MIT): https://github.com/flovoice53-tech/sms-florin-webmcp-demo. Vídeo de 2 minutos: https://youtu.be/yd-2FVXbW8s

Se você está adaptando um produto existente: não separe seu checkout para o agente. Faça o agente chamar a mesma função que seu botão faz.