A pergunta parece simples: “Temos esse produto disponível e podemos preparar um orçamento para o cliente?”. Para respondê-la, uma inteligência artificial precisa de informações que não estão necessariamente em seus documentos ou em seu treinamento. Estoque, cadastro e condições comerciais pertencem ao sistema da empresa. A integração começa a ficar perigosa quando a solução escolhida é entregar ao modelo uma credencial ampla e deixar que ele descubra o que fazer.
Neste oitavo capítulo da série, vamos entender o MCP e acompanhar o desenho de uma capacidade delimitada de um ERP, sistema integrado de gestão empresarial. O percurso parte dos conceitos, passa pelos contratos de entrada e saída e chega aos critérios de autorização, aprovação e teste. O exemplo é fictício: não representa uma integração executada nem um servidor pronto para produção.
Para sair do desenho da integração e estudar sua implementação em Object Pascal, Delphi na Era dos Agentes apresenta um servidor MCP local sobre um MiniERP educacional, com contratos, aprovação, testes e observabilidade. Conheça a proposta e leia a degustação gratuita para avaliar esse percurso antes de expor capacidades do seu sistema. O laboratório não dispensa a conferência da especificação vigente nem os controles exigidos pelo seu ambiente. Para aprofundar as decisões de arquitetura, identidade e permissões ao redor do modelo, a leitura complementar é IA Além da Conversa.
O que é MCP e qual paradigma ele propõe
MCP significa Model Context Protocol, ou protocolo de contexto do modelo. É um protocolo que organiza a comunicação entre aplicações de IA e programas que oferecem informações ou capacidades. Não é um modelo de linguagem, não substitui o ERP e não decide a política comercial. Sua função é padronizar parte da conexão, permitindo descobrir e utilizar capacidades descritas pelo servidor.
O paradigma é o de integração por capacidades explícitas. Em vez de fornecer toda a estrutura interna do sistema, a aplicação oferece operações com significado definido. Minha recomendação para um ERP é partir de perguntas reais do negócio e criar interfaces pequenas para atendê-las. “Consultar disponibilidade” é uma responsabilidade mais clara do que “acessar o banco e fazer o que for necessário”.
A visão oficial da arquitetura MCP distingue a aplicação hospedeira, chamada host, o cliente e o servidor. A hospedeira coordena a experiência de IA; o cliente é o componente que se comunica com um servidor; o servidor é o programa que oferece capacidades. Esses papéis não precisam corresponder a três computadores: um servidor também pode funcionar localmente.
Na documentação consultada em 2 de outubro de 2026, a revisão apresentada é 2026-07-28. A comunicação usa JSON-RPC, formato de mensagens para solicitar operações e relacionar respostas, com transportes como entrada e saída padrão entre processos, chamados stdio, ou HTTP. Este artigo não reproduz mensagens completas do protocolo: a compatibilidade precisa ser conferida entre a revisão implementada no servidor e a suportada pelo cliente.
Esse cuidado evita uma armadilha didática e operacional. Um exemplo antigo pode ensinar o conceito, mas não comprovar compatibilidade com uma revisão posterior. Antes de conectar ferramentas reais, minha proposta é registrar as versões, o transporte escolhido e as funcionalidades necessárias. Atualizar uma dependência sem verificar o contrato pode quebrar uma integração que parecia funcionar.
Ferramentas, recursos e instruções não são a mesma coisa
A arquitetura oficial apresenta ferramentas (tools), recursos (resources) e modelos de instruções (prompts). Ferramentas são funções executáveis, recursos fornecem dados de contexto e modelos de instruções são estruturas reutilizáveis de interação. No desenho proposto aqui, consultar disponibilidade seria uma ferramenta; uma descrição do significado de “disponível” poderia ser um recurso; uma orientação de atendimento poderia ser um modelo de instruções.
Essa distinção não concede autoridade. Ler um recurso não deve permitir alterar estoque, e um modelo de instruções não deve ampliar a permissão do usuário. Proponho manter uma separação entre aquilo que ajuda a IA a interpretar uma tarefa e aquilo que autoriza a aplicação a executá-la. Uma descrição convincente de ferramenta não equivale a uma regra de acesso.
No capítulo sobre RAG e documentos da empresa, a recuperação fornecia evidências documentais. Aqui, a necessidade pode ser consultar o estado atual do sistema. As abordagens podem coexistir: um manual explica o procedimento e uma capacidade autorizada consulta a disponibilidade. A origem e o propósito de cada informação precisam continuar visíveis.
Para o desenvolvedor Delphi, essa separação lembra a diferença entre apresentar uma informação e executar um serviço de aplicação. Minha recomendação é não colocar regras comerciais na conversa quando elas já pertencem a uma camada testável do ERP. O servidor MCP deve encaminhar uma solicitação delimitada a essa camada, não transformar o texto do usuário em substituto das regras existentes.
Um contrato pequeno para uma necessidade concreta
Considere a ferramenta fictícia consultar_disponibilidade. Seu objetivo é informar a quantidade disponível de um produto em uma unidade autorizada. O contrato define quais campos entram, quais dados saem e o que acontece quando a consulta não pode ser atendida. Contrato, neste artigo, significa um acordo verificável entre componentes, não apenas uma descrição informal.
Minha proposta de entrada usa identificador do produto e identificador da unidade. Esses campos servem para localizar o objeto consultado; não demonstram que o solicitante tem acesso a ele. A identidade deve vir de um mecanismo confiável da aplicação. Um identificador escolhido pelo modelo não pode funcionar como prova de que ele representa outro usuário ou outra empresa.
Na saída, proponho quantidade, unidade de medida, identificação do produto e instante da consulta. O significado da quantidade deve ser explícito: estoque físico, saldo livre e disponibilidade para venda podem representar conceitos diferentes no próprio ERP. Se a operação não considerar reservas, essa limitação precisa aparecer no contrato, em vez de ficar escondida em um nome genérico.
A especificação de ferramentas define descrições e esquemas de entrada, além de permitir esquema de saída. Um esquema descreve a estrutura esperada dos dados. Ele ajuda a conferir formato e campos, mas não demonstra, sozinho, que uma quantidade está correta ou que o usuário pode vê-la. A validação comercial e a autorização continuam sendo responsabilidades do sistema.
Também proponho resultados distintos para produto não encontrado, acesso negado e falha temporária, sem expor detalhes internos desnecessários. O atendimento pode pedir esclarecimento quando falta identificação; não deve transformar indisponibilidade do serviço em “estoque zero”. Essa diferença parece pequena na interface, mas altera a decisão que o usuário tomará.
O caminho da consulta sem acesso SQL genérico
No fluxo proposto, a aplicação recebe a pergunta, identifica o usuário e permite que o modelo sugira a consulta pertinente. A chamada chega ao servidor, que valida campos e autorização antes de procurar o serviço do ERP. A resposta volta com dados delimitados, e a aplicação apresenta o resultado sem atribuir à IA uma informação que veio do sistema.
Prefiro esse desenho a uma ferramenta genérica que receba SQL livre. SQL é a linguagem usada para consultar e modificar dados em muitos bancos relacionais. Mesmo quando se tenta limitar a ferramenta a consultas, uma interface ampla exige examinar tabelas, filtros, dados sensíveis e custo de execução. Uma capacidade específica permite discutir seu alcance com mais clareza e verificar situações de recusa.
Essa escolha é uma recomendação de arquitetura, não uma proibição universal do protocolo. Há sistemas com necessidades distintas, e interfaces genéricas podem existir sob controles próprios. Para o cenário educacional deste artigo, porém, o objetivo é tornar o acesso compreensível: conhecer a pergunta atendida, o dado retornado, a regra aplicada e a pessoa autorizada.
Figura — Separação de responsabilidades proposta pelo autor. Consulta não significa efetivação; este diagrama não representa um servidor MCP executado.
Preparar um orçamento é diferente de efetivá-lo
Agora considere a solicitação “prepare um orçamento”. Minha proposta é uma capacidade que gere uma proposta com produtos, quantidades e condições calculadas pelas regras do ERP, sem enviar ao cliente nem registrar uma obrigação final. O resultado deve dizer o que foi preparado e quais etapas continuam pendentes. A palavra “preparar” precisa ter consequências concretas no contrato.
A efetivação deve ser outra responsabilidade. Para operações sensíveis, a especificação recomenda confirmação humana e apresentação dos argumentos antes da execução; também exige controles no servidor, como validação de entradas e acesso. O usuário precisa poder entender qual ação será feita. Um botão “aprovar” sobre uma síntese vaga não é a experiência que proponho para uma operação comercial.
No cenário fictício, a aprovação deve estar vinculada à proposta exata, ao responsável e às condições apresentadas. Se itens ou valores mudarem, proponho pedir nova confirmação. A aplicação não deve aceitar como autorização uma frase gerada pelo modelo dizendo que o usuário já aprovou. Quem verifica a aprovação é o mecanismo de controle do sistema.
Essa etapa também precisa lidar com alterações de disponibilidade entre consulta e execução. Minha recomendação é revalidar condições relevantes no momento de efetivar. Mostrar estoque em um instante não reserva mercadoria automaticamente. A política de reserva, os limites e o tratamento de conflito pertencem ao ERP e precisam ser explicitados antes de ampliar o piloto.
Identidade, permissões e registros da operação
Autenticação é conferir quem está solicitando; autorização é decidir o que essa identidade pode fazer. No desenho recomendado, são verificações diferentes, aplicadas a cada operação e ao objeto envolvido. Poder consultar estoque em uma unidade não deve implicar consultar todas as unidades, alterar preços ou aprovar um orçamento. A integração não deve ampliar silenciosamente o perfil existente.
Quando há credenciais de acesso, a documentação de segurança do MCP alerta para aceitar tokens destinados a outro serviço e repassá-los sem validação. Um token é uma credencial que representa autorização em determinado contexto. No cenário proposto, a configuração de identidade deve respeitar esse contexto; copiar uma credencial ampla para simplificar o piloto não é uma solução de governança.
Proponho registrar a identificação da operação, o solicitante, os parâmetros permitidos, o resultado e eventuais confirmações, com cuidado para não incluir segredos nos registros. Observabilidade significa ter informações suficientes para compreender o funcionamento e investigar falhas. Um histórico de conversa pode ajudar o atendimento, mas não substitui um registro confiável da operação executada.
Também é necessário prever limites de tempo e de uso. Se uma consulta falhar, a aplicação deve comunicar a situação e definir quando pode tentar novamente. Para uma operação de alteração, repetir automaticamente exige cuidado com duplicidade. Minha recomendação é definir um identificador de operação e uma política verificável de repetição antes de habilitar qualquer efeito externo.
Como começar e como avaliar o piloto
Comece por uma capacidade de consulta em ambiente de testes, com dados fictícios e uma regra de acesso clara. Documente perguntas aceitas, campos necessários, erros esperados e informação que não pode sair. Depois, verifique a chamada diretamente, sem o modelo. Se o serviço não respeitar seu contrato isoladamente, a conversa não corrigirá esse problema.
Em seguida, avalie a escolha da ferramenta e a apresentação da resposta. Inclua produto inexistente, unidade não autorizada, argumento inválido e serviço indisponível. Para propostas comerciais, acrescente ausência de aprovação, aprovação de versão diferente e repetição da solicitação. Esses casos são critérios sugeridos, não testes executados neste artigo; não houve conexão com um ERP real.
A continuidade com o capítulo sobre IA em projetos Delphi existentes é importante: a integração deve preservar regras e limites já conhecidos. Não é necessário transformar o sistema inteiro em um agente para verificar uma consulta útil. Minha preferência é ampliar apenas depois de demonstrar que a capacidade pequena funciona e recusa o que está fora de seu alcance.
MCP pode ser desnecessário quando uma integração convencional resolve o problema com menos componentes. Ele também não garante qualidade de interpretação, segurança absoluta ou compatibilidade entre qualquer cliente e servidor. O critério de adoção deve ser a necessidade concreta de conectar capacidades à aplicação de IA, com operação e manutenção que a equipe consiga sustentar.
Conclusão
Conectar IA ao ERP não exige entregar o ERP inteiro à IA. O MCP oferece uma forma de comunicação, enquanto a arquitetura precisa decidir quais capacidades serão expostas, quem pode utilizá-las e como confirmar ações sensíveis. O controle depende de contratos e verificações aplicadas pelo sistema, não apenas de instruções bem escritas para o modelo.
O primeiro passo útil é escolher uma consulta pequena e demonstrar seu comportamento com dados fictícios, inclusive nos casos de recusa. Depois, pode-se estudar uma proposta sem efetivação e uma aprovação vinculada ao conteúdo exato. No próximo capítulo, essa separação será aplicada à automação com n8n: interpretar uma solicitação, preparar uma ação e executá-la são responsabilidades que precisam continuar distintas.
Para passar do contrato descrito a um laboratório em Object Pascal, Delphi na Era dos Agentes apresenta um servidor MCP local sobre um MiniERP educacional, com aprovação, testes e observabilidade. Consulte o sumário e a degustação gratuita para avaliar esse percurso de implementação. O laboratório não substitui a adaptação dos controles nem a conferência da especificação vigente no seu ambiente.
Referências
MODEL CONTEXT PROTOCOL. Architecture overview. Model Context Protocol, [s. d.]. Versão 2026-07-28. Disponível em: https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture. Acesso em: 2 out. 2026.
MODEL CONTEXT PROTOCOL. Security Best Practices. Model Context Protocol, [s. d.]. Versão 2026-07-28. Disponível em: https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices. Acesso em: 2 out. 2026.
MODEL CONTEXT PROTOCOL. Tools. Model Context Protocol, [s. d.]. Versão 2026-07-28. Disponível em: https://modelcontextprotocol.io/specification/2026-07-28/server/tools. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. Como usar IA em um projeto Delphi existente sem perder o controle. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/como-usar-ia-em-um-projeto-delphi-existente-sem-perder-o-controle/. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. Delphi na Era dos Agentes. Livros de Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/delphi-na-era-dos-agentes. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. IA Além da Conversa. Livros de Régys Borges da Silveira, [s. d.]. Disponível em: https://livros.regys.com.br/ia-alem-da-conversa. Acesso em: 2 out. 2026.
SILVEIRA, Régys Borges da. RAG na prática: como fazer a IA responder usando os documentos da empresa. regys.com.br, [s. d.]. Disponível em: https://regys.com.br/rag-na-pratica-como-fazer-a-ia-responder-usando-os-documentos-da-empresa/. Acesso em: 2 out. 2026.
0 comentário(s)