Bruno Luis Lucarelo Lamonato; Denis Bruno Viríssimo

DOI: 10.22167/2675-6528-202600626

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

A integração de Grandes Modelos de Linguagem (LLMs) com Sistemas de Planejamento de Recursos Empresariais (ERP) apresenta desafios arquiteturais complexos, decorrentes da incompatibilidade entre lógicas probabilísticas e determinísticas, que demandam novas arquiteturas de software, orquestração segura de APIs e mecanismos de cache robustos. Diante disso, projetou-se e implementou-se um gateway de integração em .NET, orientado ao Model Context Protocol (MCP), com o propósito de conectar agentes de Inteligência Artificial ao ERP Bling. A metodologia empregou uma abordagem baseada em Arquitetura Limpa, desenvolvendo um conector que gerenciava autonomamente tokens, persistência de dados, estratégias de cache e tarefas em segundo plano. Testes experimentais foram conduzidos com LLMs avançados para análises de vendas e projeções de estoque em um ambiente estruturado. Os resultados indicaram que o sistema reduziu significativamente a latência das consultas operacionais por meio do cache, diminuindo o tempo de processamento de uma tarefa de aproximadamente 44 minutos para menos de 5 minutos, e superou as limitações de requisição da interface externa. Observou-se, ademais, que a tipagem estrita do protocolo atuou como barreira eficaz contra alucinações, compelindo os agentes à precisão algorítmica e viabilizando a orquestração autônoma de múltiplas ferramentas. Concluiu-se que a padronização proporcionada por essa camada intermediária transformou o sistema de gestão em uma plataforma apta ao raciocínio lógico, facilitando a automação complexa e a tomada de decisão estratégica segura.

Palavras-chave: Arquitetura Limpa; Automação; Grandes Modelos de Linguagem; Inteligência Artificial; Sistema Legado.

1. Introdução

No cenário contemporâneo de gestão empresarial, a transformação digital é um requisito fundamental. Sistemas de Planejamento de Recursos Empresariais (ERPs) consolidaram-se como a espinha dorsal das operações corporativas, centralizando dados e otimizando processos essenciais (Oliveira e Ramos, 2002). No e-commerce brasileiro, plataformas como o Bling são cruciais, fornecendo infraestrutura para PMEs operarem em múltiplos canais. A eficiência dessas operações depende da integração entre esses sistemas e novas ferramentas de automação.

Paralelamente, a indústria de software testemunha uma mudança de paradigma impulsionada pelos Grandes Modelos de Linguagem (LLMs) e pela Inteligência Artificial Generativa. Essa evolução permitiu a transição para “agentes” capazes de raciocínio lógico, planejamento e execução de tarefas (Sarferaz, 2025). A literatura destaca o conceito de “Tool Use” ou “Function Calling”, onde modelos de IA identificam a necessidade de consultar sistemas externos para responder a solicitações do usuário com dados em tempo real (Niederwieser et al., 2025).

Apesar do potencial, a integração prática entre a natureza probabilística dos LLMs e a natureza determinística das Interfaces de Programação de Aplicações (APIs) empresariais apresenta desafios arquiteturais complexos. ERPs robustos, como o Bling, operam sob contratos de interface rígidos, exigindo autenticação segura via OAuth 2.0, respeito a limites de taxa de requisição e validação precisa de esquemas de dados. Conectar um agente de IA diretamente a essas APIs sem uma camada intermediária de abstração frequentemente resulta em falhas operacionais, como alucinações de endpoints, erros de autenticação ou incapacidade de lidar com a paginação de grandes volumes de dados (Vedanbhatla, 2025).

Diante desses desafios, o Model Context Protocol (MCP) propõe um padrão aberto para superar barreiras como interfaces sem estado e controles de segurança ad-hoc, visando normalizar o consumo de recursos externos por IAs via JSON-RPC orientado a sessões (Ray, 2025). A adoção desse protocolo, combinada com plataformas como o Microsoft .NET, é facilitada por um SDK C# oficial (Model Context Protocol, 2026) que suporta o gerenciamento do ciclo de vida e “parsing” de mensagens. A utilização de gateways de API, alinhada à arquitetura do MCP, busca abstrair a complexidade das interações entre cliente e servidor, permitindo que desenvolvedores foquem na lógica de negócio (Ray, 2025). Essa abordagem encapsula regras de sistemas complexos, expondo ao agente de IA apenas ferramentas negociadas e autorizadas, minimizando riscos de segurança.

