Como conectar sistemas a agentes de IA via MCP: 3 estratégias
Três caminhos que usamos em produção para conectar sistemas existentes a agentes de IA via MCP — do protótipo em dias à integração estrutural.
Por Isabele Santos, em coautoria com Fernando Junior.
Atualmente usamos 3 caminhos possíveis, que nos permitem explorar bem o que o MCP oferece. O MCP (Model Context Protocol) é um protocolo aberto criado pela Anthropic e hoje adotado pelos principais players do mercado. O que na prática o tornou o "USB-C" da IA corporativa: em vez de construir um conector artesanal para cada par modelo-sistema, você constrói um servidor MCP uma única vez e qualquer cliente compatível se conecta a ele.
O protocolo expõe três primitivas: Resources (dados que o modelo pode ler para obter contexto), Prompts (templates reutilizáveis para fluxos padronizados) e Tools (funções que o modelo pode invocar para executar ações reais, seja buscar um registro, disparar um evento, alterar um status).
Implementamos três estratégias em produção no último ano, e isso tem reduzido gastos e dores de cabeça. Daí surge o questionamento: o que custa, hoje, não implementar esse protocolo? O estudo do MIT (Projeto NANDA) mostrou que cerca de 95% dos pilotos de IA generativa empresarial não geram impacto mensurável no P&L — apontando falhas de integração empresarial como o problema central, não a qualidade dos modelos. Isso sobre um investimento estimado de US$ 30–40 bilhões em GenAI, com 95% das organizações obtendo retorno zero. Na maioria dos casos, o gargalo está na dificuldade de manutenção de integrações distintas, que custam tempo e dinheiro além de serem ineficientes. Fica claro que um dos gargalos atuais da IA corporativa é a integração dos modelos aos sistemas, e não a qualidade deles em si. (Fonte: "The GenAI Divide: State of AI in Business 2025", MIT Projeto NANDA, via Fortune)
O estudo atribui a falha ao "learning gap" e à integração com fluxos reais.
E como nosso time escolheu contornar esse problema? Justamente com a aplicação de três estratégias, que variam em isolamento e esforço, apresentadas por Fernando Junior, nosso Líder de Desenvolvimento, a partir do que aplicamos em produção.
— Isabele Santos
Estratégia 1 — Proxy + Swagger#
Fluxo de dados: LLM → MCP Server (atuando como Proxy) → API HTTP REST existente.
Automação: o servidor lê arquivos Swagger/OpenAPI nativamente e gera as "tools" no LLM de forma 100% automática.
Custo zero no legado: zero mudança necessária no código do backend original.
Cenário ideal: perfeito para prototipar rapidamente, integrar APIs externas ou plugar sistemas legados onde alterações de código são complexas.
O limite dessa abordagem: a qualidade das tools geradas é a qualidade da sua documentação OpenAPI. APIs mal descritas geram tools que o modelo usa mal. É a estratégia certa para começar em dias — não para ser o destino final de um produto.
Estratégia 2 — Projeto Simples (Read-Only)#
Micro-server enxuto: desenvolvemos projetos simplificados onde o MCP Server dispensa as camadas profundas e complexas de uma aplicação web comum. Ele foca exclusivamente em expor Tools com scripts SQL predefinidos e estritos, eliminando a complexidade do roteamento HTTP.
Execução segura (leitura): todas as instruções disponibilizadas para a IA são garantidamente limitadas à operação Read-Only no banco de dados. Esta abordagem cria uma base rápida e eficiente para relatórios, validação de contextos e BI Conversacional sem riscos estruturais.
— Fernando Junior
Essa é a resposta estrutural à pergunta que todo gestor faz: "e se a IA apagar meu banco?". Aqui a garantia não é uma instrução no prompt pedindo para a IA se comportar, é arquitetura. O modelo só tem acesso a consultas predefinidas, de leitura, e nada além disso existe para ele. Segurança por construção, não por confiança.
— Isabele Santos
Estratégia 3 — Integrado via Clean Architecture#
Múltiplas entradas: nossa arquitetura moderna permite que a mesma regra de negócio seja acionada tanto via Controller HTTP tradicional quanto via o novo canal MCP.
Adapter MCP: o MCP Tool Handler é programado apenas como um novo adapter na camada de interface da nossa Clean Architecture, encapsulando a complexidade do protocolo.
Regra inalterada: o lema é "Nova porta, mesma casa". Nossos Use Cases e Core Domain permanecem totalmente inalterados, seguros e reutilizados sem duplicação de lógica.
MCP não quebra o que já existe: o MCP atua apenas como mais uma porta de entrada lateral, operando em paralelo com os controladores existentes. Mantemos o Princípio de Separação de Responsabilidades intacto, isolando clientes humanos de agentes de inteligência artificial. A Clean Architecture nos permite garantir que a regra de negócio (Use Cases) não perceba a diferença entre uma chamada HTTP convencional e uma execução gerada pelo LLM.
Depois da implementação: o que aprendemos operando MCP em produção#
Colocar um servidor MCP no ar é a parte fácil. O que sustenta a operação vem depois — e três frentes merecem destaque porque são exatamente o que diferencia quem operou de quem só leu a documentação:
1. Segurança começa na conexão, não no prompt. Na nossa implementação, a identificação rigorosa do client acontece no momento da inicialização da conexão com o server, via API Key trafegada em header HTTP. E a autorização é dinâmica: os dados expostos — e até mesmo quais Tools aparecem listadas — são filtrados de acordo com as permissões do agente conectado. Um agente de BI não enxerga as mesmas ferramentas que um agente de operações; ele nem sabe que elas existem. O roadmap natural dessa camada é a adoção completa de OAuth 2.0 e JWTs, padrão de mercado.
2. Valide o server isolado antes de plugar o LLM. A melhor prática de fluxo de trabalho que adotamos: testar Tools e Resources localmente com o MCP Inspector (a UI oficial de debugging, que sobe com um comando npm) antes de acoplar o servidor a qualquer cliente LLM. O Inspector permite executar cada Tool via clique, preencher o payload de entrada, analisar o array de saída e — crucial — inspecionar o tráfego JSON-RPC bruto na aba History. Debugar protocolo junto com comportamento de modelo é somar duas incertezas; separar as duas economiza horas.
3. Erros são parte do contrato. O padrão de retorno do MCP prevê o flag isError: true para falhas tratáveis — e isso muda o jogo: o modelo interpreta a falha e pode corrigir os próprios argumentos e tentar de novo, sem intervenção humana. Desenhar boas mensagens de erro deixou de ser cosmético; virou parte da interface com o agente.
— Fernando Junior
O efeito colateral mais valioso de tudo isso seria a portabilidade. Um server MCP construído hoje funciona amanhã em qualquer ecossistema que adote o protocolo, do Claude Desktop a IDEs como Cursor e VS Code, e até as nossas próprias aplicações. O investimento de integração deixou de ser descartável a cada troca de fornecedor de modelo.
O diagnóstico do MIT não diz que a IA generativa falhou. Diz que a integração falhou. E integração é um problema de engenharia com solução já conhecida: padrão único em vez de dezenas de conectores artesanais. As três estratégias que apresentamos não são teoria, mas os três degraus que usamos em produção, do protótipo em dias (Proxy + Swagger) ao acesso seguro a dados (Read-Only) até o produto de longo prazo (Clean Architecture). A régua de decisão é simples de entender: quanto mais maduro e crítico o sistema, mais estrutural deve ser a integração.
Quem constrói essa fundação agora não está apostando em um fornecedor, mas construindo a porta pela qual qualquer agente de IA vai entrar na sua operação. Foi exatamente essa fundação que a gente levou para dentro do Zihin: a plataforma já nasce falando MCP, com servidor remoto pronto para conectar seus sistemas aos agentes sem projeto artesanal de integração — com governança e segurança desde a conexão. Se o seu time está travado na fase de piloto, provavelmente o problema não é o modelo, é a ponte. Agende um diagnóstico e veja na prática como plugar seus dados e ações a agentes de IA governados.
— Isabele Santos
Q&A#
Por onde começar a implementar MCP na minha empresa?
Pela estratégia de menor risco: um proxy MCP sobre uma API existente bem documentada (Swagger/OpenAPI), ou um micro-server read-only sobre uma base de dados de relatórios. Ambos entregam valor em dias, sem tocar no código legado, e servem de aprendizado antes de integrações estruturais.
MCP funciona só com o Claude?
Não. O MCP nasceu na Anthropic, mas é um protocolo aberto adotado pelos principais ecossistemas de IA do mercado. Um servidor MCP construído hoje funciona com qualquer cliente compatível — modelos, IDEs e aplicações próprias.
É seguro dar acesso ao banco de dados para uma IA?
Depende de como o acesso é construído. Com um MCP server read-only expondo apenas consultas predefinidas, a IA estruturalmente não consegue alterar nada — a limitação está na arquitetura, não em instruções de comportamento. Para escrita, o caminho é expor Use Cases específicos com autorização por agente, nunca acesso direto ao banco.
Preciso reescrever meus sistemas para usar MCP?
Não. As três estratégias deste artigo existem justamente para evitar isso: proxy sobre APIs existentes (zero mudança), micro-server paralelo (zero mudança) ou um novo adapter na camada de interface (mudança mínima e isolada). A regra de negócio permanece intacta.