Claude Cowork: integrações via MCP e automação de projetos

Ferramentas externas com MCP - Apresentação

Apresentando o curso

Boas-vindas ao curso de Claude Cowork, uma continuação do curso com essa ferramenta. Assim como criamos uma infraestrutura para organizar nossos OKRs, com um assistente de longo prazo, desta vez vamos criar um assistente que funciona como um gestor de projetos.

Temos um novo projeto no Claude, onde já tivemos algumas conversas. Vamos criá-lo e ensinar a ele como queremos ter uma gestão de tarefas de vários projetos ao mesmo tempo, dentro de um único assistente no Claude Cowork.

Conhecendo a estrutura do projeto

Ao longo do curso, além de montar toda essa infraestrutura, vamos ensinar como queremos que ele trabalhe. Podemos ver no Obsidian como isso vai ficar. Temos o nosso arquivo de instruções, que já vimos bastante no primeiro curso, e o arquivo CLAUDE.md, onde ele colocou algumas instruções mais específicas.

Temos também uma pasta separada para cada projeto. Como já discutimos, é viável ter pastas de projetos diferentes dentro de um mesmo projeto, do mesmo assistente no Cowork, e em alguns casos isso vai fazer sentido. Dentro de cada pasta há uma estrutura que segue o nosso projeto: um resumo, o escopo, quem são os stakeholders, como queremos que ele faça a comunicação do projeto e as atas das reuniões que tivemos.

Conectando ferramentas externas

Além disso, teremos os nossos conectores. Vamos conectar esse projeto com o ClickUp e o Google Calendar, para não precisarmos organizar essas ferramentas individualmente. O ClickUp será alimentado pelo assistente, que vai quebrar as tarefas e colocá-las lá. O assistente também terá acesso ao calendário para criar as nossas reuniões: ele vai conseguir criar e deletar reuniões, pedindo permissão para isso.

Vamos ver como configurar essas integrações com ferramentas externas de maneira segura, qual é o protocolo e como isso funciona por baixo dos panos. Vamos fazer bastante coisa neste curso e criar uma infraestrutura completa para ajudar na gestão de processos. Esperamos que você aproveite.

Ferramentas externas com MCP - Entendendo os limites do REST

Entendendo o problema da integração

Estamos usando o Claude para criar nossos agentes, nossos assistentes, como temos chamado, para facilitar o nosso trabalho. No curso anterior, vimos que conseguíamos ensiná-lo: havia as instruções e as habilidades que podíamos criar. Mas ele ainda estava muito limitado a fazer coisas dentro do nosso computador.

Queremos discutir os problemas que surgiram com a chegada dos agentes e das IAs na hora de integrá-los com outros sistemas. No nosso caso, temos um Trello, um Gmail, um calendário, um Google Drive: vários sistemas que podemos integrar ao agente. Como esses sistemas foram pensados inicialmente, quais problemas isso gera e como isso foi resolvido é o que vamos explorar neste curso.

Vamos trazer o contexto dos problemas que temos ao integrar um agente com um sistema e algumas limitações que você talvez encontre, como sistemas que ainda não foram adaptados para trabalhar com agentes e LLMs.

Relembrando como funcionam as APIs REST

Antes das IAs e dos LLMs, todas as integrações entre sistemas e serviços eram feitas pelo que chamamos de API REST, ou, como muitas vezes falávamos, só APIs. O sistema tem uma API, e podemos nos conectar a ela para extrair dados ou mudar informações. É por meio dessas APIs que ferramentas como o Zapier, o n8n, o Make e o Power Automate, do lado da Microsoft, fazem a conexão entre várias ferramentas e nos possibilitam criar fluxos automatizados.

Só que essas APIs REST não foram pensadas para as IAs, porque elas não existiam na época. A API REST é do começo dos anos 2000, quando não existia o LLM nem essa interface nova.

Costumávamos ter o back-end, que é o servidor, onde estão as informações e onde o sistema opera, e um cliente: o site, que chamamos de front-end, ou um aplicativo mobile, também nessa categoria de front-end. Também podíamos ter outro sistema externo, como o Make ou o Power Automate, conectado ao sistema principal.

Por exemplo, se temos um board no Trello ou no ClickUp, o servidor é o próprio ClickUp. Se quisermos alterá-lo pelo n8n, o n8n é um serviço externo que se conecta por meio dessa API e faz essa integração.

