Mais do que um simples chatbot: como integramos os agentes MCP à plataforma SimpleOne Enterprise

Os agentes de IA já são capazes de redigir e-mails, resumir reuniões e pesquisar respostas em uma base de conhecimento. Mas, no mundo corporativo, isso é apenas a ponta do iceberg. Enquanto sua IA estiver trabalhando apenas com texto, ela será apenas um ajudante útil à margem, e não um participante efetivo no jogo.

Para que um agente realmente agregue valor em aplicações corporativas como ITSM, SDLC ou outros casos de uso empresariais, ele precisa de acesso seguro às ações: recuperar dados, verificar um status, criar uma tarefa, localizar um objeto relacionado, acessar um sistema externo e retornar o resultado ao usuário. Além disso, ele deve fazer isso não diretamente por meio do banco de dados ou de uma chamada aleatória de API, mas dentro de um perímetro controlado — com permissões, ferramentas definidas e uma lógica de execução clara.

Neste artigo, em parceria com nossa empresa de tecnologia Ainergy — que desenvolve a camada de infraestrutura da plataforma SimpleOne GenAI —, vamos examinar como um novo padrão chamado MCP torna isso possível. Vamos explorar como construir uma arquitetura de agentes para que seu LLM não esteja apenas gerando frases bonitas, mas realmente impulsionando os processos corporativos.

Em um ambiente corporativo, um agente precisa de acesso controlado às ações. Por exemplo, obter uma lista de incidentes, criar uma tarefa no SDLC, localizar um serviço relacionado, verificar o status de uma alteração, recuperar dados de um sistema externo ou atualizar um registro. Ao mesmo tempo, o agente não deve trabalhar diretamente com o banco de dados nem chamar um conjunto aleatório de APIs. É necessário um ambiente controlado: com permissões claras, ferramentas descritas, parâmetros verificáveis e uma lógica de execução previsível.

É aí que entra o MCP — Model Context Protocol. A Anthropic o lançou em 25 de novembro de 2024 como um padrão aberto para conectar aplicativos de IA a fontes de dados, ferramentas de negócios e ambientes de desenvolvimento. O protocolo estabelece uma maneira unificada para que um agente visualize as ferramentas disponíveis, compreenda seus parâmetros e acione as ações necessárias.

O interesse no MCP está ligado ao crescimento geral da IA agentiva — uma abordagem em que a IA responde a uma solicitação e executa ações por meio de ferramentas conectadas. De acordo com a previsão da Gartner, até o final de 2026, até 40% dos aplicativos corporativos incluirão agentes de IA específicos para tarefas. A Forrester classifica a IA agentiva como uma tecnologia que ajudará as empresas a automatizar processos de negócios de forma mais flexível, mas enfatiza a necessidade de precisão, confiança e coordenação. A McKinsey vincula a ampliação dos casos de uso da IA agentiva à preparação de dados, arquitetura e fluxos de trabalho para que os agentes possam atuar em ações corporativas.

Para uma plataforma corporativa, isso altera os requisitos para a IA. Não basta mais que um agente seja um chatbot inteligente. É necessária uma maneira segura de executar tarefas: obter uma lista de incidentes, criar uma tarefa no SDLC, localizar um serviço relacionado, verificar o status de uma alteração, recuperar dados de um sistema externo ou atualizar um registro. O MCP ajuda a descrever essas ações de maneira unificada e a transmiti-las ao agente como um conjunto gerenciável de ferramentas.

Para simplificar, o MCP descreve a interação de um agente com sistemas externos por meio de ferramentas. Uma ferramenta é uma ação que o agente pode usar enquanto trabalha: obter dados, localizar um documento, criar um registro, verificar um status ou acessar um sistema externo. O servidor MCP publica uma lista de ferramentas, suas descrições e parâmetros. O cliente MCP recebe essa lista e a passa para o contexto do LLM. Em seguida, com base na tarefa em questão e na lista de ferramentas disponíveis, o modelo determina qual ferramenta deve ser usada, e o cliente garante que essa chamada seja executada e que o resultado seja devolvido ao modelo.

É importante observar que o MCP não substitui suas APIs, nem se sobrepõe às integrações existentes. Na maioria dos casos, um servidor MCP funciona como um wrapper em torno das APIs existentes.

Seu valor está em outro lugar: ele fornece aos agentes uma descrição padronizada das ações, permitindo que novos sistemas sejam conectados sem a necessidade de desenvolver uma lógica de integração separada para cada modelo ou estrutura de agente.

Na SimpleOne GenAI, estamos incorporando essa lógica diretamente à plataforma. O módulo MCP já está em operação, e estamos testando-o em processos empresariais reais para identificar quais casos de uso de agentes oferecem o maior valor às equipes corporativas.

Uma breve visão geral: três casos de uso principais

A seguir, vamos detalhar como esse modelo está estruturado e o que é importante considerar nos casos de uso corporativos: permissões, segurança, auditoria, erros e operação.

Aqui está o esquema simplificado:

Primeiro, vamos nos entender sobre a terminologia

Há tanto entusiasmo em torno da IA atualmente que precisamos ser precisos sobre o que estamos construindo.

• O agente opera dentro de um determinado perímetro: ele usa apenas as ferramentas descritas, passa parâmetros e retorna o resultado ao usuário. Em uma visão simplificada, trata-se de uma configuração: uma descrição da tarefa, instruções, um modelo selecionado, limitações e um conjunto de ferramentas que o agente pode usar. O LLM atua como o “cérebro”, mas o modelo em si não sabe quais ações são permitidas em um sistema corporativo específico.
• “Ferramenta” é um termo do MCP. Esse é o nome dado a uma ação que um agente pode acionar por meio de um servidor MCP: obter dados, localizar um documento, criar um registro ou acessar um sistema externo. Nos casos de uso internos do SimpleOne, os métodos de IA desempenham um papel semelhante. Eles também dão ao agente acesso a ações, mas são executados dentro da plataforma.
• O servidorMCP é uma camada em torno de um sistema externo ou de sua API. Ele descreve as ferramentas disponíveis e as executa. Por exemplo, se uma empresa usa o Confluence, um servidor MCP pode fornecer uma ferramenta “obter documento por título”. O agente recebe a descrição da ferramenta, a invoca com parâmetros, e o servidor MCP faz a chamada ao Confluence e retorna o resultado.
• O ClienteMCP é a parte do sistema do agente que se conecta ao servidor MCP, obtém a lista de ferramentas e chama a ferramenta necessária. Nos casos de uso do SimpleOne, essa lógica é necessária quando um agente dentro da plataforma trabalha com servidores MCP externos.

Essa distinção é importante para garantir a precisão. Nem todo método interno do agente é MCP. Os métodos internos de IA do SimpleOne podem ser semelhantes às ferramentas em sua função dentro de um caso de uso do agente, mas não utilizam necessariamente o protocolo MCP. Seu valor está em outro lugar: eles são executados nativamente dentro da plataforma, bem próximos ao seu modelo de objetos, dados, regras de negócios e recursos de integração.

Modelo Central do SimpleOne: Agente, Adaptador e Método

Se você deseja que um LLM utilize uma ferramenta, é preciso descrever essa ferramenta em uma linguagem que o modelo compreenda. O modelo precisa saber o que a ferramenta faz, quais parâmetros ela aceita, quando deve ser utilizada e qual é o resultado esperado.

Sem essa descrição, o agente permanecerá como um assistente de texto básico ou começará a “adivinhar” como o sistema funciona. Em um ambiente corporativo, isso é inaceitável: um agente não deve inventar APIs, alterar dados diretamente ou contornar a lógica de negócios da plataforma.

No SimpleOne GenAI, essa tarefa é resolvida pelo pacote “agente — Nexus — adaptador — método”. A seguir, detalharemos as funções do agente, do adaptador e do método, e voltaremos ao Nexus separadamente: ele é responsável pela conexão controlada com o LLM e outros serviços.

No SimpleOne GenAI, lidamos com isso por meio de uma cadeia de comando específica: agente -> Nexus -> adaptador -> método. Vamos examinar as partes (deixaremos o Nexus para o final, já que ele é a porta de entrada para o LLM).

• O Nexus é uma entidade única na plataforma que define as regras de roteamento para um modelo ou serviço de rede neural.
• O Agente é responsável pelo caso de uso aplicado. Por exemplo, um agente ajuda a analisar incidentes, outro prepara um resumo das tarefas de desenvolvimento e um terceiro busca informações sobre objetos relacionados. A configuração do agente define sua finalidade, modelo, estratégia de trabalho, instruções, limitações e conjunto de ferramentas disponíveis.
• O Adaptador reúne as ferramentas que o agente pode usar. É um conjunto de métodos que fornecemos ao agente em um caso de uso específico. Por meio do adaptador, o agente recebe uma “vitrine” das operações disponíveis: quais métodos existem, o que eles fazem, quais parâmetros aceitam e qual resultado retornam.
• Um Método é uma ação independente disponível para o agente dentro do SimpleOne. Se a ação for executada no lado da plataforma, chamamos de método de IA. Se a ação vier de um servidor MCP externo, usamos o termo ferramenta. Para o agente, ambas as opções são estruturalmente semelhantes: há uma descrição da ação, parâmetros de entrada e um resultado de execução. A diferença está no local de execução: um método de IA é executado dentro do SimpleOne; uma ferramenta é executada no lado do servidor MCP.

Essa abordagem separa o raciocínio da execução. O LLM compreende a solicitação, escolhe a ferramenta e define os parâmetros. Mas a ação em si é realizada pela plataforma ou por um servidor MCP conectado. Para um ambiente corporativo, isso é fundamental: a lógica de negócios permanece em um perímetro controlado, e o agente só tem acesso a ações explicitamente descritas e permitidas.

No nível do fluxo de execução, um caso de uso de agente pode ser representado assim:

Caso de Uso 1. O Agente atua dentro da plataforma

O primeiro caso de uso é o mais próximo da lógica da plataforma. O agente é criado dentro do sistema e utiliza seus dados, objetos de negócios, métodos internos e recursos de integração. Esse caso de uso não requer um servidor MCP externo separado, um backend de agente separado ou infraestrutura adicional para executar ações.

Aqui, a distinção em relação a um esquema MCP “puro” com um servidor externo é importante. A plataforma corporativa já sabe como trabalhar com suas próprias tabelas, objetos, processos, regras de negócios, scripts e integrações. Portanto, algumas ações podem ser descritas e executadas dentro do próprio sistema como métodos de IA.

O valor desse caso de uso reside na menor complexidade da infraestrutura. A empresa não precisa implantar um servidor MCP separado ao lado do sistema principal, configurar acessos de rede adicionais nem duplicar a lógica de negócios em uma camada externa. O agente opera mais próximo dos dados e dos processos com os quais precisa interagir.

No entanto, os métodos internos de IA não devem ser estritamente chamados de ferramentas MCP. São ferramentas nativas do módulo do agente. Elas resolvem a mesma tarefa aplicada — fornecer ao agente um conjunto gerenciável de ações —, mas são executadas dentro da plataforma, e não por meio de um servidor MCP externo.

Caso de uso 2. O agente se conecta a um servidor MCP externo

O segundo caso de uso é necessário quando os dados e métodos internos não são suficientes para o agente. Em um ambiente corporativo, os processos raramente residem em um único sistema. As tarefas de desenvolvimento podem estar no Jira, a documentação no Confluence, as métricas em um sistema de monitoramento e os processos de serviço no perímetro do ITSM.

Nessa arquitetura, o agente precisa de um contexto distribuído. Se um usuário solicitar a análise detalhada de um incidente, o agente pode precisar não apenas do cartão do ticket, mas também de tarefas de desenvolvimento relacionadas, comentários de engenheiros, documentação de serviço ou dados sobre alterações recentes.

Para esses casos de uso, servidores MCP externos podem ser conectados à plataforma. Um administrador registra um servidor, que publica um conjunto de ferramentas. O sistema recebe a descrição delas, e as ferramentas necessárias podem ser adicionadas ao adaptador de um agente específico.

Do ponto de vista do agente, isso é semelhante a trabalhar com métodos internos de IA. Ele possui um adaptador e, dentro dele, estão disponíveis as ações. A diferença é que algumas dessas ações não são executadas dentro da plataforma principal, mas no servidor MCP externo.

A mesma lógica se aplica a uma base de conhecimento. Suponha que um usuário solicite a elaboração de um breve relatório sobre os artigos mais recentes no Confluence. O servidor MCP do Confluence oferece uma ferramenta para recuperar documentos. O agente identifica essa ferramenta, a aciona com os parâmetros necessários, recebe os documentos e os passa para o contexto do LLM a fim de preparar um resumo.

Para o usuário, trata-se de um único cenário. Ele não precisa alternar entre sistemas, não precisa procurar tarefas relacionadas manualmente e não precisa comparar diferentes status. O agente se encarrega de reunir o contexto, e a plataforma corporativa continua sendo o ponto onde esse contexto é utilizado dentro de um processo de negócios.

A vantagem dessa abordagem é a extensibilidade. Se um sistema externo já fornecer um servidor MCP, suas ferramentas podem ser conectadas por meio de um mecanismo unificado. Se não houver um servidor MCP pronto, ele pode ser implementado como uma camada separada em torno da API do sistema necessário e, em seguida, conectado ao caso de uso do agente.

Caso de Uso 3. A Plataforma Atua como um Servidor MCP

O terceiro caso de uso funciona de maneira inversa. Nos dois primeiros casos, o agente estava dentro da plataforma. Mas, em uma empresa, a lógica do agente também pode residir externamente: em um IDE, uma ferramenta CLI, um ambiente de IA separado ou uma plataforma de agentes especializada.

Por exemplo, uma equipe de desenvolvimento pode usar um agente em seu ambiente de desenvolvimento. Analistas podem trabalhar com uma ferramenta externa de IA para preparar requisitos. Engenheiros de operações podem iniciar casos de uso de agentes a partir de seu perímetro de trabalho. No entanto, todos eles podem precisar de acesso a dados e ações corporativas: criar uma tarefa, localizar um incidente, obter o status de uma alteração, visualizar um serviço relacionado ou atualizar um registro.

Para isso, a própria plataforma pode atuar como um servidor MCP. O sistema de agentes externos se conecta a ela, solicita a lista de ferramentas disponíveis, obtém suas descrições e chama os métodos necessários seguindo a lógica padrão do MCP.

Nesse caso de uso, a plataforma corporativa se torna uma fonte de ferramentas para agentes externos. Ela não se limita a aceitar solicitações via API; ela descreve ao sistema de agentes externos quais ações estão disponíveis, quais parâmetros são necessários e qual resultado pode ser retornado.

Essa abordagem é útil para empresas que já utilizam ferramentas de agentes externos. Elas não precisam transferir todos os casos de uso para dentro do sistema principal. Em vez disso, a plataforma pode se tornar parte do ecossistema de agentes e fornecer aos agentes externos acesso controlado às ações corporativas.

Ao mesmo tempo, o controle sobre a lógica de negócios permanece dentro do sistema. O agente externo não trabalha diretamente com o banco de dados e não contorna as regras do processo. Ele chama métodos publicados, que são executados no lado da plataforma.

Antes de passarmos aos casos de uso do MCP, vamos definir separadamente o papel do Nexus. Sem esse termo, a arquitetura do SimpleOne GenAI ficaria incompleta: o agente escolhe uma ação, o adaptador descreve as ferramentas disponíveis, o método realiza uma operação específica e o Nexus lida com a conexão ao modelo de IA propriamente dito.

O Papel do Nexus

Nos casos de uso do agente, o Nexus é responsável pela conexão controlada com o serviço de destino. Na maioria das vezes, trata-se de um LLM: o Nexus especifica qual modelo usar, com quais parâmetros, sob quais regras e por meio de qual endpoint.

Mas essa entidade vai além da mera configuração do modelo. Por meio do Nexus, a plataforma também pode descrever a interação com outras redes neurais ou serviços externos.

Para a arquitetura de agentes, essa é a camada de infraestrutura: o agente precisa de um modelo ou serviço externo, e a plataforma deve se conectar a eles de forma estável e previsível. Portanto, o Nexus pode ser visto como uma rota para um serviço, por meio da qual o caso de uso do agente obtém acesso ao modelo ou à ferramenta externa necessária.

O que é importante para casos de uso corporativos

Quando um agente pode realizar ações em um sistema corporativo, um mecanismo apenas para chamar ferramentas não é suficiente. É importante definir com antecedência o que o agente tem permissão para fazer, em nome de quem está agindo e como a empresa poderá verificar seu trabalho.

1. Direitos de acesso

Ao trabalhar com processos corporativos, um agente deve operar dentro de limites definidos: usar apenas ferramentas permitidas, passar os parâmetros esperados e retornar o resultado por meio da lógica da plataforma. Portanto, o acesso a dados e ações deve ser determinado não apenas pelo conjunto de ferramentas, mas também pelas regras da plataforma.

No modelo-alvo, o agente atua por meio de ferramentas explicitamente publicadas. Cada ferramenta descreve uma ação específica, parâmetros e o resultado esperado. Isso permite não entregar o “sistema inteiro” ao agente, mas fornecer um conjunto limitado de operações para um caso de uso específico.

Para ações que alteram dados, pode ser necessária uma política separada: por exemplo, confirmação do usuário, restrição baseada em função ou divisão das ferramentas em operações somente leitura e gravação.

2. Auditoria e rastreabilidade

Se um agente criou uma tarefa, atualizou um registro ou recebeu dados de um sistema externo, isso deve ficar visível em um log. Para operações e segurança, é fundamental entender:

• Quem iniciou a solicitação;
• Qual agente foi chamado;
• Qual modelo foi utilizado;
• Qual ferramenta o LLM escolheu;
• Quais parâmetros foram passados;
• Onde a ferramenta foi executada: dentro do SimpleOne ou em um servidor MCP externo;
• Qual resultado foi retornado;
• Se a ação foi executada automaticamente ou após confirmação.

Essa rastreabilidade é necessária não apenas para investigar erros. Ela ajuda a aprimorar os casos de uso: permite identificar onde o agente escolhe uma ferramenta inadequada, onde faltam parâmetros e quais ações mais frequentemente exigem intervenção manual.

3. Erros e indisponibilidade de ferramentas

Em processos reais, um sistema externo pode estar fora do ar, um servidor MCP pode retornar um erro e a solicitação de um usuário pode estar incompleta. Portanto, um caso de uso do agente deve levar em conta mais do que apenas o “caminho ideal”.

Por exemplo, se uma ferramenta externa estiver indisponível, o agente não deve inventar uma resposta. Ele deve declarar explicitamente que não conseguiu recuperar dados do sistema necessário e mostrar qual parte do contexto está faltando.

Se os parâmetros forem insuficientes, é melhor que o agente peça esclarecimentos do que execute uma ação com dados incorretos. Para operações que alteram o estado — como criar uma tarefa ou atualizar um status —, a confirmação pré-execução pode ser ativada.

4. Segurança de servidores MCP externos