A literatura já explora a integração de agentes de IA em sistemas de gestão, como proposto por Niederwieser et al. (2025) com sistemas ERP impulsionados por inteligência artificial. Contudo, essas abordagens frequentemente dependem de integrações ad-hoc ou frameworks específicos de linguagem. Até o momento desta pesquisa, não foram encontrados trabalhos que implementem essa integração utilizando o Model Context Protocol (MCP) como padrão de interoperabilidade universal para sistemas legados, o que destaca o caráter inovador e exploratório da presente proposta. A relevância reside na demonstração prática de como arquiteturas modernas podem revitalizar a interação com sistemas legados, permitindo que gestores utilizem linguagem natural para realizar consultas complexas de vendas, análise de clientes, auditorias de estoque e operações financeiras.

Para viabilizar essa proposta, o projeto adotou uma abordagem de desenvolvimento orientada a interfaces, implementando um conector que gerencia autonomamente o ciclo de vida dos tokens de acesso, a persistência de dados e a orquestração das chamadas à API do Bling. A solução busca aderência a princípios de manutenibilidade e extensibilidade, essenciais para software corporativo. Estratégias de cache e processamento de tarefas em segundo plano revelaram-se indispensáveis para a viabilidade operacional, garantindo a fluidez da interação e prevenindo interrupções por tempo de limite excedido. Adicionalmente, a tipagem estrita imposta pelo protocolo atua como barreira arquitetural efetiva contra alucinações, forçando os modelos de linguagem a operarem com precisão determinística na extração e manipulação dos dados. Diante do exposto, este trabalho teve por objetivo projetar e implementar um gateway de integração desenvolvido na plataforma .NET, utilizando-se do MCP para conectar agentes de Inteligência Artificial a um ERP de mercado (Bling), permitindo a autenticação segura, a consulta estruturada de dados e a automação de processos de análises de pedidos e estoques através de interfaces padronizadas.

2. Material e Métodos

A presente pesquisa adotou uma abordagem de desenvolvimento de software, de natureza aplicada e exploratória, com o objetivo de projetar e implementar um gateway de integração. A metodologia foi orientada pelos princípios da Arquitetura Limpa (Martin, 2017), visando o desacoplamento entre as camadas do sistema e a promoção da manutenibilidade e extensibilidade. O estudo buscou validar a viabilidade técnica do gateway e demonstrar a capacidade de agentes de Inteligência Artificial em realizar análises de negócio a partir de dados reais de um ERP.

O desenvolvimento do sistema foi realizado utilizando a plataforma .NET 9.0, selecionada por sua robustez e desempenho em ambientes de microsserviços. O ERP integrado foi o Bling (Bling, 2026), que forneceu uma API completa para gerenciamento de pedidos e controle de estoque, utilizando autenticação OAuth 2.0. Para a persistência de dados transitórios, tokens de autenticação e cache distribuído, empregou-se o banco de dados relacional PostgreSQL, escolhido por seu suporte a tipos de dados JSON Binário (JSONB) e conformidade ACID (PostgreSQL Global Development Group, 2026).

O ambiente de desenvolvimento utilizado foi o Visual Studio Community 2022, com gerenciamento de pacotes e dependências via NuGet. O SDK oficial do Model Context Protocol (ModelContextProtocol.AspNetCore) foi incorporado para facilitar a implementação do protocolo. Uma chave de API do Bling, com escopos de leitura, foi fornecida por uma empresa de e-commerce brasileira, localizada no estado de São Paulo, para acesso aos dados operacionais.

A arquitetura do sistema foi organizada em quatro módulos principais. O módulo Bling.Mcp (Presentation) atuou como servidor, expondo as ferramentas via protocolo MCP (stdio). O Bling.Application (Application) funcionou como camada intermediária, orquestrando a lógica de negócio por meio de Use Cases e definindo interfaces. O Bling.Domain (Domain) continha as entidades de negócio e enumerações, enquanto o Bling.Infrastructure (Infrastructure) foi responsável pelas implementações concretas dos repositórios, autenticação OAuth 2.0, gerenciamento de cache, tarefas em background e armazenamento de tokens.

