Um ERP concentra informações e regras que sustentam a operação de uma empresa: cadastro de clientes, catálogo de produtos, estoque, faturamento, políticas comerciais e rotinas administrativas. Ao mesmo tempo, agentes de IA estão mudando a expectativa sobre como as pessoas consultam e operam sistemas. Em vez de navegar por múltiplas telas, o usuário pode formular uma intenção: “quais produtos estão abaixo do estoque mínimo?” ou “prepare um orçamento para este cliente”.

A aparente simplicidade dessas perguntas esconde uma questão de arquitetura. Um agente não deveria receber acesso genérico ao banco de dados, nem ser estimulado a reproduzir por tentativa e erro as regras que o ERP já possui. Tampouco faz sentido transformar cada detalhe interno do sistema em uma ferramenta disponível para um modelo de linguagem.

O caminho mais seguro e sustentável é expor capacidades delimitadas, com contratos claros e controles proporcionais ao risco. Nesse cenário, o Model Context Protocol (MCP) oferece uma forma de apresentar ferramentas, recursos e instruções para clientes compatíveis, enquanto o ERP permanece como fonte de verdade para suas regras de negócio.

Conheça o livro: Delphi na Era dos Agentes.

O problema não é conectar a IA; é definir o que ela pode fazer

Integrar IA a um ERP costuma ser descrito como uma tarefa de comunicação: criar uma API, enviar uma pergunta e receber uma resposta. Essa visão é incompleta. A comunicação é apenas a camada mais visível. O problema decisivo é de fronteira: onde termina a autonomia do agente e onde começam as garantias obrigatórias do sistema corporativo?

Um ERP real tem particularidades difíceis de inferir a partir de nomes de tabelas ou descrições breves. Um campo chamado Status, por exemplo, pode ter implicações fiscais, comerciais ou operacionais. Uma rotina de faturamento pode depender de validações de estoque, dados do cliente, condições de pagamento e permissões. Quando essas regras estão em código já consolidado, duplicá-las em instruções para um modelo de IA cria duas fontes de verdade — e, com o tempo, duas interpretações divergentes do mesmo processo.

Por isso, a pergunta mais produtiva não é “como dar acesso ao ERP para o agente?”, mas sim:

Qual capacidade de negócio o agente precisa usar, com quais dados, sob quais condições e com qual consequência?

Essa mudança de pergunta desloca a integração de um acesso amplo para uma interface intencional. Em vez de expor uma tabela de estoque, expõe-se a capacidade de consultar disponibilidade. Em vez de liberar inserções diretas em faturas, expõe-se a capacidade de preparar um orçamento, submetido posteriormente a revisão ou aprovação.

Complexidade interna não é uma interface

Uma tela de ERP pode conter dezenas de campos, botões, filtros e opções administrativas. Isso é adequado para uma operação humana detalhada, mas não define automaticamente uma boa ferramenta para agentes. Uma interface de agente deve ser menor, mais estável e orientada ao resultado.

Considere a diferença entre duas abordagens:

• “Executar uma consulta livre no cadastro de produtos”;
• “Localizar produtos por código, nome ou categoria e retornar código, descrição, preço permitido e disponibilidade.”

A primeira entrega liberdade demais e transfere para o consumidor da integração a responsabilidade por filtros, limites e interpretação. A segunda codifica uma intenção de negócio e permite aplicar regras no lado do ERP. Também fica mais simples testar, auditar e evoluir.

O que o MCP organiza nessa arquitetura

O MCP pode ser entendido como um protocolo para conectar clientes de IA a capacidades externas de forma estruturada. No contexto de um ERP, o servidor MCP atua como uma camada de adaptação entre o cliente que conversa com o agente e os serviços ou regras do sistema corporativo.

Essa camada pode apresentar três elementos particularmente úteis:

• tools, para operações que o agente pode solicitar, como consultar clientes, localizar produtos ou preparar uma proposta;
• resources, para disponibilizar contexto identificado e recuperável, como informações de uma entidade ou dados de referência permitidos;
• prompts, para oferecer instruções ou fluxos predefinidos que orientem tarefas recorrentes.

O protocolo não substitui a regra de negócio. Ele não sabe, por si só, quais usuários podem acessar dados, que campos são sensíveis, quando uma alteração exige aprovação ou como uma fatura deve ser calculada. Essas decisões continuam pertencendo ao ERP e à arquitetura da aplicação.

