Claude Cowork: integrações e fluxos de projeto

Ferramentas externas com MCP - Apresentação

Introduzindo o curso de Cloud Coworking

Bem-vindos ao curso de Cloud Coworking, uma continuação do curso com esta ferramenta, onde desta vez vamos criar toda a infraestrutura. Assim como criamos nossa infraestrutura para organizar nossos OKRs, teremos um assistente a longo prazo para organizá-los. Agora, vamos criar um assistente como um gestor de projetos.

Temos um novo projeto em Cloud, onde tivemos as conversas necessárias, e vamos criá-lo. Vamos organizar e ensinar como queremos e como fazemos para ter uma gestão de tarefas de vários projetos ao mesmo tempo dentro de um único assistente no Cloud Coworking.

Desenvolvendo a infraestrutura e visualizando resultados

Durante este curso, além de desenvolver toda a infraestrutura e ensinar como queremos que funcione, podemos visualizar no Obsidian como ficará o resultado. Temos nosso arquivo de instruções, que já exploramos bastante no primeiro curso, e o arquivo do Cloud, onde inserimos algumas instruções adicionais. Criamos uma pasta separada para cada projeto, conforme mencionado anteriormente, o que pode ser viável e, em alguns casos, faz sentido ter duas pastas de projetos diferentes dentro de um mesmo projeto, do mesmo assistente no Coworking. Dentro de cada uma delas, há uma estrutura que seguirá nosso projeto.

Resumindo projetos e integrando ferramentas

Cada projeto terá um resumo, incluindo seu alcance, quem são os stakeholders, como queremos que a comunicação seja feita, e as reuniões realizadas, com as respectivas datas. Além disso, teremos nossos conectores. Vamos conectar este projeto com o ClickUp e o Google Calendar, de modo que não precisemos organizar essas ferramentas individualmente. O ClickUp será alimentado pelo assistente, que desmembrará as tarefas e as colocará no ClickUp. O assistente também terá acesso ao nosso calendário para criar reuniões. Ele poderá criar e realizar reuniões, pedindo permissão para isso, e veremos como configurar essas integrações com ferramentas externas de maneira segura, entendendo o protocolo e como isso é feito nos bastidores.

Concluindo com expectativas do curso

Vamos realizar muitas atividades neste curso, criando uma infraestrutura completa para auxiliar na gestão de processos, e esperamos que aproveitem.

Ferramentas externas com MCP - O desafio das novas interfaces

Utilizando o Ocloud para criar agentes

Estamos utilizando o Ocloud para criar nossos agentes e assistentes, como os chamamos, para facilitar nosso trabalho. No curso anterior, vimos que podíamos ensiná-los, tínhamos as instruções e habilidades que podíamos criar, mas ainda era muito limitado a realizar tarefas dentro do nosso computador.

Queremos discutir os problemas que surgiram com a chegada dos agentes, com a criação das IAs e das LLMs (Large Language Models, ou Modelos de Linguagem Grande), quando pensamos em integrá-los com outros sistemas. Considerando nosso caso, temos sistemas como Trello, Gmail, Calendário e Google Drive, que podemos integrar em nosso agente. No entanto, como esses sistemas foram pensados inicialmente? Que problemas isso gera, ou que problemas tivemos inicialmente, e como foram resolvidos? É isso que vamos explorar neste curso.

Apresentando os desafios de integração com sistemas

Queremos apresentar esses problemas, dar contexto sobre as dificuldades de integrar um agente com um sistema e algumas limitações que podemos encontrar, especialmente em sistemas que ainda não foram adaptados para trabalhar com agentes e LLMs. Por que isso acontece? Antes das IAs e LLMs, todas as integrações entre sistemas e serviços eram feitas através das chamadas APIs REST, ou simplesmente APIs. Nosso sistema tinha uma API, e podíamos conectar a ela para extrair dados ou alterar informações.

Essas APIs REST permitiam que ferramentas como Zapier, N8n, Make e Power Automate da Microsoft fizessem a conexão entre várias ferramentas, possibilitando a criação de fluxos automatizados. No entanto, essas APIs REST não foram pensadas para as IAs, pois elas não existiam na época. A API REST surgiu no início dos anos 2000, quando não havia LLMs ou essa nova interface.

Explorando limitações das APIs REST

Aqui encontramos um problema, pois costumávamos ter nosso back-end, que é o servidor onde as informações estão e onde o sistema opera, e um cliente, que é nosso site, chamado de front-end, ou um aplicativo móvel, tudo isso na categoria de front-end. Também podíamos ter outro sistema externo, como N8n, Make ou Power Automate, conectados ao nosso sistema principal.

