MCP Server com TypeScript: adaptando sistemas para agentes autônomos

O Protocolo MCP - Apresentação

Apresentando o curso e objetivos gerais

Bem-vindas e bem-vindos a mais este curso na Alura. Eu sou o Ricardo Bugan e serei o instrutor neste curso.

Neste curso, vamos criar uma nova interface de usuário para a Emacs Locadora. Este projeto já aparece em alguns cursos da Alura, e, desta vez, vamos criar uma interface de usuário, mas não como camada de apresentação nem como aplicativo para dispositivos móveis. Vamos desenvolver uma interface de usuário para nossos agentes.

Testando a interface e realizando reservas

Após criarmos a interface, começamos a testá-la com o agente e agora temos um MCP para realizar reservas. O agente efetuou uma reserva para nós de um Onix. Em nossas reservas, consta um Onix LTZ 1.0, com a reserva efetuada.

Decidimos alterar a solicitação: não queremos um Onix; queremos um GPIO N-Gage. Já deixamos a instrução (prompt) preparada: “Cancele a reserva do Onix, informando o ID da reserva, e efetue uma reserva de um GPIO N-Gage.” O agente executará essa solicitação e organizará as reservas.

Acompanhando atualizações e explorando o protocolo mcp

Na nossa interface do front-end, devemos ver a atualização em tempo real conforme o agente executa as ações. Agora, o Renegade já está no lugar onde estava o ONIX. Nosso agente executou as duas operações: cancelou nossa reserva do ONIX e criou nossa reserva do Renegade. Tudo isso utilizando uma ferramenta do MCP que nós criamos.

Em nossos MCPs, temos o MCP da Hermex com as ferramentas disponíveis: GetCarrosDisponíveis, GetLocalizações, GetSeguros, CreateReserva e CancelReserva. Essas ferramentas permitem ao agente interagir com a nossa Hermex locadora.

É isso que vamos criar neste curso e é isso que vamos entender: como funciona o protocolo MCP, para que ele serve — a Clara já apresentou uma boa ideia de seu propósito —, quais detalhes devemos considerar, como lidar com ele e quais esquemas precisaremos criar. Tudo isso para desenvolver uma nova interface de usuário para o nosso produto.

O Protocolo MCP - Contexto de ferramentas MCP

Apresentando o curso e a importância do tema

Para começar o curso, vamos entender o que vamos abordar e a importância do tema que estamos trazendo.

Se você clicou neste curso, atua no mundo de desenvolvimento, na área de produto ou simplesmente acompanha o cenário atual, provavelmente já está usando, já usou ou já foi solicitado na sua empresa a utilizar alguma inteligência artificial. Isso ocorre porque, cada vez mais, as empresas pedem que nós, enquanto pessoas que trabalham nessas organizações em diversas áreas, utilizemos IAs para realizar várias tarefas, com a promessa de aumentar a eficiência e a produtividade no nosso dia a dia.

Personalizando assistentes e integrando ferramentas

Ao utilizarmos essas IAs, costumamos personalizar o nosso assistente com ferramentas que usamos diariamente. Estamos com o Claude aberto, mas nosso trabalho não se limita ao assistente. Muitos desses assistentes operam em pastas na nossa máquina. Assim, temos a possibilidade de personalizar esse assistente. Na parte de conectores, há uma série de ferramentas às quais concedemos acesso para que o assistente possa agir em nosso lugar nessas ferramentas.

Temos, por exemplo, o n8n, o Notion, o Figma, muito conhecido por quem trabalha com front-end (camada de interface), o Supabase, útil para a área de produto criar back-end (camada de servidor) de forma rápida, ou até para quem desenvolve e não quer se preocupar com back-end (camada de servidor), o Postman, para quando estamos desenvolvendo nosso back-end (camada de servidor), o Miro, o Bright Data, o ClickUp, o Gmail, entre várias outras ferramentas que podemos utilizar.

Todas essas ferramentas funcionam como uma interface do nosso agente com a própria ferramenta, permitindo que ele altere o estado das informações nelas.

Explicando servidores do protocolo e categorias de ferramentas

Talvez já tenhamos nos perguntado: como o assistente faz isso? Ele faz isso por meio de servidores MCP, utilizando um protocolo criado especificamente para a interface entre o assistente e nossas ferramentas.