Em uma implementação local, o transporte stdio pode ser uma escolha direta: o processo cliente inicia ou se comunica com o servidor por entrada e saída padrão, sem abrir necessariamente um serviço de rede. Isso reduz elementos de infraestrutura em cenários de desenvolvimento, demonstração ou uso controlado na estação de trabalho. Ainda assim, “local” não é sinônimo de “sem risco”: a confiança no processo chamador, as permissões do usuário e o tratamento de dados permanecem relevantes.

JSON-RPC como envelope, não como regra de negócio

Em uma implementação baseada em JSON-RPC, requisições e respostas seguem uma estrutura previsível. Há um método solicitado, parâmetros e uma resposta de sucesso ou erro. Essa previsibilidade facilita a descoberta de capacidades e a integração com clientes compatíveis.

Mas é importante separar responsabilidades. JSON-RPC organiza a conversa técnica; ele não torna uma operação segura apenas por estar bem-formada. Um pedido sintaticamente válido ainda pode trazer um identificador inexistente, um valor fora de faixa, um texto excessivamente longo ou uma combinação de argumentos incompatível com a política comercial.

A validação precisa ocorrer em camadas:

1. o servidor verifica se a mensagem segue o contrato técnico;
2. a ferramenta verifica tipos, presença e faixa dos argumentos;
3. a camada de negócio aplica regras do domínio;
4. ações de maior impacto passam por autorização e, quando previsto, aprovação humana;
5. o resultado registra dados suficientes para rastreamento posterior.

Uma arquitetura de capacidades para ERPs

Uma arquitetura inicial pode ser organizada em quatro camadas, ainda que elas estejam no mesmo executável durante um protótipo.

1. Adaptador MCP

É a borda do sistema. Ela recebe mensagens, responde à descoberta de ferramentas, recursos e prompts, serializa resultados e transforma falhas em erros compreensíveis pelo cliente. Essa camada deve conhecer o protocolo, mas não deve concentrar cálculos de estoque, regras de preço ou decisões fiscais.

A descoberta merece atenção especial. A lista de capacidades precisa ser tratada como parte do contrato público. Nomes claros, descrições objetivas e esquemas de argumentos ajudam o agente a escolher uma ferramenta apropriada. Uma ferramenta chamada consultar_estoque_produto, por exemplo, comunica melhor sua finalidade do que um nome genérico como executar_operacao.

2. Contratos de entrada e saída

Cada capacidade precisa declarar o que recebe e o que devolve. Contratos explícitos reduzem ambiguidade e tornam os testes mais objetivos.

Para uma consulta de produto, um contrato pode aceitar um código ou um termo de busca, com limite máximo de resultados. A resposta pode trazer uma lista com identificador, descrição, unidade, situação e dados de disponibilidade que sejam adequados à finalidade. Não é necessário retornar todos os campos existentes no cadastro.

Em operações preparatórias, o contrato deve distinguir dados fornecidos pelo solicitante, dados calculados pelo ERP e mensagens de pendência. Um orçamento preparado pode conter itens reconhecidos, quantidades validadas, valores calculados conforme as regras disponíveis e uma indicação de que ainda não representa confirmação, faturamento ou compromisso definitivo.

3. Serviços de domínio

Aqui ficam as regras que dão significado à operação. Se o ERP já possui serviços para localizar clientes, verificar estoque, calcular totais ou validar condições comerciais, a camada MCP deve chamá-los em vez de recriar sua lógica.

Essa escolha evita que a integração com IA se torne um caminho paralelo, com comportamento diferente da aplicação convencional. Também facilita manutenção: quando uma regra de negócio muda, a alteração ocorre no ponto que já deveria ser responsável por ela.

4. Controles transversais

Autorização, logs, correlação de requisições, limites de uso, mascaramento de dados e tratamento de erros atravessam todas as capacidades. Eles não devem depender da boa vontade de quem implementou uma ferramenta específica.

Uma prática útil é gerar um identificador de correlação para cada solicitação. Ele pode acompanhar os registros desde a entrada MCP até a execução do serviço de domínio. Se uma preparação de orçamento retornar um resultado inesperado, esse identificador ajuda a localizar a sequência de decisões sem registrar, indiscriminadamente, conteúdo sensível.