A comunicação com o ERP Bling foi realizada através de sua API v3 (Bling, 2026). Para abstrair a complexidade das requisições HTTP, definiu-se a interface IBlingApiGateway na camada Application, implementada pela classe BlingApiGateway na camada Infrastructure. Essa implementação gerenciava automaticamente a autenticação transparente, a resiliência via retry com backoff exponencial em casos de limites de taxa de requisição (HTTP 429) ou erros de autenticação (HTTP 401), e a telemetria de chamadas via ApiTelemetryService.

O serviço BlingOAuthService gerenciou o fluxo completo de OAuth 2.0 (Authorization Code Flow), implementando a interface IAuthService. Suas responsabilidades incluíram a geração da URL de autorização com proteção CSRF, a captura do callback de autorização, a troca do código por Access Token e Refresh Token, e o gerenciamento do ciclo de vida dos tokens, realizando a renovação automática antes da expiração. A persistência dos tokens foi abstraída pela interface ITokenStorage, com implementações em arquivo para testes locais e em banco de dados PostgreSQL para produção.

Para otimizar o tempo de resposta e reduzir o consumo da cota de requisições da API do Bling, implementou-se uma estratégia de cache robusta através do serviço BlingPostgresCacheService. A interface ICacheService ofereceu modos de armazenamento permanente (Set) e com Tempo de Vida configurável (SetWithTtl), além de operações de leitura, remoção e contagem. A camada de persistência em PostgreSQL foi projetada com a tabela `mcp_cache`, que armazenava objetos em formato JSONB e marcadores de ciclo de vida, com um índice atrelado ao campo `expires_at` para mitigar gargalos de performance.

A lógica de consulta seguiu o padrão Cache-Aside: o caso de uso verificava a existência e validade da informação no cache (PostgreSQL); em caso de Cache Hit, a resposta era retornada imediatamente; em caso de Cache Miss, a requisição era feita à API do Bling e o resultado era armazenado com Tempo de Vida (TTL) configurável ou de forma permanente. Adicionalmente, o CacheManagementUseCase ofereceu operações explícitas de gerenciamento de cache, como refresh e invalidação por categoria.

A camada de apresentação para os agentes de Inteligência Artificial foi construída sobre o Model Context Protocol (MCP). O sistema expôs 31 ferramentas (Tools) individuais, distribuídas em 10 classes, mapeadas diretamente para os serviços de domínio. O registro das ferramentas utilizou uma extensão customizada para contornar uma limitação do SDK MCP C# 0.5.0-preview.1, garantindo que parâmetros opcionais fossem corretamente marcados no JSON Schema gerado. Cada ferramenta, decorada com o atributo [McpServerTool], expôs um esquema JSON detalhado que instruía o modelo de linguagem sobre a interação com o ERP.

As ferramentas foram categorizadas em Operacionais (PedidoTools, ProdutoTools), Analíticas (AnalyticsTools, ContatoAnalyticsTools), Financeiras (FinanceiroTools), Auxiliares (AuxiliarTools, ContatoTools, AuthTools) e Gerenciamento (CacheTools, BackgroundTaskTools). Os Casos de Uso foram divididos em Casos de Uso de Consulta (Read-Only), focados na recuperação de dados, e Casos de Uso de Análises (Analytics), especializados em processamento agregado em memória. A filtragem de situações de pedidos foi realizada pelo chamador (camada MCP Tools) por meio do parâmetro `idsSituacoes` no `PedidoFiltrosDto`, e o prompt de sistema (`SYSTEM_MESSAGE.md`) orientou o modelo de linguagem sobre as chamadas.

Para validar a viabilidade técnica do gateway, conduziu-se um experimento estruturado em etapas sequenciais. Os dados operacionais utilizados foram reais, captados através da API do Bling, com os nomes dos produtos ocultados por conterem registro de marcas protegidas. As métricas de avaliação definidas foram: (i) tempo total de processamento, (ii) throughput (taxa de transferência) e (iii) erro ou acerto na orquestração. O experimento avaliou o desempenho em duas condições operacionais: um ambiente sem o uso do mecanismo de persistência (Cache Miss) e um ambiente com os dados previamente armazenados (Cache Hit).

