Primeiras aulas do curso
Bem-vindos a mais um curso aqui na Alura. Sou Ricardo Bugan, Head de Produto e Tech Lead. Fui Tech Lead por muito tempo e serei o instrutor neste curso.
Neste curso, exploraremos o N8n, entendendo como ele funciona e para que serve, além de onde encaixamos os servidores MCP dentro de nossa arquitetura. Vamos aprender a utilizar essa nova tecnologia e protocolo para oferecer acesso aos nossos clientes.
Um cliente, um agente de IA, terá acesso ao nosso MCP e, então, às ferramentas que disponibilizamos. Vamos pensar em como integrar essas ferramentas aos nossos sistemas já existentes. Para isso, vamos criar nosso MCP, nosso servidor MCP. Vamos liberar algumas ferramentas para esse cliente e entender como essas coisas se encaixam, como funcionam, para que servem, quais problemas resolvem e como nos afetam no dia a dia como pessoas desenvolvedoras.
Vamos explorar onde isso poderia se encaixar e como trabalhamos com essa nova interface que está surgindo, que são os agentes de IA, que não têm facilidade para lidar com REST. Vamos criar esse servidor e explorar essas ferramentas, esse novo protocolo, dentro deste curso. Esperamos vocês lá!
A proposta deste curso é entender como funciona o MCP e como trabalhamos com ele. Para isso, começaremos explorando os problemas que enfrentamos ao integrar agentes de IA ou algum LLM (Large Language Model, ou Modelo de Linguagem Grande) em nossa aplicação. Precisamos adaptar o sistema e identificar os desafios que os agentes de IA nos apresentam, como pessoas desenvolvedoras, e que precisamos resolver.
Antes da introdução dos LLMs, as integrações entre sistemas eram feitas principalmente através de REST, um protocolo amplamente utilizado e ainda muito comum. Toda a integração do sistema era realizada com REST. Tínhamos um back-end que se comunicava com um cliente, como o front-end, que consultava informações no servidor por meio de chamadas à API REST. Também era possível ter outro sistema interno, um BI, ou uma integração de um sistema terceiro, que manipulava o serviço de forma externa, tudo através de REST.
Com a introdução dos agentes de IA, queremos integrá-los nessa infraestrutura existente para que possam operar e manipular informações em nosso sistema. Um agente de IA é um software que utiliza o LLM para fornecer respostas, algo que antes era passivo, onde inseríamos um input e esperávamos uma resposta em um contexto isolado. Agora, queremos que esses agentes tenham agência, ou seja, que possam agir em nosso lugar, tomar decisões e manipular sistemas.
Para isso, precisamos de uma interface que se encaixe em nosso back-end, permitindo que um agente de IA interaja com ela, assim como o front-end ou um sistema externo interage através das APIs REST. As integrações com REST eram feitas manualmente por uma equipe de software que estudava a API e a documentação, mas sabemos que isso demanda trabalho. Embora REST tente padronizar, não consegue estandardizar 100% das coisas, especialmente o descobrimento.
No protocolo REST, não há um padrão de organização de recursos que inclua o descobrimento de rotas padronizadas. Não podemos chamar uma API ou uma rota específica que seja igual em todos os sistemas integrados e que informe as capacidades e rotas disponíveis com seus recursos. Essa parte do descobrimento não é fácil, especialmente para a IA, que pode interagir com a API REST, mas enfrenta dificuldades nessa área.
Outro problema que o REST apresenta, que não ajuda na integração com agentes de IA, é a falta de descrição. Mesmo que possua rotas parecidas ou uma padronização mínima de como chamar cada rota, através dos métodos, da nomenclatura e outros aspectos, não é necessariamente óbvio ou claro como essa rota será chamada, como irá modificar o recurso ao qual estamos chamando, ou que informações podemos enviar, que tipo de filtro podemos aplicar. Portanto, essa descrição de como manipular esse endpoint, essa rota no REST, também não é tão óbvia se não lermos a documentação. Precisamos da documentação, pois não há uma autodescrição fácil. E, no final, devido a essa falta de um padrão global, temos uma implementação personalizada para cada serviço, para cada interface, para cada back-end que desejamos integrar. Isso também acaba complicando nossa vida, quando temos esse tipo de integração que é personalizada por serviço.
Para ilustrar, vejamos um exemplo de como isso funciona. Se tivermos uma loja de roupas e uma farmácia chamada Farmácia San José, podemos chamar o método GET na rota produto, ou na rota produtos, no caso da farmácia, para realizar uma busca de todos os produtos existentes. No caso do comércio de roupas, na rota /produto, busca-se todos os produtos existentes na loja, sem filtro. Enquanto que na Farmácia San José, utiliza-se produtos, no plural, e busca-se todos, mas também permite filtros através de query params. Assim, a rota é muito parecida, o que queremos fazer é muito similar, mas a forma de manipulá-la é diferente, e isso pode causar problemas para nosso agente.
Outro exemplo: no comércio de roupas, obtemos o produto por ID com GET e retornamos os detalhes do produto específico da loja. Na Farmácia San José, utiliza-se o GET em produto, agora no singular, que, se observarmos, essa rota seria igual à do comércio de roupas, mas seu comportamento é diferente, pois irá devolver os detalhes de um produto cujo ID foi especificado no body param. Aqui temos esse detalhe.
No comércio de roupas, temos um PUT com o ID do produto, onde modificamos a informação do produto; espera-se uma atualização completa desse produto. Na Farmácia San José, temos um PATCH produto, onde atualizamos parcialmente o produto especificado também pelo ID no body param. Assim, duas APIs que falam de produtos, mas que podemos manipular de maneiras bastante diferentes. E, por mais que se diga que é muito parecido, é suficientemente diferente para que uma IA ou um sistema autônomo que precise ser integrado de forma automática aqui, enfrente problemas.
O NCP vem para resolver esse tipo de problema, oferecendo um padrão de descoberta das capacidades que um back-end expõe para nós e uma implementação mais padronizada do que a do REST. Podemos fazer REST através de ferramentas de CLI, de terminal, podemos fazer REST. Podemos chamar e fazer requisições no formato REST. Mas o MCP vem com uma forma de facilitar e proporcionar essa descoberta e a descrição das ferramentas disponíveis em nosso servidor. É um protocolo que tenta resolver o problema de como integrar um agente de IA em um sistema que já existe, ou em um sistema que pode ser manipulado e que possui seu servidor com back-end, com o estado da aplicação em si. Este é o problema que o MCP tenta resolver e é isso que vamos explorar neste curso.
Para compreendermos o problema que o MCP resolve, vamos desmembrar suas partes, entender como funciona em um nível elevado, em um nível de apresentação, e como o implementamos e integramos em nossa arquitetura como um todo.
Primeiramente, é importante entender que o MCP foi criado para ajudar com as limitações de contexto mencionadas anteriormente. A primeira camada envolve a criação dos LLMs (Large Language Models, ou Modelos de Linguagem Grande). Inicialmente, utilizávamos esses modelos apenas para chat, fazendo perguntas e obtendo respostas diretamente, o que implicava em uma criação de texto fechada em um contexto específico da ferramenta, como o chat GPT, sem integração ou autonomia para interagir com sistemas externos. Era um sistema autocontido.
Posteriormente, surgiram os agentes de IA, que consistem em aproveitar a capacidade da ferramenta de gerar e interpretar texto, além de imagens e outras modalidades, para dar autonomia a essa ferramenta. Isso permite que ela pense em soluções diferentes, raciocine mais profundamente sobre problemas e discuta temas. No início, os agentes ainda estavam limitados a esse contexto, mas ganharam capacidades de discussão, argumentação e contraponto, que não existiam na primeira versão dos LLMs.
A seguir, surgiu a necessidade de dar autonomia ao LLM para interagir com outros sistemas. Desejamos ter um assistente pessoal que escreva código e o suba para o GitHub, programe eventos no calendário, cuide da agenda e envie lembretes. Para isso, precisamos de uma interface entre o GitHub, o calendário, o Excel da empresa, a folha de metas e o agente que processará e manipulará essas informações, permitindo autonomia. A grande diferença aqui é a autonomia dada a essas ferramentas baseadas em LLM.
Assim, temos a terceira camada, que é a conexão do agente com o mundo externo através do MCP. O servidor MCP é composto por um servidor, que possui o protocolo, e também por um cliente. Nesse sentido, é semelhante ao REST. Temos um cliente que faz uma solicitação ao servidor, o qual processa a solicitação e devolve a resposta. A arquitetura cliente-servidor continua funcionando aqui.
Em um cenário mais real, especialmente para empresas já operacionais com equipes estabelecidas, há outro tipo de arquitetura presente. Atualmente, já temos um backend em REST que atende ao cliente no front-end, além de dispositivos móveis e sistemas externos. Onde o MCP se encaixa nesse esquema? Podemos ter um servidor MCP que se conecta e faz a interface com o REST, funcionando como um wrapper ou adaptador para o agente de IA da API REST.
Dessa forma, nosso agente de IA se comunica com o backend MCP, que realiza a comunicação direta conosco. Ele, por meio das ferramentas que possui, interage com nosso REST, nosso sistema principal, onde ocorre a manipulação da informação. O MCP torna-se um adaptador, um interceptor no meio do caminho, permitindo que o agente de IA manipule nosso sistema, que originalmente foi desenvolvido em REST.
Então, esta é uma arquitetura que observamos ser muito comum atualmente. Do lado do nosso MCP, desse protocolo, temos o LLM Host. Nosso agente de IA terá dentro de si uma ferramenta que é o Client MCP. Assim, nosso agente, que é o LLM Host, terá um cliente internamente. O cliente fará a comunicação com o servidor, estando emparelhado com ele, e podemos ter vários clientes MCP conectados a vários servidores diferentes dentro do mesmo host.
Nosso servidor possui internamente as ferramentas e as APIs que pode invocar, permitindo um controle mais granular. Toda essa comunicação entre as partes do MCP será realizada por meio de entradas e saídas com JSON RPC. RPC não é um protocolo novo, já existe há bastante tempo, mas é diferente do REST, que não era tão utilizado. Na época dos microserviços, houve até uma discussão sobre o JRPC, um padrão do Google para reduzir o tráfego dentro dos clusters de Kubernetes ou Docker. Portanto, é um protocolo que já existe há bastante tempo.
O protocolo RPC se baseia em chamadas a funções, em vez de rotas. Temos chamadas a funções diretamente, e a ideia é que seja mais leve e ocupe menos largura de banda que o REST. Toda a comunicação entre nosso host, o cliente e o servidor será feita através de JSON RPC. São chamadas, pacotes JSON com a ferramenta que queremos invocar, a descrição e a saída. Este é o protocolo de entrada e saída entre as partes, principalmente entre o cliente e o servidor. O host chama o cliente diretamente, sendo uma ferramenta que está ali de forma direta, e o servidor já possui as funções que invocam as próprias ferramentas. Entre cliente e servidor, principalmente, teremos os inputs passando pela rede no formato JSON RPC, que também não é novo.
Resumindo, o objetivo do MCP é fornecer ferramentas para que um agente execute ações, permitindo a ideia de autonomia. Seu foco é a integração com APIs, bases de dados, arquivos, e o que chamamos de ferramentas de forma ampla. Integração com nosso sistema, calendário, documentos no Google Drive, por exemplo. Atua como a mão de obra do agente, fornecendo as ferramentas para que ele possa atuar no mundo real. Esse é precisamente o problema que resolve: o agente atua no mundo real. É um tipo de fluxo determinístico. Uma vez que a chamada passa do cliente para o servidor MCP, o servidor MCP é código determinístico. Executará a tarefa, a função, exatamente como foi programada. Podemos passar parâmetros para essa função, assim como em uma rota REST, mas é uma chamada a uma função.
Nosso servidor MCP é determinístico, enquanto o agente e o LLM, na ponta, tendem a ser não determinísticos. Quando passamos o mesmo prompt, o mesmo input, obtemos respostas diferentes. Isso ocorre no lado do LLM, não no servidor MCP. Cada vez que passamos o mesmo input, obtemos a mesma resposta. A ideia é que seja determinístico, uma ferramenta programada para funcionar assim; não é um LLM em si. Seu alcance é de execução. Faremos uma chamada, ele executará, atuará, não pensará ou processará, nem refletirá. Realizará uma ação, chamará e executará algo. O MCP está nesse contexto. Esta é sua arquitetura, como a vemos encaixando nos sistemas já existentes hoje em dia, e para isso serve.
Agora, vamos criar nosso Alicom N8n.
O curso Model Context Protocol (MCP): otimização de agentes de IA com n8n possui 102 minutos de vídeos, em um total de 35 atividades. Gostou? Conheça nossos outros cursos de Automação & Produtividade em Inteligência Artificial, ou leia nossos artigos de Inteligência Artificial.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Todos os cursos, trilhas e certificados para evoluir.
7 dias para cancelar com reembolso
Aprenda mais rápido com IA, idiomas e imersões.
7 dias para cancelar com reembolso
TUDO DO PLUS, MAIS:
Aceleração de carreira: mentoria, vagas e prática guiada.
7 dias para cancelar com reembolso
TUDO DO PRO, MAIS:
