Como construímos o MCP da NFE.io para emitir nota fiscal pelo Claude e pelo ChatGPT

Em 29 de setembro de 2025 a OpenAI anunciou o Instant Checkout: usuários do ChatGPT nos Estados Unidos passaram a comprar de vendedores da Etsy dentro da conversa, com mais de um milhão de lojistas da Shopify na fila, tudo em cima de um protocolo aberto construído com a Stripe. Em agosto de 2026, na NFE.io, a gente colocou no ar o primeiro MCP do mercado fiscal brasileiro: você conecta o Claude, o ChatGPT ou o Copilot à sua conta e pede, em português, "emite uma nota de R$ 3.500 pra esse CNPJ".

Ou seja: a loja, o ERP e o sistema fiscal estão deixando de ser o lugar onde você opera e virando a infraestrutura por trás de uma conversa. Venho apontando isso há alguns anos e agora tenho o recibo. Este post conta como a gente construiu o nosso, o que quebrou no caminho, o que a IA se recusou a fazer e por que eu acho que em breve toda plataforma vai ter uma porta dessas aberta, do sistema fiscal ao iFood.

A visão: todo sistema vai ser operado por linguagem natural

A tese é simples de enunciar e difícil de executar. Software sempre foi uma tela entre a pessoa e um banco de dados. Você aprende onde fica o botão, decora o fluxo, treina o time. Com um modelo de linguagem no meio, a tela deixa de ser obrigatória: a pessoa diz o que quer e o modelo chama a função certa no sistema certo.

O movimento da OpenAI com Etsy e Shopify é exatamente isso aplicado a comércio: o catálogo continua na loja, o pagamento continua na Stripe, mas a compra acontece no chat. Não tem motivo para parar aí. Se dá para comprar um casaco pelo ChatGPT, dá para pedir o almoço pelo Claude. A pergunta não é se o iFood vai abrir essa porta, é quando, e em que termos.

Pra quem opera um SaaS, isso muda a pergunta de produto. Não é mais só "como fica a minha tela", é "como o meu sistema se apresenta para um modelo". E o padrão que emergiu para isso, em 2025 e 2026, foi o MCP.

O que é um MCP, sem mistério

MCP é a sigla de Model Context Protocol, um padrão aberto que a Anthropic publicou para um modelo de IA descobrir e usar ferramentas de sistemas externos. Na prática, um servidor MCP é uma lista de funções com nome, descrição e parâmetros, escrita de um jeito que o modelo entende. "Validar CNPJ, recebe um CNPJ, devolve situação cadastral." "Emitir NFS-e, recebe tomador, valor e descrição do serviço, devolve o número da nota."

Quando você conecta o servidor ao Claude ou ao ChatGPT, o modelo lê essa lista. Daí em diante, quando você pede algo em português, ele decide qual função chamar, monta os parâmetros a partir do que você escreveu, executa e traduz a resposta de volta. Nada de API, nada de planilha, nada de código para quem usa.

É por isso que a gente não construiu o MCP para dev. O público que eu tinha na cabeça era o analista fiscal e o financeiro que já usam IA no dia a dia e nunca vão abrir o Claude Code. Hoje são 13 ferramentas gratuitas liberadas assim que a conta é criada (validação de CPF e CNPJ, chave de NF-e, CST, ICMS interestadual, dados do IBGE e do Banco Central) e, no plano pago, emissão de NFS-e e consultas oficiais na Receita e nos Correios, ao mesmo preço da API.

Dados próprios

13

ferramentas gratuitas disponíveis no MCP da NFE.io assim que a conta é criada

Validações fiscais, cálculo de ICMS e dados de referência do IBGE e do Banco Central, sem cartão de crédito; emissão e consultas oficiais entram no plano pago

Como a gente construiu

O ponto de partida não foi uma folha em branco. A NFE.io já tinha um SDK em Node.js em cima da própria API, usado por clientes há anos. O MCP também é em Node.js e, por baixo dos panos, chama esse SDK. Cada ferramenta do MCP é basicamente uma função do SDK com uma descrição boa o suficiente pro modelo saber quando usá-la e um esquema de parâmetros pro modelo não inventar campo.