O servidor MCP foi compilado como executável autônomo (Bling.Mcp.exe) e configurado no software Antigravity (Google, 2026) versão 1.20.6, por meio de um arquivo de configuração JSON (`mcp_config.json`). Este arquivo especificava o caminho do executável, as credenciais OAuth 2.0 (Client ID e Client Secret) e o caminho para o arquivo de persistência de tokens (`bling_tokens.json`). O transporte utilizado foi o STDIO (Standard Input/Output), conforme especificação do protocolo MCP para clientes desktop. A cada inicialização, o servidor MCP realizava automaticamente a verificação e renovação do token OAuth 2.0.

Definiram-se dois cenários de teste, cada um executado com os modelos de linguagem Claude Opus 4.6 (Thinking) e Gemini 3.1 Pro (Thinking), totalizando quatro execuções experimentais. No primeiro cenário, instruiu-se o agente a consultar todos os pedidos de venda do mês de janeiro de 2026, excluindo pedidos cancelados, e a gerar um relatório executivo. No segundo cenário, o agente foi instruído a consultar o estoque dos 10 produtos mais vendidos de janeiro de 2026, prever a demanda para os próximos 2 meses (60 dias) e gerar um Plano de Ressuprimento. Em ambos os casos, o modelo foi instruído utilizando o arquivo `SYSTEM_MESSAGE.md`.

3. Resultados e Discussão

A integração de Grandes Modelos de Linguagem (LLMs) com o Sistema de Planejamento de Recursos Empresariais (ERP) Bling, mediada por um gateway desenvolvido em .NET e orientado ao Model Context Protocol (MCP), revelou a viabilidade e a eficácia de uma arquitetura robusta para automação e análise de dados. Os resultados demonstraram que a solução proposta superou desafios inerentes à incompatibilidade entre lógicas probabilísticas e determinísticas, garantindo autenticação segura, consulta estruturada de dados e automação de processos de análises de pedidos e estoques. A arquitetura do sistema foi organizada em módulos distintos, como Bling.Mcp (Presentation), responsável por expor as ferramentas via protocolo MCP; Bling.Application (Application), que orquestrava a lógica de negócio; Bling.Domain (Domain), contendo as entidades de negócio; e Bling.Infrastructure (Infrastructure), que implementava o acesso à API Bling v3, autenticação OAuth 2.0, gerenciamento de cache e tarefas em background.

As ferramentas expostas pelo servidor MCP incluíram categorias operacionais, como PedidoTools e ProdutoTools para consultas diretas; analíticas, como AnalyticsTools e ContatoAnalyticsTools para análises agregadas de vendas e clientes; financeiras, com FinanceiroTools para contas a receber e pagar; e auxiliares, como AuxiliarTools, ContatoTools e AuthTools para metadados e autenticação. Adicionalmente, ferramentas de gerenciamento, como CacheTools e BackgroundTaskTools, foram implementadas para otimizar o desempenho e a orquestração. Os casos de uso foram divididos em consulta (read-only) e análise (analytics), permitindo desde a listagem de pedidos com paginação automática até a obtenção de balancetes simplificados e análises agregadas de vendas e clientes. A camada de infraestrutura forneceu serviços como BlingApiGateway para requisições HTTP com retry e telemetria, BlingOAuthService para autenticação OAuth 2.0, e BlingPostgresCacheService para cache persistente, além de repositórios específicos para pedidos, produtos, contatos e dados financeiros.

Primeiro Cenário

A execução do primeiro cenário de testes, focado na geração de um relatório executivo de vendas para janeiro de 2026, foi conduzida inicialmente com o modelo Gemini 3.1 Pro (Thinking) em uma condição de dados não cacheados (Cache Miss). O agente demonstrou uma notável capacidade de raciocínio sequencial (Chain of Thought) ao consultar autonomamente as situações do ERP, identificando corretamente o ID 12, que correspondia a “Cancelado”, para aplicar o filtro exigido no prompt. Em seguida, o agente orquestrou a execução de tarefas analíticas assíncronas para gerar um resumo de vendas, a evolução diária e o ranking de produtos, evidenciando a capacidade de automação de processos complexos.

