MCP vs SQL chatbot custom: quando cada um ganha
Por que escolhemos MCP para o demo público da Acme Store, e em que casos um SQL chatbot proprietário ainda faz mais sentido. Critérios, não religião.
por Jonatas Zechim
Toda vez que um cliente nos pede um agente que "conversa com os dados", existe a mesma bifurcação de arquitetura.
Opção A: construir um SQL chatbot custom. Frontend próprio. Backend próprio. Conexão direta com o banco. Tudo nosso.
Opção B: expor os dados via MCP (Model Context Protocol). Qualquer cliente MCP-aware (Claude Desktop, Cursor, Claude Code, Cline) pode conectar. A gente foca no servidor MCP, não no chat.
Ambos funcionam. A escolha errada custa meses. Esse post é sobre os critérios que usamos.
O que MCP é, em uma frase
MCP é um protocolo padronizado pra LLMs conversarem com ferramentas externas. Seu banco vira um servidor MCP. Qualquer assistente de IA fala com seu servidor MCP usando a mesma linguagem.
Pense em "REST para LLMs". O Claude Desktop tem cliente MCP nativo. Cursor também. Claude Code também. Em vez de cada um inventar o próprio jeito de "ligar ao banco", todos falam MCP.
Quando MCP ganha
Os usuários já vivem em um cliente MCP-aware. Se seu time de engenharia usa Cursor todo dia ou seus analistas usam Claude Desktop, expor seu warehouse como MCP os deixa "perguntar para os dados" sem mudar de janela. Sem treinar ninguém. Eles abrem o cliente que já usam.
Você não quer construir UI de chat. Construir um chat decente é maior do que parece. Streaming, tool calls visualizadas, tabela renderizada inline, histórico, autenticação, mobile. Se a UI não é seu diferencial, deixar o cliente MCP do usuário fazer esse trabalho economiza meses.
O caso de uso é developer-heavy. Engenheiros, devops, analistas técnicos preferem ficar no editor / terminal. MCP atende esse público nativamente.
Você quer compor com outras fontes. O Claude Desktop pode estar conectado ao seu warehouse + ao GitHub + ao Notion ao mesmo tempo. Perguntas que cruzam fontes ("liste os PRs abertos do João e quanto a feature dele rendeu") ficam triviais sem você precisar integrar nada. MCP compõe.
Você quer ser openable por terceiros. Se sua oferta é uma plataforma e clientes vão conectar IAs próprias, MCP é a escolha. É o jeito padrão de ser API-compatível com IAs em 2026.
Quando SQL chatbot custom ainda ganha
O usuário não é técnico. Sua tia que vende confeitaria não vai abrir o Claude Desktop. Ela quer um app simples, no celular, com botão grande. Pra ela, você constrói uma UI dedicada e o MCP fica como detalhe de implementação opcional.
A UX precisa ser disputada. Se seu diferencial competitivo é a experiência de chat (animações, gráficos custom, fluxos guiados, multimodal), você precisa controlar a UI ponta-a-ponta. MCP delega o controle de UI ao cliente do usuário.
A integração precisa ser deep. Se o agente precisa abrir um modal de aprovação, atualizar um campo em outra tela, lançar notificação push - esses fluxos vivem no SEU app. Não dá pra delegar pro Claude Desktop.
Você quer rastrear conversões. Quem perguntou o quê, quando, e o que fez depois? Em chat próprio você tem analytics. Em MCP a conversa fica do lado do cliente; o que você vê é só "alguém chamou minha tool de query".
Compliance proíbe expor. Em alguns regimes (financeiro, saúde), expor um endpoint que LLMs externos podem chamar diretamente é proibido sem aprovação. Chat próprio mantém tudo dentro da sua fronteira.
A escolha que a gente faz para o demo
O demo em zechim.com/demo tem AMBAS as superfícies. Por design.
A página /demo é um SQL chatbot custom. Streaming, tool calls visualizadas, render de tabela inline, CTAs de conversão. UX 100% nossa.
A página /demo/connect oferece a versão MCP. Você pega uma chave grátis, cola no Claude Desktop, e pergunta de dentro do seu editor. Mesma fonte de dados, cliente diferente.
Por que ambas? Porque os dois públicos existem. O visitante casual que cai no site quer o chat bonito que funciona em um clique. O engenheiro técnico que está avaliando se a gente sabe o que faz quer plugar no Cursor dele em 30 segundos.
Ambas as superfícies passam pelo mesmo servidor MCP por baixo. O /api/chat conecta no /api/mcp via header de bypass interno. O Claude Desktop conecta no /api/mcp via API key. Mesma porta, mesma tool, mesmas guardrails, mesmo controle de quota.
Isso é o ganho silencioso do MCP: mesmo quando você constrói chat próprio, expor o motor como MCP custa pouco e te dá superfície adicional de graça.
Como decidir no seu caso
Três perguntas:
- Quem é o usuário principal? Técnico (Cursor / Claude Desktop) ou geral (app no celular)?
- A UX faz parte do produto? Se sim, chat próprio. Se não, MCP.
- Quanto compliance restringe? Quanto mais restritivo, mais custom.
Quase nunca é zero-sum. A resposta sensata na maioria dos casos é: chat próprio pra o usuário principal, MCP exposto pro técnico aproveitar. Foi o que fizemos no demo. É o que a gente recomenda na maioria dos projetos.
Se você está nessa bifurcação no seu projeto, vale uma conversa. Ajudamos a desenhar a arquitetura antes do código sair errado.