Comece por consultas e operações reversíveis

Nem toda capacidade deve ser disponibilizada desde o início. Uma integração madura geralmente avança por níveis de impacto.

O primeiro nível é composto por consultas: encontrar clientes, consultar produtos, verificar estoque ou recuperar dados de faturas conforme as permissões definidas. Mesmo leituras exigem cuidado, pois podem revelar dados comerciais ou pessoais, mas tendem a ter menor efeito operacional imediato do que alterações.

O segundo nível reúne operações preparatórias: montar uma seleção de itens, simular uma condição, estruturar uma proposta ou preparar um orçamento. Essas ações produzem um artefato que pode ser revisado, sem disparar automaticamente uma consequência irreversível.

O terceiro nível inclui ações de negócio com efeitos relevantes, como confirmar documentos, reservar estoque, alterar cadastros ou emitir registros formais. Nessa faixa, aprovação humana, permissões específicas e validações adicionais deixam de ser detalhes opcionais.

Um exemplo: preparação controlada de orçamento

Imagine que um usuário peça ao agente um orçamento para um cliente, com determinados produtos e quantidades. Uma implementação prudente não deveria converter essa frase diretamente em uma fatura definitiva.

O fluxo pode ser organizado assim:

1. o agente identifica a intenção e solicita ao servidor a busca do cliente;
2. o servidor retorna somente clientes compatíveis com os critérios e as permissões aplicáveis;
3. o agente resolve os produtos por meio de uma ferramenta de consulta, sem inventar códigos inexistentes;
4. uma ferramenta de preparação recebe identificadores e quantidades dentro de limites definidos;
5. o ERP valida estoque, regras comerciais e dados necessários;
6. o servidor devolve uma proposta estruturada, com itens aceitos, pendências e total calculado quando aplicável;
7. uma pessoa revisa e aprova a etapa que realmente produz efeito no processo.

Esse desenho preserva a utilidade do agente — interpretar pedidos, reunir contexto e conduzir o fluxo — sem transferir a ele a autoridade final sobre uma ação sensível.

Restringir argumentos é uma decisão de produto e segurança

Modelos de linguagem trabalham com linguagem natural e podem gerar parâmetros incompletos, imprecisos ou excessivos. Uma ferramenta bem projetada precisa supor essa possibilidade.

Restringir argumentos não é apenas rejeitar entradas inválidas. É definir deliberadamente os limites da capacidade. Alguns exemplos práticos incluem:

• exigir identificadores internos depois de uma etapa de busca, em vez de aceitar qualquer descrição livre em uma operação crítica;
• limitar a quantidade de itens em uma solicitação;
• definir teto para tamanho de textos e termos de pesquisa;
• usar enumerações para campos que possuem estados conhecidos;
• rejeitar campos desconhecidos em operações sensíveis;
• estabelecer paginação e limite máximo de resultados em consultas;
• separar “simular” de “confirmar”, mesmo que ambas usem parte da mesma lógica.

Esses controles tornam o comportamento mais previsível para pessoas, agentes e equipes de suporte. Também reduzem o risco de uma ferramenta aparentemente simples virar uma porta genérica para o ERP.

Testes e observabilidade: condições para confiar na integração

A qualidade de uma integração com agentes não pode ser avaliada apenas por uma demonstração em que a pergunta foi entendida. É necessário testar o contrato e os limites.

Nos testes de protocolo, verifique descoberta, formato das mensagens, tratamento de métodos desconhecidos e respostas de erro. Nos testes de ferramenta, cubra argumentos ausentes, tipos incorretos, valores fora de faixa, identificadores inválidos e resultados vazios. Nos testes de domínio, confirme que as mesmas regras usadas pelo ERP continuam valendo quando a chamada vem pela camada MCP.

Também vale testar situações que um fluxo ideal não mostra: produto sem saldo disponível, cliente bloqueado, quantidade negativa, duplicidade de item, timeout de dependência e tentativa de executar uma ação que exige aprovação.

A observabilidade complementa os testes em execução. Registros úteis respondem perguntas como: qual ferramenta foi chamada? Quais parâmetros foram aceitos ou recusados? Qual regra impediu a operação? Quanto tempo a solicitação levou? Quem aprovou uma etapa posterior? O cuidado é registrar o necessário sem transformar logs em uma cópia descontrolada de dados empresariais.