Devido à ausência de dados em cache e à necessidade de consolidar aproximadamente 5.200 pedidos de venda de um mês inteiro, o processamento demandou um tempo total de quase 44 minutos. Essa latência inerente à API do ERP Bling justificou a adoção da arquitetura de tarefas em background (BackgroundTaskTools) no gateway, que se mostrou essencial para evitar o timeout da conexão HTTP padrão e do próprio chat do software Antigravity. Durante a longa espera, o agente de inteligência artificial exibiu um comportamento proativo, porém incorreto, ao inferir que a demora indicava um problema e disparar uma nova requisição amostral limitada a 500 pedidos. Essa situação exigiu uma intervenção manual do usuário para cancelar a tarefa paralela, validando a resiliência da arquitetura e o suporte ao padrão Human-in-the-Loop.

Ao término dos 44 minutos de processamento, e após uma nova solicitação do usuário para verificar o estado da tarefa, o modelo retomou o fluxo de trabalho com precisão. O agente leu os resultados com sucesso, manipulou os arquivos locais e injetou o array JSON contendo o faturamento, de aproximadamente R$ 217 mil, e os 10 produtos mais vendidos diretamente na estrutura do arquivo HTML gerado. Essa etapa final confirmou a integridade das ferramentas de formatação disponibilizadas pelo MCP, entregando um relatório estático consolidado que forneceu dados concisos e completos para decisões de negócio. A capacidade de orquestração autônoma e a manipulação de grandes volumes de dados, mesmo em condições de alta latência, foram pontos cruciais validados neste teste.

A execução do segundo teste do primeiro cenário, utilizando o modelo Claude Opus 4.6 (Thinking) com o mesmo prompt e system message, mas desta vez operando sob condições de dados já armazenados no cache, demonstrou a robustez arquitetural da solução e a otimização de desempenho. O sistema utilizou o cache construído anteriormente pelo método “ListarAsync” na implementação do repositório “BlingPedidoRepository”. A persistência de dados via PostgreSQL provou ser eficaz, reduzindo drasticamente o tempo total de processamento de quase 44 minutos para apenas 4 minutos e 56 segundos, para a análise de 5.214 pedidos e 167 Stock Keeping Units (SKU) diferentes.

Além do ganho expressivo de performance, o modelo Claude Opus 4.6 orquestrou as chamadas de ferramentas de forma contínua e assertiva, sem as hesitações observadas no teste anterior, onde não havia dados em cache. O agente compreendeu o contexto das tarefas em background e concluiu o fluxo de trabalho sem necessidade de intervenção manual. O relatório estático consolidado gerado foi 100% idêntico ao obtido no teste anterior, validando o determinismo do sistema. Essa consistência absoluta nos dados de saída evidencia que a abstração fornecida pelo gateway e a tipagem estrita imposta pelo esquema JSON do protocolo MCP atuam como barreiras eficazes contra alucinações, forçando modelos probabilísticos a operar com precisão algorítmica sobre os dados reais do ERP, do mecanismo de cache e de suas ferramentas.

Segundo Cenário

A execução do segundo cenário de testes, destinado à elaboração de um Plano de Ressuprimento de Estoque para 60 dias, foi realizada primeiramente com o modelo Gemini 3.1 Pro (Thinking) e evidenciou a notável capacidade de orquestração multi-etapas do gateway. O ensaio iniciou-se com o agente validando proativamente o token OAuth, utilizando a ferramenta mcp_verificar_autenticacao, e acionando a busca assíncrona pelos produtos mais vendidos através da ferramenta analytics_top_products. Após monitorar o progresso da tarefa de agregação por cerca de 5 minutos, o sistema retornou com sucesso o ranqueamento dos itens que compunham a curva ABC de vendas, demonstrando a eficiência na recuperação e organização de dados.