Identificando os desafios para os agentes

Os agentes trazem novos desafios, porque esse tipo de API sempre foi pensado para nós interagirmos com ela. Quando tentamos conectar um agente de LLM a esse serviço, ele não consegue interagir por padrão: não sabe como interagir com o sistema.

Isso acontece porque, quando essas interações foram pensadas com o REST, considerávamos que havia outra pessoa do outro lado, lendo uma documentação, entendendo onde as coisas estão e buscando o que chamamos de endpoint, para fazer as conexões de maneira quase personalizada. Existia um padrão, afinal a API REST, o REST, é de fato um protocolo e traz alguns padrões. Mas havia uma série de customizações que você podia e, muitas vezes, precisava fazer, e essa parte de customização é um dos problemas para os LLMs.

Descobrindo as rotas disponíveis

O REST tem padrões de organização dos recursos e das ações que podemos fazer no servidor, mas não disponibiliza de maneira centralizada como descobrir o que chamamos de rotas. Se você quiser mover um card de coluna no board em que está trabalhando, é nessa rota, nessa chamada, que precisa fazer. Se quiser criar um novo card, é em outra chamada. Todas essas chamadas são rotas, como costumamos falar na hora de integrar sistemas.

A IA não tem como descobrir isso naturalmente. Seria muito mais fácil ter um lugar centralizado dizendo: "Esses são todos os recursos disponíveis nessa API, fique à vontade", cada um com a sua descrição e a sua função, e a IA chamaria o que quisesse. Mas isso não existe no REST. O mais próximo de algo centralizado que temos no REST é a própria documentação.

Uma das maneiras de a IA fazer a integração seria acessar o site da documentação do sistema, lê-la e tentar montar chamadas com o que entendeu. O problema é que nem todo sistema tem documentação, e nem todo sistema tem uma documentação atualizada. Então, às vezes, a IA vai tentar fazer uma chamada pelo que está na documentação e isso não bate com a realidade.

Descrevendo o que cada recurso faz

Outra coisa que o REST não disponibilizava é uma descrição do que cada coisa faz dentro do próprio sistema. Quando chamamos, por exemplo, a rota de criação de um card no Trello, nós sabemos que é essa rota que faz isso, mas a IA não tem como descobrir a não ser pela documentação, que, de novo, tem as suas limitações. Falta essa descrição integrada ao próprio sistema, para que o LLM saiba quando usar cada recurso.

O nosso agente, o Claude que estamos usando, vai tomar decisões com base no pedido que fizermos. Se pedirmos que ele crie um novo board, preencha com as listas X, Y e Z e crie cinco cards no backlog, porque são as próximas tarefas, ele tem três ações diferentes, que seriam pelo menos três chamadas diferentes na API REST. Ele precisa decidir o que fazer primeiro: criar o board, as listas ou os cards. Precisa entender como esse fluxo funciona e qual chamada executa cada ação, e isso não existe no protocolo REST por padrão.

Além disso, mesmo sendo um protocolo com um padrão de organização, o REST ainda permite uma série de customizações e maneiras diferentes de fazer certas coisas. Para criar um card no Trello, por exemplo, do jeito que o time do Trello implementou o servidor, existem pelo menos duas ou três maneiras diferentes. Há um padrão, mas também há customização. E a ideia, de novo, era que havia uma pessoa do outro lado, lendo uma documentação, testando o sistema e criando as integrações de maneira mais customizada quando precisávamos.

Conhecendo o protocolo MCP

Com a chegada das IAs, foi criado um novo protocolo. Foi a Anthropic, inclusive dona do Claude, que criou esse protocolo, pensando nesse problema: temos uma ferramenta muito poderosa, o LLM, um gerador de texto, imagem ou áudio, mas ele não está conectado com nenhum dos serviços que já estamos acostumados a usar. Era preciso criar um novo protocolo, uma nova maneira de conectar, que resolvesse esses problemas.

Assim surgiu o protocolo MCP. Você já deve ter ouvido falar: é o Model Context Protocol (protocolo de modelo e contexto). Ele tenta resolver os problemas que o REST tinha, criando uma forma padrão de descoberta das capacidades de um sistema, em que os agentes de IA têm acesso facilitado a uma interface pensada para eles.

