Engenharia de software na era da IA: MCP servers, tools e integrações para agentes de IA

Entendendo o MCP - Model Context Protocol - Apresentação

Apresentando o instrutor e o curso

Olá, estudante da Alura. Meu nome é Pedro. Sou um homem branco, tenho cabelo escuro, barba escura, estou vestindo roupas de cor preta e estou em um ambiente iluminado por cores rosa e azul. Estou aqui para dar as boas-vindas a mais um curso na plataforma Alura.

Audiodescrição: Pedro é um homem branco, com cabelo e barba escuros. Ele veste roupas pretas e está em um ambiente iluminado por cores rosa e azul.

Introduzindo o curso sobre MCP

Este é um curso que muitas pessoas solicitaram, um curso extremamente necessário, que aborda o MCP. Não falaremos apenas sobre o MCP de forma geral, mas principalmente sobre servidores MCP personalizados. Vamos além do MCP, explorando como ele funciona, o que é esse protocolo, o que ele resolve e como o utilizamos. Não se trata apenas de mais um tema de IA; hoje, essa é uma habilidade essencial para personalizarmos nosso trabalho como pessoas desenvolvedoras de software que utilizam IA no dia a dia para facilitar o trabalho.

Desenvolvendo a plataforma DevReview

Neste curso, vamos desenvolver a plataforma DevReview. Com essa plataforma, começaremos entendendo como o MCP funciona, como depuramos um servidor MCP através do MCP Inspector, e como identificamos servidores MCP de qualidade e aqueles que não são tão bons.

Aprenderemos a acessar o registro, entender como ele funciona, como escolhemos o servidor MCP, como o instalamos, como o utilizamos e como fazemos a configuração dentro do editor de texto ou dentro da LLM que estivermos estudando, seja Cloud Code, Grok, Cursor, OpenAI, entre outros. Aprenderemos como realizar essa conexão e configuração de servidores MCP para utilizá-los em nosso dia a dia.

Utilizando a IA e o BaaS no projeto

A plataforma DevReview, que já desenvolvemos como um projeto 100% funcional, será um dashboard onde poderemos adicionar regras para a plataforma DevReview realizar revisões automáticas de PR, considerando regras e decisões de arquitetura. Teremos um histórico das revisões realizadas, com a média de problemas, o estado da revisão, o resumo, a data, uma URL para que possamos acompanhar essa revisão em tempo real. Não tocaremos no código front-end, sempre solicitaremos à IA, pois este não é um curso de back-end nem de front-end, mas sim um curso de IA. Estamos aqui para usar a IA como nossa aliada, aprendendo a utilizá-la para criar toda essa parte visual e estrutural para nós.

Além disso, utilizaremos o banco de dados não relacional do Superbase, portanto, não teremos um back-end neste curso da forma convencional. Utilizaremos um BaaS, que é um back-end as-a-service. Vamos juntos, pois a seguir começaremos a entender mais sobre o funcionamento do servidor MCP, para que possamos iniciar a construção do nosso próprio servidor MCP personalizado do DevReview. Vamos juntos, estudantes!

Entendendo o MCP - Model Context Protocol - Aprendendo Sobre Mcps E O Estado De Desenvolvimento Atual

Discutindo mudanças na programação e o papel dos agentes

Nos últimos meses, a forma como programamos mudou significativamente. Não precisamos voltar muitos anos para perceber essa transformação. A maneira como enxergamos a programação como um todo evoluiu bastante. Vamos discutir sobre os agentes, que são nossos agentes de código, utilizando inteligência artificial para resolver questões e interagir com nossa base de código. Além disso, abordaremos o MCP, sobre o qual já introduzimos anteriormente, explicando seu funcionamento e importância.

Entendendo o MCP

O MCP, ou Model Context Protocol (Protocolo de Contexto de Modelo), é um conceito que vamos explorar em detalhes. Vamos compreender os motivos e as novidades que o MCP traz para nosso cotidiano como pessoas programadoras. Em muitos cenários, um agente sozinho não será suficiente; precisamos conectá-lo ao mundo real. Este é o ponto de partida do nosso conteúdo.

Integração com agentes

Vamos desmembrar as primitivas e conceitos do MCP, focando na integração com agentes. A partir disso, entenderemos desde o protocolo, que é uma redução da expressão Model Context Protocol, até como ele pode ser aplicado de forma prática em nosso contexto.