Métricas simples, como volume por ferramenta, taxa de validações rejeitadas, latência e falhas por categoria, ajudam a identificar contratos confusos ou capacidades que precisam ser revistas. Se uma ferramenta recebe frequentemente argumentos inválidos, o problema pode estar na descrição, no esquema, no fluxo de descoberta ou na própria granularidade da capacidade.

Limitações e decisões que o MCP não resolve

MCP não elimina a necessidade de modelagem de domínio, autenticação, autorização ou governança de dados. Ele também não garante que um agente interprete perfeitamente a intenção de um usuário. A arquitetura deve admitir incerteza e manter validações no lado do sistema.

Além disso, a adoção depende do contexto operacional. Um servidor local com transporte stdio pode ser adequado para determinados cenários, mas não responde sozinho a necessidades de múltiplos usuários, acesso remoto, alta disponibilidade ou segregação mais complexa de ambientes. Esses requisitos exigem decisões adicionais de infraestrutura e segurança.

Há ainda uma limitação de escopo essencial: uma capacidade bem delimitada pode não atender todos os casos de uso no primeiro momento. Isso não é necessariamente um defeito. É preferível começar com operações compreensíveis e ampliar o conjunto conforme contratos, riscos e evidências de uso sejam avaliados.

Um caminho prático em Delphi

Para equipes Delphi, a oportunidade não está em abandonar aplicações existentes para adotar uma camada de IA, mas em aproveitar os serviços e conhecimentos de domínio já presentes no ERP. O trabalho consiste em criar uma fronteira clara: de um lado, o protocolo e as capacidades descritas para clientes de IA; de outro, regras de negócio preservadas e controles verificáveis.

Uma sequência razoável de implementação é:

1. escolher um fluxo de consulta útil e de baixo impacto, como busca de produtos ou situação de estoque;
2. definir nome, descrição, argumentos, resposta, limites e erros esperados;
3. implementar o adaptador MCP e conectá-lo ao serviço de domínio existente;
4. testar casos válidos e inválidos antes de ampliar o catálogo de ferramentas;
5. incluir logs e correlação desde a primeira versão;
6. adicionar uma operação preparatória, como orçamento controlado;
7. estabelecer explicitamente quais transições exigem aprovação humana.

Esse percurso evita o salto direto para automações amplas e mantém a evolução ancorada em capacidades que a equipe consegue explicar, testar e auditar.

Para quem quer ver essa implementação aplicada em Delphi 13, com um MiniERP fictício e um servidor MCP local construído sem biblioteca MCP externa, o livro Delphi na era dos agentes, de Régys Borges da Silveira, aprofunda o tema. A obra trabalha JSON-RPC, transporte stdio, descoberta, tools, resources e prompts, além de cenários de estoque, clientes, produtos, faturas e preparação controlada de orçamento. O livro também aborda contratos explícitos, restrição de argumentos, aprovação humana, testes e observabilidade, e informa a existência de um repositório público com o projeto completo.

Conclusão

Conectar um ERP a agentes de IA não exige expor o sistema inteiro nem entregar ao modelo acesso direto às estruturas internas. A escolha arquitetural mais importante é converter necessidades de negócio em capacidades limitadas, com contratos explícitos e consequências proporcionais ao nível de risco.

O MCP organiza a apresentação dessas capacidades para clientes de IA, mas a segurança e a confiabilidade dependem do que acontece por trás dele: validação de argumentos, reutilização das regras de domínio, autorização, aprovação humana para ações relevantes, testes e observabilidade.

Em Delphi, esse tipo de integração pode ser construído preservando o valor do ERP existente. O agente passa a ser uma camada de interação e orquestração; o ERP continua sendo a autoridade sobre dados e regras. Para estudar uma implementação guiada desse caminho, é possível conhecer o livro de Régys Borges da Silveira ou ler sua degustação na página oficial da obra.

Referências

SILVEIRA, Régys Borges da. Delphi na era dos agentes. 1. ed. 2026. Disponível em: https://livros.regys.com.br/delphi-na-era-dos-agentes. Acesso em: 28 set. 2026.