Aqui não estamos pensando em um humano na outra ponta fazendo a integração e chamando o sistema. Estamos pensando exclusivamente num agente de IA, num LLM, que vai fazer as chamadas no sistema por meio do protocolo MCP. É esse protocolo que as ferramentas precisam implementar para que os agentes consigam se integrar a elas e utilizá-las.

Vamos explorar um pouco mais como esse protocolo funciona, mas esse é o problema que ele tenta resolver e que a Anthropic tinha em mente ao criar os seus padrões.

Ferramentas externas com MCP - Conhecendo o protocolo MCP

Entendendo onde o MCP se aplica

Vamos entender um pouco mais como o protocolo MCP funciona, como ele é implementado e como você vai encontrá-lo no dia a dia, se estiver buscando por ele. No curso, vamos usá-lo dentro do Claude, mas ele não funciona só no Claude. Qualquer LLM ou ferramenta que seja um agente de IA consegue, ou deveria, ter acesso aos MCPs para fazer as integrações. Ou seja, ele funciona em qualquer ferramenta que você estiver usando e que tenha acesso a um cliente MCP. Vamos ver como isso funciona.

Conhecendo as camadas: LLM e agente de IA

Primeiro, um pouco de contexto sobre as camadas que estão sendo construídas. Na base, temos a criação dos LLMs: o ChatGPT, o Gemini e o próprio Claude, mas não o Claude do jeito que estamos usando, e sim aquele chat inicial. Essa é a camada do LLM, o gerador de texto ou de imagem, a base sobre a qual o Claude trabalha. Estamos usando o Claude Cowork, que tem a camada de LLM como motor que processa o texto, mas tem muito mais: acesso às pastas, geração de arquivos, entendimento dos próprios arquivos e as habilidades. A camada de LLM é só a base, onde está o processamento da linguagem natural.

Em cima disso foram criados os agentes de IA. Um agente de IA pega o LLM e o envolve com algumas capacidades a mais. No caso do Claude, há as habilidades, os guardrails (as regras que ele tem que seguir) e o loop de execução: ele executa uma tarefa e verifica se ela está correta antes de dar a resposta. Ou seja, ele pegou a camada do LLM, de linguagem e de resposta ao que pedimos, e colocou habilidades e features a mais, que o tornam mais potente. A ideia de ter várias personalidades diferentes também entra aqui: tudo isso são pacotes de features envolvendo o LLM.

Conectando o agente ao mundo externo

A próxima camada vem daí: temos o LLM, que processa a linguagem, e damos a ele mais habilidades e mais formas de customização para que tenha mais capacidade de fazer tarefas. Mas, no dia a dia, precisamos conectar isso com o mundo externo, com as ferramentas que já usávamos. No seu trabalho, você já usava o Google Sheets, o Excel, o e-mail, o Slack, e até existir esse protocolo, essa ferramenta não se conectava com nada disso. São várias camadas que vamos construindo, e assim vemos a evolução desse tipo de ferramenta.

Visualizando a arquitetura com o servidor MCP

Agora, um jeito comum de pensar nessa arquitetura é como a encontraremos na vida real. Vamos pegar o caso do ClickUp ou do Trello, que discutimos no vídeo anterior. Temos o back-end, que já existia antes dos LLMs e das IAs. Tínhamos o front-end, o próprio site do Trello ou do ClickUp, que se conectava a esse back-end, e também a possibilidade de ferramentas externas se conectarem a ele, como o n8n, o Make e o Power Automate. Se quiséssemos fazer uma integração customizada com as ferramentas, nada nos impediria, mas já havia ferramentas acostumadas a fazer isso.

Agora temos uma camada a mais: precisamos de um servidor que converse com a IA nesse protocolo MCP. O agente de IA vai se conectar a um servidor MCP, um back-end MCP. Esse servidor vai traduzir o que o agente de IA está pedindo para o back-end REST e, nessa tradução, vai conseguir executar todas as tarefas que já existiam no sistema, ou as que tiver capacidade de traduzir.

Se já havia um jeito de criar cards, boards e listas no back-end do Trello, no servidor do Trello, o servidor MCP vai traduzir isso para que o agente de IA saiba que essas capacidades existem e como chamar cada uma delas. Ele serve como essa camada de tradução.