Exemplificando a estandardização com carregadores de celular

Para ilustrar, pensemos em como funcionavam os carregadores de celular antigamente. Temos diferentes modelos de celulares no mercado, cada um com seu próprio padrão de carregadores. Isso gerava uma demanda complicada por estandardização. Por exemplo, se viajarmos com um iPhone que utiliza o cabo Lightning, não poderemos usar outro carregador sem um adaptador.

A chegada do USB-C

Com a chegada do USB-C, que é o padrão mais moderno atualmente, houve uma estandardização entre dispositivos. Os novos iPhones já adotam o USB-C como padrão, assim como os Androids, que há algum tempo vêm com esse padrão em vez do antigo mini USB. Essa adaptação elimina a necessidade de cabos personalizados para cada tipo de celular. Com o USB-C, podemos carregar iPhones, Androids, tablets, iPads, entre outros dispositivos, facilitando a vida dos usuários.

Concluindo com a importância da padronização

A estandardização dos carregadores é um exemplo de como a unificação de padrões pode simplificar processos e melhorar a experiência do usuário. Da mesma forma, o MCP busca trazer essa unificação e eficiência para o mundo da programação, integrando agentes de forma eficaz e prática.

Ao padronizarmos, eliminamos a necessidade de personalizações de conectores. Como aplicamos isso ao nosso cenário de MCP, que tanto mencionamos em termos de padronização? No contexto dos agents, que podemos usar como referência nessa questão de padronização, ocorre o seguinte: um agent pode precisar se conectar ao GitHub, a uma base de dados, à documentação ou às regras do projeto. Quando mencionamos agent durante este curso, referimo-nos aos agentes que operam sobre nossas LLMs (Large Language Models), ou seja, nossas IAs em execução.

Explorando o impacto do MCP na integração de agentes

O MCP é nosso protocolo de transferência de dados, transportando informações entre nosso modelo de contexto e nossa base de dados, que pode ser nosso código, a conexão com o GitHub, a documentação ou as regras do projeto. Portanto, ao falarmos do MCP, referimo-nos a um protocolo que transita essa informação, proporcionando o contexto necessário para o que faremos dentro do projeto.

Daremos alguns exemplos ao abordarmos nosso projeto Dev Review e explicaremos por que estamos construindo um MCP personalizado. O grande problema é que cada agent terá um tipo de conexão e sua maneira de operar quando executamos os agents separadamente. Esperamos que haja código personalizado para determinadas integrações e respostas distintas quando executamos agents de forma separada. Quando transferimos os agents dentro de um protocolo de transporte de informação, como o MCP, nosso protocolo de contexto, padronizamos essas conexões para que tenham o mesmo contexto dentro do nosso modelo, eliminando problemas comuns em inteligência artificial, como alucinações nas respostas que trazem informações fora de contexto.

Nosso MCP elimina o problema de N por M integrações, onde N é a quantidade de agents. Quanto mais agents ou modelos tivermos em execução, maior será o número de ferramentas com as quais esses agents e modelos interagirão. Cada agent terá suas ferramentas, assim como, nos modelos antigos de celulares e carregadores, havia personalizações internas. No entanto, ao utilizarmos a padronização — no caso dos celulares, o USB-C, e para nossos agents, nossa camada do MCP — eliminamos problemas de ruído e duplicação de ferramentas. Em vez de escalar o número de ferramentas pelo número de agents, teremos uma redução significativa.

Detalhando a eficiência do MCP na redução de complexidade

Ao aprofundarmos no código e na configuração, veremos que o número de ferramentas realmente necessárias durante nossas integrações será muito menor do que seria se utilizássemos um agent puro, sem informações ou inclusão no MCP. Eliminamos a magnitude que era de ordem produto, ou seja, multiplicação do número de ferramentas pelo número de agents. Passamos a ter o número de agents, que é nosso M, multiplicado por M, que será a quantidade de ferramentas dentro de cada modelo. Apenas ao eliminar uma quantidade gigantesca de ferramentas durante essa integração, já economizamos em tokens, e quando falamos de tokens, falamos de dinheiro, pois hoje não é apenas tempo, é dinheiro.