Essa parte foi rápida. Se você já tem uma API bem desenhada, o MCP é uma casca fina em cima dela. No total foram cerca de três semanas de desenvolvimento ativo e mais umas duas de testes e correções, e a maior parte desse tempo não foi gasta nas ferramentas. Foi gasta em outra coisa.

O que quebrou: autenticação

Um MCP que só valida CNPJ pode ser público. Um MCP que emite nota fiscal em nome da sua empresa precisa saber quem é você. Existem dois jeitos de resolver isso, e a escolha define quem consegue usar o produto.

• Chave de API. O usuário copia uma chave do painel e cola na configuração do cliente de IA. Simples de implementar para quem desenvolve o MCP, e é o que a maioria dos exemplos na internet mostra.
• OAuth. O usuário clica em "conectar", faz login na NFE.io numa tela do navegador, autoriza, e pronto. Nenhuma chave copiada, nenhum arquivo editado, e dá para revogar a qualquer momento.

Pra dev, chave de API resolve. Pra analista fiscal, não: pedir pra alguém do financeiro editar um JSON de configuração é o mesmo que não lançar. Então a gente foi de OAuth, e foi aí que o projeto ficou difícil.

Cada plataforma exige a sua própria coreografia. O Claude tem um fluxo, o ChatGPT tem outro, o Copilot outro, com diferenças em como descobrem o servidor de autorização, em quais redirecionamentos aceitam e em como registram o cliente. Coisa que funcionava no Claude quebrava no ChatGPT, e vice-versa. Teve momento em que o fluxo funcionava, o token expirava e o cliente não renovava. Não vou fingir que foi bonito: foram várias rodadas de teste em cada plataforma até fechar 100%. Fechou, mas o custo de suportar OAuth em três clientes diferentes é real e nenhum tutorial de "monte seu MCP em 20 minutos" menciona.

O que a IA se recusou a fazer

Aqui vai a parte que os gurus de IA não contam. Mesmo com tudo autenticado e funcionando, o ChatGPT se recusou, algumas vezes, a emitir a nota. O modelo interpretou "emitir documento fiscal em nome de uma empresa" como ação sensível e parou, pedindo confirmação ou simplesmente negando.

Isso não é bug. É o modelo fazendo o que a política de segurança dele manda, e eu prefiro assim a um modelo que emite nota sem pensar. Mas tem duas consequências práticas. A primeira é de produto: a descrição de cada ferramenta precisa deixar claro o que ela faz e quais confirmações já aconteceram, porque o modelo lê isso para decidir se executa. A segunda é de expectativa: "funciona 100%?" Não. Funciona muito bem na maior parte das vezes, e em algumas o modelo vai pedir para você confirmar, ou vai recusar, e você emite pelo painel. Quem vende "automação total" está vendendo o que não existe ainda.

Segurança e governança, abertamente

Vale falar claro sobre o que muda quando você abre o seu sistema para um modelo.

Autorização é o primeiro ponto, e OAuth resolve melhor que chave: o token é da pessoa, tem escopo, expira e pode ser revogado sem trocar credencial em lugar nenhum. O segundo é o que o modelo pode fazer sozinho. No nosso caso, consulta e validação são livres; emissão passa por uma conta com plano ativo e por uma ação explícita do usuário na conversa. O terceiro é rastreabilidade: cada chamada do MCP passa pela mesma API, então fica no mesmo log que a integração tradicional, com o mesmo usuário identificado.

Sobre o dado que passa pelo modelo: para emitir uma nota, nenhum dado sensível é enviado. O que trafega é CNPJ, valor e descrição do serviço, dado empresarial e em boa parte público. Dado pessoal só entra quando o tomador é pessoa física, e mesmo aí a LGPD não exige consentimento: emitir nota fiscal é cumprimento de obrigação legal, e usar o CPF do tomador para isso se apoia nessa base e no legítimo interesse (artigo 7º, incisos II e IX da lei). O que a LGPD cobra é o resto: usar o dado só para a finalidade da nota, não guardar além do necessário e saber por onde ele passou. É por isso que vale ler a política de retenção do provedor da IA antes, não depois. Conversa curta, mas com o jurídico, não com o influencer.

Será que vamos pedir iFood pelo Claude?