Esse é o jeito mais comum de encontrarmos esse tipo de servidor implementado nas empresas: uma camada a mais em volta do serviço, porque o serviço em si já existia. Mas os serviços novos, criados agora e já pensados diretamente para IA, podem não ter essa parte do back-end: serão só um back-end MCP, chamando direto todas as funcionalidades. Ou seja, os serviços mais novos podem ser criados com outra arquitetura.

Identificando as partes do MCP

Para o MCP funcionar, temos algumas partes. Há o LLM Host, que no nosso caso é o Claude: ele é o hospedeiro do LLM, da nossa inteligência artificial. Esse host tem um cliente MCP. Pense no caso mais comum do Trello: temos o back-end, que é o servidor do Trello, e o navegador, o Google Chrome, por exemplo, servindo como cliente, acessando o site e mostrando as interações. O cliente é só uma interface para conseguir se conectar com o serviço.

Essas duas partes já estão prontas dentro do Claude Cowork: já vêm na ferramenta, mas são necessárias. Se você sair do Claude e estiver mexendo em outras ferramentas, precisa pensar em qual é o seu LLM Host: pode ser o Claude, da Anthropic, o GPT, o Gemini, o Llama ou qualquer LLM que você quiser. Você vai precisar de um serviço de cliente MCP (MCP Client), que, no caso do Claude, já está embutido na ferramenta. Tudo isso se conecta ao servidor MCP, que tem acesso às ferramentas e à própria API do serviço que queremos acessar.

É assim que o MCP funciona e é assim que vamos vê-lo funcionando. Essas camadas conversam entre si, com chamadas de entrada e saída (input e output). O cliente MCP e o LLM Host já estão no Claude, e vamos precisar procurar quais servidores MCP queremos conectar e verificar se as ferramentas que queremos conectar têm um serviço desse tipo, porque pode ser que ele ainda não exista ou não esteja implementado.

Resumindo o papel do servidor MCP

Temos uma tabela que descreve para que serve o MCP, um resumo do que vimos. A ideia é que o MCP dê acesso a ferramentas para os agentes executarem ações no nosso serviço, no nosso servidor. Ele faz a integração de APIs, bancos de dados e arquivos junto com o agente. Um agente consegue pedir informações que estão no banco de dados do nosso sistema, chamar as APIs para executar ações ou pedir arquivos, no caso do Google Drive, por exemplo.

O papel do servidor é essa mão de obra. Como falamos, o nosso agente está limitado, por enquanto, a usar só o que está dentro do nosso computador, inclusive só o que está dentro da pasta que criamos. Ao dar acesso a uma ferramenta MCP, ele passa a ter uma mão de obra fora do nosso computador que pode utilizar.

O foco é o agente atuar no mundo real. O nosso computador é fechado e seguro, com a pasta, mas é muito limitado. O nosso trabalho acontece em outros lugares, e são esses lugares que estamos chamando de mundo real.

Entendendo por que o MCP é determinístico

Uma característica interessante do protocolo MCP é que ele é determinístico. Quando o agente chama um comando no servidor MCP e pede para executar algo, se ele der a mesma entrada para aquele comando, sempre terá a mesma saída.

Isso é diferente do próprio LLM. Se pedirmos ao LLM "como vai estar o clima amanhã" ou "faça um resumo do dia", mesmo pedindo três vezes no mesmo dia, ele vai dar uma resposta diferente a cada vez, ainda que o texto inicial seja o mesmo. Ou seja, o LLM em si é não determinístico: dado o mesmo texto, ele responde coisas diferentes. Obviamente, ele responde dentro do tema perguntado, mas a resposta não é exatamente a mesma.

No MCP, quando o agente chamar uma ferramenta de criar um cartão no Trello passando sempre o mesmo comando, terá sempre a mesma resposta. Ele é mais controlado. E o escopo dele é a camada de execução: quando quisermos que o agente execute algo no mundo real, ele vai usar o servidor MCP que disponibilizarmos.

Esse é um resumo dos servidores MCP e de como podemos usá-los. Agora, vamos conectar as nossas ferramentas dentro do nosso projeto no Claude Cowork.

Sobre o curso Claude Cowork: integrações via MCP e automação de projetos

O curso Claude Cowork: integrações via MCP e automação de projetos possui 149 minutos de vídeos, em um total de 38 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:

• Ferramentas externas com MCP
• ClickUp e Google Calendar via MCP
• Documentação e regras dos projetos
• Validações automáticas com hooks
• Skills de início e fim do dia