Por exemplo, se temos um quadro no Trello ou no ClickUp, que está conectado ao nosso servidor, esse serviço é o próprio ClickUp. Se quisermos modificá-lo através do N8n, o N8n é um serviço externo que se conecta via API e realiza essa integração. Os agentes trazem novos desafios, pois esse tipo de API não foi pensado para que o agente interaja com ela. Quando tentamos conectar um agente LLM a esse serviço, ele não consegue interagir por padrão, pois não sabe como fazê-lo.

Discutindo a personalização e documentação das APIs

Isso ocorre porque, quando as interações foram pensadas com REST, tínhamos maneiras de projetar as APIs e formas de pensar nessas integrações, considerando que havia outra pessoa do outro lado, lendo uma documentação, entendendo onde estão as coisas e buscando os chamados endpoints para fazer as conexões de maneira quase personalizada. Existia um padrão, afinal, a API REST. REST é, de fato, um protocolo que estabelece alguns padrões, mas havia uma série de personalizações que muitas vezes podíamos e devíamos fazer.

Essa parte de personalização é um dos problemas cruciais para os LLMs. O protocolo REST tem padrões de organização dos recursos e das ações que podemos executar no servidor, mas não fornece de maneira centralizada como podemos descobrir as chamadas rotas. Por exemplo, se quisermos mudar um cartão de uma coluna de um quadro em que estamos trabalhando, precisamos saber qual é a rota e a chamada que precisamos fazer. Se quisermos criar um novo cartão, é outra chamada que precisamos fazer. Todas essas chamadas são rotas que mencionamos ao integrar sistemas. Para a IA, não há uma forma natural de descobrir isso.

Propondo soluções para integração de IAs

Seria muito mais fácil ter um lugar centralizado para listar todos os recursos disponíveis em uma API, com cada um deles acompanhado de uma descrição sobre sua utilidade, permitindo que a IA chame o que for necessário. No entanto, isso não existe no REST, que não possui um local centralizado. O mais próximo que temos de algo centralizado no REST é a própria documentação.

Uma das formas de a IA fazer a integração é lendo a documentação, acessando o site de documentação do sistema, compreendendo essa documentação e tentando montar as chamadas com base no que entendeu. O problema é que nem todo sistema possui documentação, e nem toda documentação está atualizada. Assim, a IA pode tentar fazer uma chamada baseada na documentação que não corresponde à realidade, gerando uma série de problemas.

Destacando a necessidade de um novo protocolo

Outra questão é que o REST, como tipo de API e forma de integrar sistemas, não nos fornece ou facilita uma descrição do que cada recurso faz dentro do próprio sistema. Quando chamamos, por exemplo, a rota de criação de uma tarefa no Trello, nós sabemos que essa é a rota correta. Porém, a IA só pode descobrir isso por meio da documentação, que, como mencionado, possui suas limitações.

Falta uma integração no próprio sistema, uma documentação ou descrição do que cada recurso faz, para que o LLM saiba quando utilizar cada um. Nosso agente, o Cloud que estamos usando, tomará decisões baseadas na solicitação feita. Se pedirmos para criar um novo quadro, preenchê-lo com listas X, Y, Z e criar cinco tarefas no backlog, que são as próximas tarefas, teremos três ações diferentes, que seriam pelo menos três chamadas diferentes na API REST. O agente precisa decidir a ordem dessas ações: criar o quadro, depois as listas, ou as tarefas primeiro. Ele precisa entender o fluxo e qual chamada executar para cada ação. Isso não está presente no protocolo REST por padrão.

Introduzindo o protocolo MCP

Embora o REST seja um protocolo com um padrão de organização, ele ainda possui uma série de personalizações e formas diferentes de realizar certas ações. Por exemplo, para criar uma tarefa no Trello, a equipe de Trello pode ter implementado duas ou três maneiras diferentes de realizar essa funcionalidade. Existe um padrão, mas também personalização.

A ideia original era que uma pessoa estivesse do outro lado, lendo a documentação, testando o sistema e criando as integrações de forma personalizada. Com a chegada das IAs, surgiu a necessidade de criar um novo protocolo. A Antropica, que é proprietária do Cloud, desenvolveu esse novo protocolo pensando nesse problema. Precisamos de uma ferramenta como um LLM, um gerador de texto, imagem ou áudio poderoso, mas que não está conectado aos serviços que já usamos. Diante dos problemas do protocolo das APIs REST, foi necessário criar um novo protocolo que resolvesse essas questões.

Assim, surgiu o protocolo MCP, o Model Context Protocol. Esse protocolo visa resolver os problemas do REST, criando uma forma padrão de descoberta das capacidades de um sistema, onde agentes de IA têm acesso facilitado a uma interface projetada para seu uso. Não estamos pensando em um humano fazendo a integração, mas exclusivamente em um agente de IA, um LLM, que fará as chamadas ao sistema através do protocolo MCP. Esse protocolo é necessário para que as ferramentas sejam implementadas e os agentes possam se integrar e utilizá-las. Vamos explorar mais sobre o funcionamento desse protocolo, mas esse é o problema que ele tenta resolver e que a Antropica considerou ao criar seus padrões.

Ferramentas externas com MCP - O protocolo MCP

Explicando o protocolo MCP e sua aplicação

Vamos entender agora como funciona o protocolo MCP, como será implementado e como o encontraremos no dia a dia, caso estejamos buscando. Este protocolo será utilizado no curso, especialmente no contexto de Cloud, mas não se limita apenas a isso. Qualquer LLM (Modelo de Linguagem Grande) ou ferramenta que seja um agente de IA pode ou deve ter acesso aos MCPs para facilitar integrações. Portanto, é importante lembrar que ele não funciona apenas no Cloud, mas em qualquer LLM ou ferramenta que tenha acesso a um cliente MCP. Vamos explorar como isso funciona.

Primeiro, temos algumas limitações de contexto, trazendo um pouco das camadas que estão sendo construídas. Inicialmente, temos a criação dos LLMs, como o ChatGPT, o Gemini e o próprio Cloud. No entanto, não estamos falando do Cloud como o usamos inicialmente, mas sim da camada do LLM, que é o gerador de texto e imagens, a base sobre a qual o Cloud opera. Estamos trabalhando com o Cloud Coworking, que possui a camada de LLM como motor para processar texto e nos responder, mas ele oferece muito mais. Tem acesso a rotas, pode gerar e entender arquivos, e possui habilidades específicas. Assim, a camada de LLM é apenas a base, responsável pelo processamento de linguagem natural.

Desenvolvendo agentes de IA e suas capacidades

Sobre essa base, foram criados os agentes de IA. Um agente de IA utiliza o LLM, mas o envolve com capacidades adicionais. No caso do Cloud, há habilidades, regras a serem seguidas (word rails) e um ciclo de execução que verifica se uma tarefa está correta antes de fornecer uma resposta. Assim, a camada do LLM, que era apenas de processamento de linguagem, ganha mais habilidades e funcionalidades, tornando-se mais potente e inteligente. A ideia é que ele possa ter várias personalidades diferentes, com pacotes de funcionalidades que cercam o LLM.

Agora, temos a próxima camada: o LLM processa a linguagem, mas também possui mais habilidades e formas de personalização para aumentar sua potência e capacidade de realizar tarefas. No entanto, no dia a dia, precisamos conectar isso ao mundo externo e às ferramentas que já utilizamos, como Google Sheets, Excel, e-mail e Slack. Antes do protocolo MCP, essa ferramenta poderosa não se conectava a nada disso. Essa é a próxima camada, e veremos a evolução desse tipo de ferramenta.

Integrando LLMs com ferramentas externas

Uma forma comum de pensar na arquitetura do LLM é como a encontraremos na vida real. Por exemplo, temos o caso do ClickUp e do Trello, discutido anteriormente, e nosso back-end REST. Esse back-end já existia antes dos LLMs e das IAs. Tínhamos o front-end, o próprio site do Trello e do ClickUp, que podiam se conectar a esse back-end. Também havia a possibilidade de ferramentas externas se conectarem a ele, como N8n, Make e Power Automate. Se quiséssemos, poderíamos, como pessoas desenvolvedoras, fazer uma integração personalizada com essas ferramentas.

Agora, temos uma camada adicional: precisamos de um servidor que se comunique no protocolo MCP com nossa IA. Nosso agente de IA se conectará a um servidor MCP. Esse servidor, por sua vez, estará conectado ao nosso agente de IA e traduzirá o que ele solicita para nosso back-end REST. Nessa tradução, ele poderá executar todas as tarefas ou aquelas que tiver capacidade de traduzir, que já existiam no sistema. Se já havia uma forma de criar cartões, quadros e listas no Trello, o servidor MCP poderá traduzir isso para que o agente de IA saiba que essas capacidades existem e como invocar cada uma delas. Essa camada servirá como uma camada de tradução.

Implementando servidores MCP e suas funções