O aspecto mais relevante deste cenário foi a resolução de um problema de negócio complexo na ausência de uma ferramenta analítica específica para o cálculo de ressuprimento. O modelo Gemini 3.1 Pro compreendeu logicamente que o endpoint de análise de vendas não continha os saldos de estoque atuais necessários para a projeção. Demonstrando alta sinergia na utilização do catálogo de ferramentas, o agente extraiu dinamicamente os códigos dos produtos (SKU) da resposta analítica e iterou autonomamente sobre o array, invocando sequencialmente a ferramenta operacional mcp_obter_produto para cada um dos 10 itens. Essa capacidade de encadear ferramentas atômicas, extraindo o output de uma requisição para utilizá-lo como input em dez novas consultas individuais, indica a maturidade do agente em contornar limitações de endpoints e o rigor com que foi respeitado o contrato de interfaces estabelecido pelo protocolo MCP.

De posse dos dados granulares, especificamente a métrica SaldoVirtualTotal, que revelou um cenário de ruptura crítico com apenas 37 unidades para o líder de vendas e estoques zerados para os subsequentes, a IA demonstrou acurácia no raciocínio matemático. O modelo inferiu o divisor de 31 dias para o período avaliado (janeiro), calculou o consumo diário, projetou a demanda para os próximos 60 dias e subtraiu o estoque atual para determinar a sugestão de compra exata. Todo o fluxo culminou na estruturação de um painel analítico em formato HTML, com design interativo e alertas visuais de risco iminente, comprovando que o fornecimento de dados estruturados via MCP diminui muito a propensão a alucinações e viabiliza a geração de artefatos de alto valor estratégico. O tempo total de processamento para este teste foi de 5 minutos, com um throughput de 1.042,8 pedidos por minuto, e a execução foi autônoma e bem-sucedida.

A execução do segundo teste do Cenário 2, desta vez conduzida pelo modelo Claude Opus 4.6 (Thinking), corroborou a eficácia da orquestração multi-etapas e introduziu novos comportamentos agênticos de alto valor agregado. Diferentemente das execuções anteriores, o Claude iniciou o fluxo de trabalho demonstrando uma capacidade avançada de planejamento prévio: antes de disparar qualquer requisição ao ERP, o agente utilizou a ferramenta tool_search do MCP para mapear ativamente o catálogo disponível, buscando termos como “top products analytics” e “saldo estoque produto”. Esse comportamento exploratório comprova que a arquitetura permite que agentes de IA se adaptem a ambientes sistêmicos desconhecidos, descobrindo e selecionando as ferramentas corretas de forma autônoma.

Após identificar os endpoints necessários, o modelo Claude Opus 4.6 repetiu o sucesso do teste anterior ao lidar com a ausência de uma ferramenta única de análise de ressuprimento. O agente iniciou a extração assíncrona do ranking de vendas e gerenciou a latência da API de forma exemplar, realizando 17 checagens de status (polling) ao longo de quase 5 minutos de processamento de carga pesada, analisando 5.214 pedidos. Com o array dos 10 itens mais vendidos em mãos, o agente iterou de forma impecável sobre cada código (SKU), invocando a ferramenta mcp_obter_produto dez vezes consecutivas para extrair a métrica de SaldoVirtualTotal, demonstrando a capacidade de encadeamento de ferramentas.

Do ponto de vista analítico, o Claude Opus 4.6 executou os cálculos matemáticos de projeção para 60 dias com total precisão, classificando visualmente os itens em estados de alerta. O grande diferencial deste ensaio foi a capacidade do modelo de sobrepor uma camada de raciocínio qualitativo aos dados quantitativos. Ao analisar as descrições dos SKUs com maior risco de ruptura, predominantemente “Cadernos Universitários”, e cruzar essa informação com o período analisado (janeiro), a IA inferiu o contexto de sazonalidade. O modelo incluiu, de forma autônoma, uma nota metodológica no relatório HTML, alertando o gestor de que a demanda atípica do período de “volta às aulas” não deveria ser projetada linearmente para os meses subsequentes, mitigando o risco de superestoque. Este resultado evidencia que o fornecimento de dados estruturados via MCP potencializa não apenas a automação de relatórios, mas também a geração de insights estratégicos complexos por parte da Inteligência Artificial. O tempo total de processamento foi de 4 minutos e 56 segundos, com um throughput de 1.057,6 pedidos por minuto, e a execução foi autônoma e bem-sucedida.