Com nosso protocolo MCP, que atua como um protocolo de trânsito de informação, temos nosso padrão para conectar modelos ou agents com nossas ferramentas, dados e contextos. Isso significa que, à medida que nossos agents aumentam em complexidade e contextos, o número de ferramentas não mudará. Dada a integração, o MCP e tudo que fazemos dentro do nosso código, eliminamos a possibilidade de surgirem muitos códigos personalizados e remendos para fazer funcionar como os agents vão interagir com ferramentas externas de forma mais organizada. A integração tende a se tornar mais reutilizável, pois reduzimos a personalização, permitindo reutilizar mais nossas conexões. Com isso, o desenvolvimento se torna mais fácil de entender, e o sistema ganha mais consistência.

Entendendo o MCP - Model Context Protocol - Conhecendo As Primitivas Dos Mcps

Compreendendo o funcionamento do MCP

Para compreendermos como funciona na prática, precisamos entender mais sobre o funcionamento subjacente do MCP e o que ele nos oferece em termos de resolução para nosso problema de código personalizado e reutilização de ferramentas. Precisamos entender quais são as primitivas com as quais nosso protocolo, o MCP, opera para compreender essa arquitetura subjacente e o que ele resolverá para nós.

As primitivas do MCP se baseiam em três pontos principais: ferramentas, recursos e prompts, que farão com que nosso MCP funcione da maneira que precisamos. As ferramentas serão qualquer tipo de ação que nosso agente tome. Basicamente, quando interagimos com o agente, ou seja, quando passamos informações para ele, qualquer ação que ele execute, seja analisar o código, devolver uma resposta ou até mesmo formular uma pergunta em forma de prompt para que possamos respondê-la, são as ações. Vamos visualizar essas ações funcionando, independentemente do local onde estamos executando nosso modelo, e elas virão com um padrão de funcionamento em snake_case. Por exemplo, temos um get_team_rules, que será o nome da ação que nosso agente tomará para verificar as regras de um time, por exemplo, para usar essa informação, montar um contexto e utilizá-la para qualquer propósito pelo qual estamos fazendo essa consulta.

Explorando recursos e eficiência no MCP

Nosso segundo ponto, que são nossos recursos, são os dados estáticos que preenchem a informação de nosso protocolo, do nosso MCP. Quando definimos algumas diretrizes, regras ou documentações sobre as quais o MCP se baseará, estamos falando de resources, que são precisamente recursos. Se traduzirmos a palavra resources para o português, estamos falando de recursos. Todos os recursos que são os dados estáticos que o MCP consulta, chamamos de resources. Essa é uma das primitivas de funcionamento do nosso MCP. Para que servem os resources? Não poderíamos ter apenas as ferramentas buscando em locais remotos, na web ou em uma documentação oficial? Sim, as ferramentas desempenharão esse papel, mas o resource aqui se refere a um alto nível de eficiência da ferramenta. Quando começamos a ter dados estáticos dentro da configuração do nosso MCP, garantimos que, mesmo buscando informações via web ou qualquer protocolo de comunicação, nosso MCP assegurará, a partir desses resources, que certos padrões de qualidade sejam mantidos e filtrará melhor a informação, pois estaremos dando comandos claros sobre como queremos que ele se comporte, como queremos que o MCP devolva determinado dado e como filtra essa informação. Estamos falando de um refinamento no funcionamento, que é precisamente o pilar que trará eficiência ao nosso MCP.

Utilizando prompts para segurança e eficiência

Por último, mas não menos importante, muitos de nós usamos prompts praticamente o dia todo para nos comunicarmos com as LLMs, com nossos modelos e agentes. São as templates normalmente reutilizáveis que teremos para nosso MCP, onde essas templates eliminarão problemas de segurança que veremos ao final, mas deixamos aqui essa introdução para entender melhor o funcionamento dessas três primitivas. Basicamente, os prompts funcionam como facilitadores para a segurança do nosso MCP, para assegurar ainda mais a qualidade da informação e justamente para evitar ter que escrever certas informações novamente. Quando unimos esses três pilares e escolhemos a forma correta de usar essas primitivas, estamos falando de eficiência. E, novamente, repetiremos bastante que token é dinheiro. Quando nossa eficiência, ou seja, a resposta por número de tokens, é eficiente — ou seja, obtemos uma boa resposta com um baixo número de tokens gastos, tanto na comunicação quanto na busca e na resposta — estamos falando de economia, seja para sua empresa, seja para você, ou para quem estiver assumindo os custos, pois, infelizmente, tudo que é bom tem um custo. E para usar ferramentas de ponta e obter respostas de ponta, estamos investindo nosso tempo e nossos tokens para obter essas respostas dentro do MCP.

Explorando ferramentas e documentação do MCP

Primeiramente, para verificar a informação de um MCP, temos as documentações e, em seguida, acessamos o site do Registro Oficial do MCP para entender como buscar um bom MCP e por que utilizá-lo. Além da documentação, outra forma de entender como o MCP funciona e como usar essa informação é através do MCP Inspector, uma ferramenta semelhante ao Postman.

Se nunca utilizamos o Postman, ele é basicamente uma ferramenta para fazer conexões via uma API, onde há documentação dos endpoints, as respostas dos endpoints e os parâmetros que utilizam. O MCP Inspector funciona de maneira muito parecida com o Postman, mas será executado internamente em nossa aplicação, como uma consulta interna a nível de aplicação. A partir do MCP Inspector, podemos ver e chamar as ferramentas, analisar as respostas e inspecionar erros. Para isso, utilizaremos a biblioteca Zod para validar erros e apresentá-los de forma amigável, tanto para nós, como pessoas desenvolvedoras, quanto para o agente que estará utilizando o MCP.

Implementando conexões e validações no MCP

Não precisamos de um host completo, pois utilizaremos a forma de conexão STDIO. Essa forma de conexão é suficiente, pois não precisamos de um formato HTTP para fazer uma chamada. Com o MCP Inspector, podemos executá-lo localmente e usar STDIO para essa conexão. Quem se lembra das aulas de algoritmos dos anos 2000, quando começamos no mundo do desenvolvimento, usávamos STDIO em C++ para interagir com o teclado, solicitando informações e aguardando entradas e saídas por terminal. STDIO é justamente essa conexão local, interagindo e aguardando entradas para produzir saídas.

Existem outras formas de conexão que, para o MCP Inspector, não farão diferença, pois usaremos um host mínimo, que chamaremos de uma "template mínima" para nosso MCP Server. Usaremos o Inspector porque investiremos tempo em configurá-lo e entender seu funcionamento. Será nosso primeiro contato com o MCP Server, que é a camada de configuração do funcionamento do nosso MCP, do nosso protocolo de comunicação de contexto para os modelos.

Configurando o MCP Client e Server

Outra forma é o nosso MCP Client, onde fazemos as configurações a partir de uma interface mais amigável, com informações de forma mais visual. Isso é o que representa o Dev Reveal, nosso projeto, a parte frontend que representa um dashboard. Veremos isso a seguir, para fazer as configurações para nosso MCP Server.

Uma informação importante é que nosso agente será executado sobre o MCP Server. Quando fizermos alguma consulta a nível de agente, enquanto a LLM estiver em execução, o modelo usará o MCP Server para chamar as ferramentas, entregar a resposta, usar o prompt e os resources, que são nossos dados estáticos. O MCP Client se refere às configurações que faremos. Neste caso, usamos um projeto frontend para ilustrar melhor o dashboard e como faremos essa conexão.

Testando e validando ferramentas do MCP

Além de o Inspector ser nosso primeiro contato com o MCP Server e ter uma interface de cliente, podemos testar de forma isolada nossas ferramentas antes de uma integração real. Validamos usando dados simulados, sem necessidade de uma conexão real com a base de dados. Através do nosso host mínimo, com a conexão STDIO, validamos com dados locais, permitindo um debug rápido. Se tivéssemos que fazer uma conexão com um servidor remoto, seria mais complexo e custoso, pois, ao rodar localmente, não há custo de tokens para consultas, já que usamos um host mínimo com informações simuladas.

Na última etapa, ao fazer uma conexão real e testar uma revisão de PR, que será nosso objeto de estudo, teremos gastos de tokens para consultas. Portanto, neste primeiro momento, para depurar e entender, não faz sentido gastar tokens. Podemos fazer isso de forma gratuita, aproveitando nosso host local para integrações.

Sobre o curso Engenharia de software na era da IA: MCP servers, tools e integrações para agentes de IA

O curso Engenharia de software na era da IA: MCP servers, tools e integrações para agentes de IA possui 408 minutos de vídeos, em um total de 60 atividades. Gostou? Conheça nossos outros cursos de IA para Programação 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:

• Entendendo o MCP - Model Context Protocol
• Utilizando MCPs prontos
• Implementando design de Tools
• Construindo o MCP Server Customizado
• Nova aula
• Integrando múltiplos MCPs
• Segurança em MCP