Esta é a forma mais comum de encontrarmos esse tipo de servidor e serviço implementado nas empresas. Teremos uma camada adicional ao redor do nosso serviço, pois o serviço em si já existia. No entanto, podemos afirmar que novos serviços, criados diretamente para a IA, não terão essa parte do back-end. Serão apenas um back-end MCP, chamando diretamente todas as funcionalidades. Esses são os serviços mais novos que podem ser criados com outra arquitetura.

Para que o MCP funcione, temos algumas partes. Temos o LLM Host, que, no nosso caso, é o Cloud. O Cloud é nosso LLM Host, hospedando nossa inteligência artificial. Esse host terá um cliente MCP. Pensemos assim: no caso mais comum do Trello, temos nosso back-end, que é o servidor do Trello, e nosso navegador, como o Google Chrome, servindo como cliente, acessando o site e mostrando as interações. Esse cliente é apenas uma interface para conectar-se ao serviço.

Explorando a conectividade e o papel do MCP

Essas duas partes já estão prontas para nós dentro do Cloud for Working. Elas vêm na ferramenta, mas são necessárias. Se sairmos do Cloud e usarmos outras ferramentas, é preciso considerar qual será nosso LLM Host. Pode ser o Cloud, Anthropic, GPT, Gemini ou qualquer LLM desejado. Será necessário ter um serviço de MCP Client, que, no caso do Cloud, já está embutido na ferramenta, e tudo isso se conectará ao nosso serviço, nosso servidor MCP. Esse servidor MCP terá acesso às ferramentas e à própria API do serviço que queremos acessar. Assim funciona o MCP. É assim que o veremos funcionar. Essas camadas se comunicam e terão chamadas de entrada e saída entre elas.

Portanto, temos tudo isso, o Client MCP e o LLM Host, já no Cloud, e precisaremos identificar quais são os serviços e servidores MCP que queremos conectar. Também é necessário verificar se as ferramentas que desejamos conectar possuem um serviço desse tipo, pois pode ser que não exista ou não esteja implementado ainda.

Resumindo o funcionamento e as vantagens do MCP

Aqui temos uma tabela descrevendo um pouco para que serve o MCP, um resumo do que foi mencionado. A ideia é que o MCP dê acesso a ferramentas para agentes, permitindo que executem ações em nosso serviço, em nosso servidor. Eles farão a integração de APIs, bases de dados e arquivos do local junto com esse agente. Um agente pode solicitar informações que estão na base de dados do nosso sistema, chamar as APIs para executar ações ou solicitar arquivos, como no caso do Google Drive, por exemplo. Assim, ele pode realizar esse tipo de operação.

O papel do nosso servidor é fornecer essa mão de obra. Como mencionado, nosso LLM, nosso agente, está limitado, por enquanto, a usar apenas o que está dentro do nosso computador, inclusive dentro da pasta que criamos. Ao dar acesso a uma ferramenta MCP, ele terá assistentes, mão de obra fora do nosso computador que pode utilizar. Vamos nos concentrar em fazer com que o agente atue no mundo real. Nosso computador é fechado, seguro, mas muito limitado. Nosso trabalho ocorre em outros lugares, que chamamos aqui de mundo real.

Destacando a natureza determinística do MCP

Uma característica interessante do MCP, do protocolo, é que ele é determinístico. Ou seja, quando nosso agente chama um comando ao servidor MCP e solicita a execução de algo, se fornecer a mesma entrada para esse comando, sempre terá a mesma saída, o que é diferente do próprio LLM. Quando pedimos ao LLM, por exemplo, para saber como estará o clima amanhã ou para fazer um resumo do dia, mesmo que façamos a mesma solicitação três vezes, o LLM dará respostas diferentes, ainda que o texto inicial seja o mesmo. Isso significa que o LLM em si não é determinístico. Dada a mesma entrada, ele responderá de forma diferente, embora dentro do tema solicitado. Já no MCP, ao invocar uma ferramenta para criar uma tarefa no Trello, se passarmos sempre o mesmo comando, a resposta será sempre a mesma. Assim, é mais controlado, e seu alcance opera na camada de execução. Quando queremos que o agente execute e faça algo no mundo real, ele usará esse servidor MCP disponível.

Conectando ferramentas no projeto Cloud Core

Aqui está um resumo dos servidores MCP que podemos utilizar. Agora, vamos conectar nossas ferramentas dentro do nosso projeto no Cloud Core.

Sobre o curso Claude Cowork: integrações e fluxos de projeto

O curso Claude Cowork: integrações e fluxos de projeto possui 149 minutos de vídeos, em um total de 35 atividades. Gostou? Conheça nossos outros cursos de Automação e Produtividade em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Ferramentas externas com MCP
• Conectores
• Infraestrutura de gestão
• Hooks
• Manutenção de rotina