Vou explorar a hipótese em vez de só provocar. Hoje o pedido de comida é uma sequência de telas: abrir o app, escolher o restaurante, montar o pedido, confirmar o endereço, pagar. Cada tela existe porque o sistema precisa de uma informação e não tem como perguntar de outro jeito. Um modelo tem. "Pede o de sempre do japonês, mas sem cebolinha, e usa o cartão da empresa" resolve as cinco telas em uma frase, desde que o iFood exponha três funções: buscar cardápio, montar pedido, pagar. É o mesmo desenho do Instant Checkout da OpenAI, só que com comida.

Tecnicamente, nada impede. O que decide é a conta do iFood, não a nossa. Enquanto a tela for onde ele vende destaque, cupom e anúncio de restaurante, abrir a porta para o modelo significa entregar essa vitrine para a OpenAI ou para a Anthropic. Por isso a minha aposta é uma sequência, não um salto: primeiro o modelo entra como assistente dentro do app, depois consultas e reposição de pedido saem pelo chat, e por último a compra completa, quando a plataforma tiver negociado quem fica com o cliente. A Shopify já está na segunda fase. O iFood vai chegar lá quando a concorrência no chat doer mais do que a perda da vitrine.

E o que isso diz sobre a gente? Que a interface de conversa devolve o pedido ao formato mais antigo que existe: falar com alguém e ser entendido. O app foi um desvio de vinte anos. A parte nova é que o "alguém" do outro lado nunca cansa, lembra de tudo e representa, ao mesmo tempo, você e a plataforma. É aí que os conflitos aparecem.

Os conflitos que isso acende

Se a interação passa a acontecer no chat, quem é dono do cliente? Hoje o lojista da Shopify tem a loja; amanhã a compra acontece no ChatGPT e a marca vira um fornecedor atrás de uma interface que não controla. O mesmo vale pro iFood, pro banco e pro ERP. A plataforma que abre a porta ganha distribuição; a que não abre vira invisível para quem já opera por IA. Nenhuma das duas opções é confortável, e é por isso que o padrão aberto importa: com MCP, o sistema é seu, o token é do usuário, e você decide o que expõe.

Tem também um conflito humano. Parte do valor de um sistema estava em saber operá-lo. Quando "saber onde fica o botão" deixa de valer, o valor migra para saber o que pedir e conferir o que voltou. É a mesma conversa da capacitação: quem entende o processo fiscal vai extrair muito mais desse MCP do que quem só sabe digitar.

Por que isso importa para quem tem um produto

Três motivos, na ordem em que eu vi acontecer.

Distribuição. Um MCP coloca o seu produto dentro da ferramenta que a pessoa já usa o dia inteiro. Na NFE.io, na primeira hora após o anúncio, mais de 130 leads responderam com intenção de testar, e boa parte era perfil que nunca teria lido a documentação da API. Foi o lançamento com a resposta mais rápida que eu vi por aqui.

Dados próprios

+130

leads com intenção de testar na primeira hora após o anúncio do MCP

Respostas ao lançamento em agosto de 2026, boa parte de perfis que nunca tinham usado a API

Redução de atrito. Conta em 2 minutos, um clique para conectar, e o primeiro CNPJ validado antes de qualquer contrato. O funil que antes passava por "tem dev na sua empresa?" agora começa por "você usa Claude ou ChatGPT?".

Posicionamento. Ser o primeiro do mercado fiscal a fazer isso diz algo sobre a empresa que nenhuma campanha diz. Marca que se apresenta bem para um modelo vai ser a marca que o modelo recomenda.

Se você quiser ver na prática, a gente gravou um workshop gratuito de quatro aulas mostrando a configuração passo a passo, em português, sem código.

O que eu faria diferente

Começaria pelo OAuth desde o primeiro dia, testando nos três clientes em paralelo, em vez de fechar em um e portar para os outros. Escreveria as descrições das ferramentas pensando na política de segurança do modelo, não só na função. E colocaria observabilidade por ferramenta antes do lançamento, porque a primeira pergunta do time comercial foi "quantas emissões vieram pelo MCP?", e eu queria ter respondido na hora.

Ainda assim, o principal continua de pé: isso não é mais o futuro do software, é presente. Sistema que não fala com modelo vai ser sistema que ninguém lembra de abrir.