Os resultados obtidos com o gateway orientado ao protocolo MCP corroboram e, simultaneamente, oferecem novas perspectivas em relação às metodologias recentes exploradas na literatura para a integração de Grandes Modelos de Linguagem com sistemas ERP. A abordagem desenvolvida avança em relação a propostas como a de Niederwieser et al. (2025), que dependem de bibliotecas de código aberto e orquestração acoplada à linguagem específica. O presente trabalho demonstrou que a adoção do Model Context Protocol como camada de padronização atua de forma agnóstica, abstraindo a complexidade do cliente e permitindo que diferentes modelos, como Claude Opus e Gemini Pro, orquestrem tarefas de forma autônoma e com alta precisão sem a necessidade de codificar fluxos de decisão no lado da aplicação cliente.

O gateway desenvolvido materializa o framework conceitual proposto por Vedanbhatla (2025), no qual os LLMs operam como intermediários inteligentes capazes de realizar tradução semântica, orquestração de sistemas e raciocínio contextual. Enquanto Vedanbhatla destaca que tecnologias tradicionais de integração frequentemente falham em ambientes que exigem compreensão semântica e interação adaptativa, a arquitetura apresentada operacionaliza essa visão de middleware semântico, mitigando o risco de alucinações inerente aos LLMs através do esquema de tipagem estrita JSON-RPC do MCP. Essa característica forçou a IA a respeitar contratos determinísticos de APIs, unindo a adaptabilidade semântica com o rigor técnico exigido por sistemas financeiros e de suprimentos.

Por sua vez, ao abordar o ciclo de desenvolvimento, Sarferaz (2025) propõe uma arquitetura que embute as capacidades de IA Generativa diretamente no ERP por meio de um DevOps Framework robusto. Em contraste, o gateway MCP projetado neste trabalho atua de maneira externa, modular e plug-and-play. Os ensaios demonstraram que sistemas legados que não possuem IA nativa podem se beneficiar do raciocínio avançado de agentes externos, isolando a complexidade de gestão de tokens (OAuth 2.0) e a persistência em cache no gateway, sem requerer reestruturações profundas no núcleo tecnológico original do software de gestão. A validação dos dados analíticos e operacionais gerados pelos modelos de linguagem nos dois cenários experimentais restringiu-se à conferência realizada pelo próprio pesquisador, sem a avaliação por profissionais externos ou especialistas dedicados às áreas de compras e controladoria, o que constitui uma limitação do estudo.

A análise pautou-se em uma verificação empírica e amostral, confrontando os valores numéricos consolidados de faturamento com o montante das notas fiscais de venda emitidas pela empresa no período. Constatou-se, qualitativamente, a aderência do ranqueamento de produtos mais vendidos à realidade comercial empírica da empresa no mês de janeiro de 2026. Uma auditoria pormenorizada, com a conciliação individual de cada pedido em relação às dezenas de relatórios nativos dispersos pelos múltiplos canais de venda, não compôs o escopo desta validação, priorizando-se a avaliação da viabilidade arquitetural, da autonomia do agente de inteligência artificial e da possibilidade de usar diferentes LLMs. A solução apresentou uma dependência tecnológica direta da interface v3 do Bling, o que restringiu a generalização imediata da arquitetura para outros sistemas de gestão sem reestruturações nas camadas de repositório e mapeamento. Adicionalmente, as métricas de escalabilidade ficaram limitadas a ambientes de teste controlados, carecendo de validação em cenários de produção sob alta concorrência e volumetria massiva de dados em tempo real.

Notou-se, ainda, que a estabilidade da orquestração dependeu do uso de modelos de linguagem de alta performance com capacidades avançadas de function calling, sendo que restrições externas, como os limites de utilização dos modelos no plano contratado no software Antigravity, influenciaram a capacidade de realização das análises complexas. Por fim, a solução indicou que a padronização das ferramentas via MCP não apenas viabiliza a orquestração autônoma de consultas em múltiplas etapas por parte da inteligência artificial e garante que as regras de cálculo corretas sejam seguidas, mas também potencializa a geração de artefatos analíticos complexos. Os resultados demonstram que o gateway de integração em .NET orientado ao Model Context Protocol atingiu o objetivo de conectar agentes de Inteligência Artificial ao sistema Bling de forma segura, escalável e padronizada, transformando o sistema de gestão em uma plataforma apta ao raciocínio lógico e à tomada de decisão estratégica segura.