Conectar um servidor MCP externo amplia as capacidades do agente, mas traz questões de confiança. É preciso saber exatamente quais ferramentas esse servidor externo oferece, quais dados estão sendo enviados para fora da rede e quais ações o agente pode acionar remotamente.

Portanto, um servidor MCP externo não deve ser de acesso livre para todos. É preciso adicionar conscientemente suas ferramentas apenas aos adaptadores dos agentes que realmente precisam delas. Isso reforça o princípio do privilégio mínimo.

5. Operação e monitoramento

Para uso corporativo, é preciso monitorar a integridade de toda a operação, não apenas as respostas do chat. São necessárias métricas sobre o LLM, a conexão com o Nexus, o adaptador, os métodos internos e as ferramentas externas.

Na prática, é preciso acompanhar chamadas, erros, latência, tempo de inatividade do sistema e a frequência com que um ser humano precisou intervir. Sem essa observabilidade, gerenciar a lógica do agente como parte de uma plataforma corporativa é quase impossível.

Por que o MCP é mais do que “acesso à API”

Não pense no MCP apenas como mais uma forma de fornecer acesso à API de um LLM. Seu propósito é muito mais profundo: ele cria uma relação gerenciável e padronizada entre a IA e as ações corporativas.

Uma API é um contrato escrito para um desenvolvedor humano. Um servidor MCP descreve ferramentas especificamente para um agente de IA: eis o que faço, eis o que preciso e eis o que vou retornar. Isso não substitui sua API; o servidor MCP geralmente apenas a envolve. Mas essa descrição no nível da ferramenta é vital porque o LLM escolhe ações com base em descrições, e não escrevendo código na hora.

No SimpleOne, essa lógica é complementada por métodos internos de IA. Quando uma ação pode ser executada dentro da plataforma, não é necessário um servidor MCP externo. Quando o agente precisa de contexto externo, o SimpleOne pode se conectar ao servidor MCP de outro sistema. E quando um agente externo precisa das ações do SimpleOne, a própria plataforma pode publicar seus métodos como ferramentas MCP.

Essa separação é fundamental para a empresa. O agente não deve ser uma solução alternativa que contorne o sistema corporativo; ele deve ser um participante de sua arquitetura. Assim, ele pode ser incorporado a processos reais: análise de incidentes, trabalho com tarefas de desenvolvimento, suporte a usuários, processamento de solicitações, elaboração de resumos e outros casos de uso em que a flexibilidade de um LLM precisa ser combinada com a capacidade de gerenciamento de uma plataforma.

Essa distinção é o motivo pelo qual o MCP é tão crucial para a empresa. O agente não é um “hack” nem uma solução alternativa; ele se torna uma parte estruturada da arquitetura. É assim que você integra com segurança a IA a fluxos de trabalho reais — desde a análise de incidentes e tarefas de desenvolvimento até o atendimento de solicitações e a geração automatizada de relatórios — combinando a flexibilidade de um LLM com uma governança rigorosa no nível da plataforma.

Resumo

O verdadeiro valor do MCP nas empresas não está no fato de o agente simplesmente “obter acesso à API”. Trata-se de criar uma camada governada e padronizada de ferramentas entre o LLM e seus sistemas centrais.

Essa camada permite que os agentes vão além das perguntas e respostas básicas e comecem a interagir com dados e processos dentro de limites claramente definidos: por meio de métodos descritos, com controle de acesso rigoroso, execução previsível e uma trilha de auditoria completa. Para plataformas corporativas, essa é a ponte essencial a ser atravessada para passar de “assistentes de IA” para verdadeiros agentes de IA que participam ativamente dos fluxos de trabalho de negócios.

O módulo MCP já está em operação no SimpleOne GenAI. Atualmente, estamos expandindo nossos casos de uso, com foco nos pilares das operações de nível empresarial: direitos de acesso granulares, auditabilidade, integração segura de ferramentas externas, tratamento de erros e monitoramento aprofundado.