Quando entramos no Figma, por exemplo, encontramos o Figma MCP. Ele possui um servidor MCP que ajuda a obter contexto do Figma e nos fornece ferramentas. Essas ferramentas estão organizadas em categorias:

• Ferramentas interativas
• Ferramentas de somente leitura
• Ferramentas de gravação
• Ferramentas de exclusão

Contextualizando o ecossistema e delineando os objetivos do curso

A proposta deste curso é explorar esse protocolo no navegador, acessando a página oficial modelcontextprotocol.io, onde encontramos a documentação da especificação do protocolo. Vamos pensar em como implementar para que você tenha um serviço próprio que rode com o assistente, avaliando como usar esse protocolo para oferecer uma interface mais simples para um assistente em nosso produto personalizado.

Se refletirmos sobre o ecossistema atual, o Supabase já existia antes dos agentes; já era amplamente utilizado. O Lovable, por sua vez, não existia antes; surgiu junto com os MCPs e com os avanços em IA e, recentemente, criou seu próprio MCP. Assim, é possível alterar as configurações do Lovable por meio de qualquer assistente que você preferir, sem depender necessariamente do modelo que ele fornece.

O Figma é outro software que já existia antes da IA, mas que passou a oferecer acesso via MCP para que a IA possa buscar contexto e apoiar o desenvolvimento, com foco principalmente em front-end (interface). Com isso, conseguimos obter contexto, acessar os assets (recursos), acessar as variáveis do nosso design e programar de maneira muito mais simples.

Provocando reflexão e iniciando a criação do servidor

Qual é o seu produto? E como uma IA, um assistente, pode usar o seu produto para facilitar a vida da sua pessoa cliente?

A partir disso, vamos entender como usar esse protocolo para desenvolver um servidor próprio, personalizado para nosso produto, e que você pode fornecer para suas pessoas clientes.

É aqui que vamos começar o curso: vamos discutir esse protocolo e, em seguida, criar nosso servidor.

[♪ Música de encerramento ♪]

O Protocolo MCP - Como funciona o MCP?

Contextualizando o MCP e sua motivação

Agora que falamos sobre por que adotar o MCP e quais são suas vantagens, exploramos possibilidades e vimos ferramentas como Figma, Breach Data, Lovable e outras. Vamos entender como funciona o nosso protocolo MCP, identificando os detalhes em nível mais alto para observar seu funcionamento na prática.

A ideia do MCP parte da base com os LLMs (Modelos de Linguagem de Grande Escala). Os LLMs foram a primeira parte da infraestrutura criada para os agentes, antes mesmo de existirem agentes de área; inicialmente, basicamente só havia o chat, o ChatGPT. Em seguida, introduzimos a camada de Harness (camada de controle), um “guia” que controla como a requisição chega ao LLM e como as respostas são enviadas. A partir dela, surgiram as aplicações que temos hoje, como Cloud Code, Watch Gravity, Codex e outras.

Relacionando os agentes ao ecossistema de serviços

Temos, então, a camada de agentes, com regras e skills (competências), para organizar como esses LLMs trabalham dentro do nosso projeto. Porém, precisamos da camada MCP para dar acesso ao mundo real e permitir que tarefas sejam executadas em nosso lugar. Esse é o objetivo central.

Do outro lado, muitas vezes já trabalhamos em uma empresa que tem um produto ou serviço: há um site, uma API, e queremos oferecer um serviço que, além de atender o front-end (camada de interface) na aplicação web, a aplicação mobile (móvel) e o sistema de back-office (retaguarda administrativa) para configurações do serviço, também atenda agentes dentro desse ecossistema. Ou seja, o serviço e o produto já existem, mas queremos que os agentes sejam capazes de acessá-los diretamente, sem depender de intermediações manuais via APIs nem de skills que descrevam rotas REST e sua orquestração.

Analisando limitações do REST para descoberta e semântica

Como atendemos nossos agentes da melhor maneira? Poderíamos expor tudo via REST, mas não é o que buscamos aqui. REST é um estilo com protocolo e padrões de projeto por trás, com convenções de organização. No entanto, há um ponto central que falta muito em REST: a descoberta de rotas. Sempre que há uma API REST em funcionamento, é necessário saber previamente quais rotas existem e como foram nomeadas. Apesar de convenções mais difundidas, as empresas variam a nomenclatura e a organização desses padrões. Essas pequenas variações impedem uma descoberta padronizada de rotas.

Para os agentes, há ainda a falta de descrição explícita da funcionalidade. Tomando o exemplo que usaremos no curso, “Max Locadora de Veículos”, ainda que saibamos que existe uma rota “Veículos” e que possamos realizar operações como GET, PUT, POST e PATCH nessa rota, continuamos sem clareza sobre ações específicas. Em REST, podemos seguir um padrão geral, mas sempre existem particularidades que não ficam auto-organizadas nem facilmente descobertas.

Se quisermos alugar um veículo, por exemplo, poderíamos ter uma rota REST como Veículos/ID/locacao, representando uma ação aplicada a um veículo específico. Essa ação não fica automaticamente evidente apenas pela existência de uma rota “Veículos” com métodos genéricos; ela exige uma rota e uma semântica específicas, o que reforça a necessidade de uma camada como o MCP para descrever capacidades, permitir descoberta e expor funcionalidades de forma clara aos agentes dentro do nosso ecossistema.

Evidenciando impactos de implementação e manutenção de skills

Essa rota pode até existir, mas em que medida nosso assistente conseguirá alcançá-la e saber quando utilizá-la? Esse é o problema que temos com o REST: a descoberta de rotas não é eficiente, e não dispomos de uma forma simples para o assistente, nosso LLM, saber quando usar cada rota. Tudo isso ocorre por causa de implementações personalizadas para cada serviço.

Do lado das empresas, se temos vários serviços que queremos utilizar com nosso agente, precisaremos criar skills (habilidades) para todos eles. Se quisermos usar o Figma, teremos de criar uma habilidade de como utilizar a API do Figma. Se quisermos usar o GitHub, teremos de criar uma habilidade de como utilizar a API do GitHub. Se a API mudar, a habilidade precisa mudar junto. Isso torna a manutenção mais difícil.

Detalhando a arquitetura cliente-servidor do MCP

A solução é a criação de um servidor MCP, uma plataforma que atenda diretamente esses agentes. Esse protocolo possui algumas partes. Começamos com nosso LLM, o modelo de linguagem, conectado a um MCP Client. Para nós, durante o curso, podemos considerar que será o Harnett, o Claude Code, o Antigravity, o Codex, o Cursor e assim por diante. Nosso MCP Client já está desenvolvido e embutido nessas ferramentas. Inclusive, quando estávamos com o Claude aberto, ele já permite conectar a diversos MCPs. Portanto, não precisamos nos preocupar com o cliente.

Do outro lado, esse cliente precisará se comunicar com nosso servidor. Esse servidor deve disponibilizar ferramentas para nosso LLM acessar nossa API. Assim, do lado do cliente, o cliente dialoga com nosso LLM; do lado do servidor, o servidor registra as ferramentas que podemos usar. Toda essa comunicação ocorre por meio do protocolo JSON-RPC. Toda a entrada e saída de informações — isto é, input (entrada) e output (saída) — entre o servidor e o cliente, bem como a forma como isso chega ao host (máquina hospedeira) e se cadastra nas ferramentas, baseia-se nesse protocolo de comunicação, o JSON-RPC. Precisamos tomar cuidado, pois esse formato de comunicação estará em execução em segundo plano, por trás do que estivermos fazendo.

Há ainda uma camada de comunicação web (rede), porque o cliente pode estar em qualquer lugar do mundo e o servidor estará hospedado em algum provedor, como Azure ou AWS. Para que a comunicação entre o computador do cliente e o servidor funcione, há a camada de internet no meio. Sobre essa camada de internet, teremos o protocolo de comunicação JSON-RPC. Precisamos observar esse ponto com atenção, e o veremos em mais detalhes.

Nosso objetivo é fornecer ao agente ferramentas preparadas e prontas para que saiba quando e como utilizar cada uma delas, integrando com nossos serviços e com nossa API, possibilitando que ele realize o trabalho necessário em nosso lugar. É por isso que vamos criar um MCP; é onde queremos chegar. Usaremos a AMX Locadora de Veículos como exemplo para seguirmos este projeto.

Sobre o curso MCP Server com TypeScript: adaptando sistemas para agentes autônomos

O curso MCP Server com TypeScript: adaptando sistemas para agentes autônomos possui 129 minutos de vídeos, em um total de 43 atividades. Gostou? Conheça nossos outros cursos de Engenharia de LLMs & Agentes 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:

• O Protocolo MCP
• Servidor MCP e ferramentas
• Integração com a API
• Manipulação de dados
• Experiência do usuário