4. Conclusão

O estudo teve por objetivo projetar e implementar um gateway de integração em .NET, utilizando-se do Model Context Protocol (MCP), para conectar agentes de Inteligência Artificial a um ERP de mercado (Bling), permitindo a autenticação segura, a consulta estruturada de dados e a automação de processos de análises de pedidos e estoques através de interfaces padronizadas. Verificou-se que a arquitetura proposta superou os desafios de incompatibilidade entre lógicas probabilísticas e determinísticas, garantindo a autenticação segura e a consulta estruturada de dados. Os testes experimentais demonstraram uma redução significativa na latência das consultas operacionais, com o tempo de processamento de uma tarefa complexa caindo de aproximadamente 44 minutos para menos de 5 minutos, por meio da implementação de um robusto mecanismo de cache. Observou-se, ademais, que a tipagem estrita imposta pelo protocolo MCP atuou como uma barreira eficaz contra alucinações, compelindo os agentes à precisão algorítmica e viabilizando a orquestração autônoma de múltiplas ferramentas. A principal contribuição reside na transformação do sistema de gestão em uma plataforma apta ao raciocínio lógico, facilitando a automação complexa e a tomada de decisão estratégica segura, ao permitir que gestores utilizem linguagem natural para interagir com dados empresariais.

Contudo, o estudo identificou limitações inerentes ao seu escopo. A validação dos dados analíticos e operacionais gerados restringiu-se à conferência realizada pelo próprio pesquisador, sem a avaliação por profissionais externos, e a análise pautou-se em uma verificação empírica e amostral, não incluindo uma auditoria pormenorizada de cada pedido. A solução demonstrou dependência tecnológica direta da interface v3 do Bling, o que restringe a generalização imediata da arquitetura para outros sistemas de gestão sem reestruturações. As métricas de escalabilidade ficaram limitadas a ambientes de teste controlados, carecendo de validação em cenários de produção sob alta concorrência e volumetria massiva de dados em tempo real. Para trabalhos futuros, recomenda-se o desacoplamento da camada de API para suporte multi-ERP e a realização de testes de estresse em infraestruturas de nuvem distribuídas, com múltiplas consultas sendo realizadas ao mesmo tempo.

Referências Bibliográficas

Bling. 2026. API do Bling. Disponível em: https://developer.bling.com.br/. Acesso em: 14 jan. 2026.

Google. 2025. Antigravity: versão 1.20.6. Disponível em: https://antigravity.google/. Acesso em: 20 mar. 2026.

Martin, R.C. 2017. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice-Hall Press, Upper Saddle River, NJ, EUA.

Model Context Protocol [MCP]. 2026. MCP C# SDK. Disponível em: https://github.com/modelcontextprotocol/csharp-sdk. Acesso em: 22 abr. 2026.

Niederwieser, E.; Siegele, D.; Matt, D.T. 2025. Al-driven ERP systems: integrating large language models for enhanced customer interaction and operational efficiency. Zeitschrift Für Wirtschaftlichen Fabrikbetrieb 120(s1): 112-117.

Oliveira, M.A.; Ramos, A.S.M. 2002. Fatores de sucesso na implementação de sistemas integrados de gestão empresarial (ERP): estudo de caso em uma média empresa. In: Encontro Nacional de Engenharia de Produção, 2002, Curitiba, PR, Brasil. Anais… p. 1-8.

PostgreSQL Global Development Group. 2026. PostgreSQL 17 Documentation. Disponível em: https://www.postgresql.org/docs/17/index.html. Acesso em: 14 jan. 2026.

Ray, P.P. 2025. A survey on model context protocol: architecture, state-of-the-art, challenges and future directions. TechRxiv Preprint 174495492.22752319 v.1: 1-43.

Sarferaz, S. 2025. Implementing generative Al into ERP software. IEEE Access 13: 73342-73354.

Vedanbhatla, N.V.K.A. 2025. LLMs as Al middleware: unifying disparate systems in manufacturing IT landscapes. Journal Of Computer Science And Technology Studies 7(7): 31-41.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy