MCP explicado: como o Model Context Protocol funciona

LLMs já conseguem chamar ferramentas há algum tempo, mas o Model Context Protocol (MCP) oferece uma forma estruturada e padronizada de fazer isso.

Ainda assim, há confusão sobre o que o MCP realmente é.

Muitas pessoas presumem que o MCP é um app, uma API ou alguma ferramenta, mas ele não é nada disso. Ele é um protocolo, e isso significa algo bem específico.

Vamos detalhar.

Se você só quer ver o que o MCP viabiliza na prática, assista a este vídeo curto:

O que é um protocolo?

Um protocolo é simplesmente um conjunto de regras que define como dois ou mais sistemas se comunicam entre si.

Ele não faz nada por si só. Ele apenas define a estrutura e as expectativas de uma conversa entre duas entidades. Pense nele como uma linguagem compartilhada com regras gramaticais estritas que computadores seguem para trocar informações.

Sistemas postais fazem algo semelhante. Todos os correios de um determinado país seguem um formato de endereço padronizado para enviar cartas.

Ou pense nele como USB-C para ferramentas de IA. Vinte anos atrás, o mercado estava cheio de diferentes tipos de cabos de carregamento e dados. Da mesma forma, ecossistemas de IA tiveram várias formas de passar ferramentas para modelos de linguagem. Frameworks como LangChain, Haystack e Pydantic AI definiram seus próprios formatos para integrar ferramentas, o que significa que, se um desenvolvedor quisesse escrever um conjunto de ferramentas para Google Maps, teria que fazer isso para cada tecnologia específica.

Para tornar isso mais concreto, vamos analisar o protocolo mais popular, HTTP (Hypertext Transfer Protocol), que sustenta sites. O HTTP define, entre outras coisas, como um navegador (cliente) solicita uma página web a um servidor web e como o servidor deve responder.

Aqui está um exemplo de um ciclo de requisição-resposta HTTP:

O navegador faz uma requisição HTTP

Quando você digita https://example.com no navegador, ele envia uma requisição HTTP estruturada ao servidor web:

Aqui estão os parâmetros e valores HTTP usados no nosso exemplo:

"GET" – Esta é a ação (solicitar uma página web).
"/index.html" – A página web específica que está sendo solicitada.
"HTTP/1.1" – A versão do protocolo que está sendo usada.
"Host: example.com" – O nome de domínio do site.
"User-Agent: Mozilla/5.0" – Informações sobre o navegador que faz a requisição.

O servidor web sabe como interpretar essa requisição porque o HTTP padroniza esse formato. Ele entende essa “linguagem”.

O servidor responde usando o protocolo HTTP

O servidor processa a requisição e envia de volta uma resposta HTTP estruturada:

"HTTP/1.1 200 OK" – O código de resposta (200 significa sucesso).
"Content-Type: text/html" – O tipo de conteúdo enviado de volta.
"Content-Length: 512" – O tamanho da resposta.
Conteúdo HTML – O conteúdo real da página web (há apenas um título "Welcome to Example.com")

Importante: o HTTP em si não armazena páginas web nem as exibe. Ele apenas define as regras de como navegadores web e servidores web podem se comunicar. Qualquer sistema que siga essas regras pode se comunicar pela Internet definida pelo HTTP.

Como o MCP funciona como protocolo

Agora, vamos aplicar o mesmo raciocínio ao MCP (Model Context Protocol).

MCP é um protocolo para agentes de IA conversarem com ferramentas externas e fontes de dados. Assim como o HTTP, ele não armazena dados nem executa tarefas por si só. Ele simplesmente define uma forma padronizada para a IA solicitar e recuperar informações de ferramentas.

Você pode se perguntar: o que são essas “ferramentas”?

No contexto de LLMs, ferramentas são sistemas externos, APIs ou serviços com os quais a IA pode interagir para estender suas capacidades além da geração de texto. Elas permitem que agentes de IA busquem dados em tempo real, agendem compromissos ou enviem mensagens para seus amigos, tornando-os muito mais úteis para necessidades do mundo real.

Digamos que você pergunte a um agente de IA:

“Que horas são em Londres agora?”

Como a IA em si não sabe a resposta correta, pois modelos de IA têm uma data de corte de conhecimento (outubro de 2023 para os modelos da OpenAI), ela precisa buscar dados ao vivo em um serviço de horário. Mas, em vez de usar HTTP para solicitar uma página web, a IA usa MCP para solicitar dados de horário.

Veja o que acontece:

O agente de IA faz uma requisição MCP ao serviço de horário (exemplo)

"method": "tools.call" → A IA está chamando uma ferramenta externa.
"tool": "get_time" → O nome da ferramenta que ela quer usar.
"args": { "location": "London" } → Os parâmetros de entrada específicos.

Assim como no HTTP, essa requisição segue um formato estrito para que qualquer ferramenta compatível com MCP saiba exatamente como interpretá-la.

O servidor de horário MCP responde

A ferramenta externa (servidor de horário) segue as regras de resposta do MCP e envia de volta:

"status": "success" → Confirma que a requisição foi processada corretamente.
"result" → Contém os dados reais de horário.

Agora, o agente de IA pode pegar esses dados e compor uma resposta real ao usuário com:

“A hora atual em Londres é 12:20 PM (GMT).”

Para resumir e esclarecer a confusão:

“MCP é um app.” → Não, MCP é um conjunto de regras. Você precisa de software de IA e ferramentas que implementem MCP para realmente usá-lo, assim como o app do Instagram precisa de servidores ativos do Instagram para responder a requisições HTTP e entregar dados.

“MCP é um banco de dados.” → Não, MCP não armazena dados. Ele ajuda agentes de IA a conversar com bancos de dados ou APIs.

“MCP é como uma API.” → Não exatamente. Uma API é uma forma específica de interagir com um sistema, enquanto um protocolo (como MCP ou HTTP) define uma forma universal pela qual muitos sistemas diferentes podem se comunicar. MCP é uma linguagem que um sistema de IA pode usar para interagir com muitas APIs reais (horário, bancos de dados, Stripe, Slack etc.).

Tabela de comparação MCP vs protocolo

Por que o MCP é interessante

Agora que sabemos que o MCP é uma forma padronizada de software de IA interagir com ferramentas e apps externos, e que MCP não é uma API, vamos entender por que a comunidade de desenvolvedores de IA (incluindo nós) se interessou por ele.

Como o MCP não é uma API, mas permite que apps de IA interajam com APIs reais em escala, ele ajuda projetos que exigem conexão com muitos sistemas externos a sair do papel mais rapidamente. Ferramentas também dão alcance a um modelo, e o que aconteceu no incidente OpenAI Hugging Face mostra como esse alcance se parece quando excede a tarefa. Para fazer isso, desenvolvedores às vezes precisariam passar por um ciclo completo de desenvolvimento de integração de API, mas hoje geralmente usam bibliotecas existentes ou projetos open-source (por exemplo, disponíveis no GitHub) que fornecem a funcionalidade necessária.

Usar essas bibliotecas acelera o início do desenvolvimento, mas integrá-las corretamente ao seu sistema (se ele não for compatível com a implementação que você encontrou no GitHub) ainda exige esforço para fazer a ferramenta funcionar com a IA.

Com MCP, uma vez que o framework esteja em funcionamento, adicionar uma nova integração (por exemplo, integrar Google Drive) pode ser uma questão de conectar-se ao servidor MCP do Google Drive com algumas linhas de código. Você não encontrará problemas de compatibilidade porque ambos usam o mesmo protocolo: MCP.

Vamos comparar as duas abordagens para ver as diferenças com mais clareza.

Integração padrão vs. uso do Model Context Protocol (MCP)

Para tornar esta comparação concreta, vamos percorrer a adição de acesso a arquivos do Google Drive a um AI Agent, primeiro manualmente e depois com uma ferramenta compatível com MCP.

Integração padrão

Encontrar e adaptar uma biblioteca: você procura um cliente da API do Google Drive ou um projeto open-source. O Google fornece bibliotecas cliente (por exemplo, Google Drive API para Python). Você inclui isso no seu projeto. Ainda precisa garantir que funcione no ambiente da sua IA.
Implementar a lógica: você escreve funções para, por exemplo, pesquisar arquivos ou buscar um documento no Drive. Quando a IA precisa de algo, ela deve chamar essas funções. Você formata a requisição da IA em chamadas específicas da API do Google Drive. Depois de obter uma resposta do Google, você extrai o conteúdo para devolvê-lo ao contexto da IA.
Tratar erros e casos de borda: adicione código para lidar com casos como “arquivo não encontrado”, erros de permissão ou limites de taxa da API. Se a API do Google retornar um erro, você o captura e talvez responda com uma mensagem de desculpas ou peça à IA que reformule. Você também precisa impedir que sua IA envie requisições demais muito rapidamente.
Manter: ao longo do tempo, se o Google atualizar a API ou a biblioteca, você deverá atualizar seu código. Se encontrar um bug na biblioteca, talvez precise corrigi-lo ou encontrar outra fonte. Na prática, você se torna o mantenedor dessa integração com Google Drive dentro da sua aplicação de IA.

Esse processo se estende a outras ferramentas: quer adicionar Slack ou um banco de dados à sua IA? Você precisa repetir todo o processo para cada uma.

Integração MCP

Agora vamos ver como esse processo ficaria ao usar MCP.

Primeiro, vamos definir conceitos-chave:

Cliente – uma aplicação de IA (ChatGPT, app Claude, Quickchat AI) que estabelece uma conexão com um ou mais servidores e solicita informações ou ações para executar tarefas solicitadas por um usuário.

Servidor – cada servidor pode se conectar a algo como um banco de dados, uma API (Google Drive) e definir um conjunto de “ferramentas” ou dados que ele pode fornecer. Neste caso, o servidor é um programa que expõe essas ferramentas e capacidades ao Cliente (app de IA).

Desenvolvedores, dependendo do que querem fazer, podem escolher qualquer um dos lados: criar um servidor para expor dados ou criar um cliente de IA que consiga conversar com qualquer servidor. A maioria quer a segunda opção, mas ainda assim vamos começar pelo lado do servidor para entender como o MCP funciona passo a passo:

Inicializar um servidor MCP. Um desenvolvedor ou administrador de sistemas configura um servidor MCP para uma determinada ferramenta ou fonte de dados. Um servidor MCP geralmente é apenas um pequeno programa que implementa a especificação MCP. Por exemplo, há um servidor Google Drive MCP pré-construído disponível que sabe pesquisar e buscar documentos.

Ao inicializar o servidor, você dá a ele acesso ao sistema de destino (Google Drive). O servidor então expõe um conjunto de ferramentas correspondentes a ações ou consultas que ele consegue tratar. Ele é essencialmente um adaptador de API que fala MCP de um lado e o serviço nativo do outro.

Quando o servidor está em execução, ele aguarda requisições.
Conectar um LLM (cliente) a um servidor MCP. Em seguida, a aplicação de IA (o lado “cliente”) precisa se conectar a esse servidor. Na prática, se você estiver usando uma plataforma de IA compatível com MCP (como Claude Desktop), você a configuraria com o endereço ou comando para iniciar o servidor. Depois de conectado, o cliente estabelece uma sessão com o servidor seguindo o handshake do MCP. Se você estiver usando a interface do Claude, verá que o Claude está “conectado” a determinados servidores MCP (a UI pode indicar conectores disponíveis).

Claude com ferramentas adicionadas

É assim que aparece na UI do Claude

Descobrir ferramentas disponíveis. Com a conexão estabelecida, a primeira coisa a fazer é descobrir o que o servidor oferece (às vezes, isso acontece automaticamente depois que você se conecta ao servidor). O cliente MCP envia uma requisição tools/list ao servidor (isso é definido no protocolo). O servidor responde com uma lista de suas ferramentas disponíveis, cada uma com detalhes como nome, descrição e esquema de entrada.

Por exemplo, um servidor pode responder que tem as ferramentas create_file(path, content), read_file(path) e search_files(query) disponíveis. O cliente então disponibiliza essas informações ao LLM. Em muitas implementações, o cliente formatará essas descrições de ferramentas e as incluirá no contexto do modelo (por exemplo, adicionando ao prompt do sistema: “Você tem acesso às seguintes ferramentas… [lista de ferramentas]”).

Prompt do sistema

Aqui está um prompt do sistema de IA junto com a mensagem do usuário solicitando a hora atual

Ferramenta MCP no prompt

Com ferramentas MCP implementadas, uma ferramenta chamada “get_current_time” é integrada, permitindo que a IA acesse um recurso externo e busque a hora exata em Londres

Isso significa que você não precisa prever e programar antecipadamente todas as ações potenciais que seu app de IA pode precisar para concluir alguma tarefa. Com MCP, a IA pode descobrir todas as ações possíveis em tempo real perguntando a um servidor MCP e escolher o que for necessário.

Usar uma ferramenta por meio do MCP. Quando a IA precisa executar uma ação ou buscar dados, ela invoca uma ferramenta via MCP. Da perspectiva da IA (especialmente para modelos como Claude, que oferecem suporte nativo ao uso de ferramentas), ela decidirá em seu raciocínio: “Devo chamar a ferramenta X com estes parâmetros.” O cliente MCP captura essa intenção e envia uma requisição tools/call no formato MCP ao servidor apropriado (servidor MCP do Google Drive).
O servidor MCP atua como uma ponte. Ele recebe uma requisição estruturada e compatível com MCP do agente de IA, mapeia essa requisição para o endpoint correto da API do Google Drive, reescreve a requisição como uma chamada real à API do Google Drive, executa a requisição, processa a resposta e a reformata novamente como uma resposta compatível com MCP antes de enviá-la de volta ao agente de IA.

Vale observar que servidores MCP seguem uma abordagem estruturada para tratar erros, garantindo que AI Agents possam interpretá-los e agir sobre eles de forma eficaz.

Digamos que um AI Agent esteja usando uma ferramenta MCP para encontrar um arquivo no Google Drive. Se a requisição incluir um ID de arquivo inválido (por exemplo, uma string de cinco caracteres em vez do formato esperado), o servidor MCP retornará uma mensagem de erro:

Em vez de simplesmente falhar, o AI Agent pode pegar essa resposta estruturada e reformulá-la como um feedback amigável ao usuário:

“Parece que o ID de arquivo que você forneceu é curto demais. IDs de arquivos do Google Drive normalmente têm 28 caracteres. Você poderia conferir e tentar novamente?”

Essa abordagem garante que erros não levem a becos sem saída e, em vez disso, se tornem oportunidades para o AI Agent orientar o usuário rumo a uma resolução bem-sucedida.
Responder à pergunta/solicitação do usuário. Depois que o servidor MCP retorna um resultado, o cliente MCP entrega esses dados de volta ao app de IA. O modelo então incorpora o resultado ao seu raciocínio ou diretamente à saída que gera para o usuário.

Se o usuário solicitar a criação de um novo arquivo do Google Sheets, a resposta do servidor (contendo o ID do arquivo e um link gerado) será enviada ao modelo. O modelo então responderá ao usuário com: “Boa notícia! Seu novo arquivo do Google Sheets está pronto. Você pode acessá-lo aqui: [link].”

Fluxo de como o MCP funciona

Durante todo esse processo, a IA permanece no controle do fluxo: ela decide quando chamar uma ferramenta e como usar o resultado para formar sua resposta. Enquanto isso, o desenvolvedor não precisa orquestrar manualmente essas etapas, o framework MCP e o modelo de IA cuidam disso. O resultado final é que o usuário pode fazer perguntas complexas à IA ou solicitar tarefas que exigem informações ou ações externas, e a IA pode executá-las de forma autônoma via MCP e retornar um resultado.

Benefícios de usar um MCP

Observe como essa abordagem abstrai muitos detalhes: o cliente não tratou chaves de API nem códigos de status HTTP, isso é tratado pelo servidor MCP.

O ponto principal é a simplicidade no ponto de integração: nós “pedimos” clientes, e nós os recebemos. A lógica de como buscá-los fica encapsulada em outro lugar. Isso significa que um desenvolvedor que trabalha no lado da IA não precisa escrever novas chamadas HTTP para cada nova ação, ele apenas invoca ferramentas pelo nome. O trabalho pesado (autenticação, chamadas aos endpoints do Google Drive, formatação da resposta) é feito no código do servidor MCP, que é reutilizável e padronizado.

Aqui está um resumo dos principais benefícios:

Reduz código de ligação específico de APIs. Antes do MCP, fazer uma IA usar um serviço externo normalmente exigia escrever muito código de “ligação”: chamar a API, transformar a resposta em texto que o modelo conseguisse digerir, depois analisar a saída do modelo para talvez chamar outra API etc. Com MCP, boa parte dessa ligação é eliminada. O cliente do modelo e o servidor tratam a troca de dados de forma estruturada, então você não precisa transformar manualmente outros formatos (como JSON) em texto ou vice-versa, o protocolo faz isso. Você também não precisa escrever lógica para decidir quando chamar o quê. A IA (guiada pelas descrições das ferramentas e por seu próprio raciocínio ou prompt) faz isso.
Conectores reutilizáveis e compartilhados em vez de wrappers de API pontuais. Com MCP, você escreve uma integração uma vez e pode reutilizá-la em muitos projetos e sistemas de IA. Por exemplo, você poderia criar um servidor MCP para a wiki interna da sua empresa. Qualquer app de IA compatível com MCP pode se conectar a esse servidor para consultar a wiki. Você não precisa reimplementar “busca na wiki” para cada novo chatbot de IA ou para cada fornecedor de LLM diferente. Essa reutilização é uma mudança em relação ao passado, quando cada equipe talvez escrevesse sua própria integração ligeiramente diferente para a mesma API. O MCP incentiva uma biblioteca de conectores que podem ser compartilhados e melhorados coletivamente.
Integração plug-and-play com diferentes LLMs. MCP é agnóstico em relação ao modelo. O protocolo não se importa se o cliente é Claude, GPT-4, DeepSeek ou qualquer modelo futuro, desde que o cliente consiga lidar com a interface MCP. No futuro, se você quiser mudar para outro modelo, poderá fazer isso sem reescrever todas as suas integrações.
Manutenção mais fácil. Como é um padrão aberto, há uma comunidade crescente contribuindo com servidores pré-construídos (para bancos de dados, APIs populares etc.) que você pode aproveitar em vez de criar tudo do zero. À medida que você integra mais sistemas, o MCP ajuda a evitar o “espaguete” de muitas integrações ponto a ponto. E você não precisa monitorar todas as atualizações de API de outros provedores.

Integrações de API se tornarão obsoletas?

Tanto integrações tradicionais de API quanto MCP têm seu lugar. A melhor abordagem pode depender da natureza do projeto, da experiência da equipe e dos objetivos de longo prazo.

Se você só precisa integrar um ou dois serviços externos e as interações são relativamente simples, uma integração direta de API costuma ser a solução mais rápida. Se seu app web só precisa verificar um token de pagamento do Stripe no checkout, chamar a API do Stripe diretamente é simples e eficaz. Introduzir MCP nesse cenário pode ser excessivo. Você pode conectar um AI Agent a qualquer API REST documentada com uma HTTP Action revisada, ou usar uma integração de um clique como Google Sheets para registrar leads e solicitações de demonstração, sem executar um servidor MCP.

Em casos em que você precisa de controle muito preciso sobre a requisição/resposta (para ajuste de desempenho, tratamento especial de dados ou protocolos proprietários), escrever diretamente para a API pode ser melhor. Integrações tradicionais permitem usar todos os recursos avançados de uma API e personalizar as chamadas exatamente. Se uma API tem requisitos incomuns ou se você quer evitar qualquer camada de abstração para máxima clareza e controle, a abordagem tradicional é apropriada.

Para um exemplo concreto de como ferramentas MCP são expostas a um AI Agent de produção junto com ações de API personalizadas, veja como Quickchat AI Agents combinam as duas abordagens. A discussão mais aprofundada sobre quando usar MCP, AI Actions individuais ou “Generate from Text” está em APIs para AI Agents: de MCP a endpoints personalizados. Para testar por conta própria, siga o guia passo a passo para conectar seu AI Agent a um servidor MCP remoto, de modo que ele chame uma ferramenta ativa no meio da conversa.

Lista de servidores MCP disponíveis

Se você quer começar com MCP, confira os diretórios de servidores MCP abaixo:

Você também pode executar um sem escrever nenhum código: todo Quickchat AI Agent pode ser transformado em um servidor MCP com uma URL hospedada que Claude, ChatGPT e Cursor chamam como ferramenta. A conexão também funciona na outra direção: um Quickchat AI Agent pode chamar um servidor MCP hospedado de um fornecedor como suas ferramentas, que é como o assistente de agendamento de IA criado sobre o servidor MCP da Calendly verifica disponibilidade real e agenda reuniões a partir de um chat, e como um chatbot de IA para Notion responde a partir de uma central de ajuda ativa e registra solicitações de suporte de volta em um banco de dados do Notion.

A Quickchat AI também executa um servidor MCP remoto para sua própria conta. Conecte-o ao ChatGPT, Claude, Cursor ou Codex e você poderá gerenciar seus AI Agents a partir dali: analytics, transcrições de conversas, atualizações da base de conhecimento e criação de novos Agents, por trás de um único login OAuth. O passo a passo de configuração para cada cliente está em Gerencie seu AI Agent a partir do ChatGPT, Claude e Codex com MCP.

FAQ

Ele funciona apenas com Claude?

MCP é agnóstico em relação ao modelo. O protocolo não se importa se o cliente é Claude, GPT-4, um derivado local do LLaMA ou qualquer modelo futuro, desde que o cliente consiga lidar com a interface MCP. Isso significa que você não fica preso a um único provedor de IA ao criar suas integrações de ferramentas.

Como o MCP difere de simplesmente fornecer ao modelo todas as informações de que ele precisa logo de início? Por que não encher o prompt com dados?

MCP é fundamentalmente diferente de encher o prompt do modelo com dados porque permite que o modelo busque informações dinamicamente quando necessário, em vez de trabalhar com um prompt estático e pré-carregado. Colocar texto demais no prompt esbarra em limitações, pois modelos de IA têm uma janela de contexto fixa, o que significa que dados demais podem fazer detalhes importantes se perderem, desacelerar respostas e aumentar custos de API (por causa dos modelos de preço por token usados por fornecedores de LLM). Isso também fornece conhecimento apenas em um ponto específico no tempo, enquanto o MCP permite acesso em tempo real a dados externos ativos e permite que a IA execute ações, não apenas leia informações. Uma IA com um prompt carregado pode conhecer detalhes de clientes, mas não conseguirá atualizar registros nem processar transações.

E se conectarmos dezenas de ferramentas à IA? Isso não vai sobrecarregar o modelo ou fazer com que ele as use de forma incorreta?

Depende da implementação, mas é verdade que os LLMs atuais têm limites em quão bem distinguem e escolhem entre muitas opções. Se você apresentar a um modelo, digamos, 50 ferramentas possíveis, há risco de ele escolher a errada. A abordagem MCP em si não obriga você a carregar tudo de uma vez. Você deve conectar ferramentas relevantes com base no contexto. Uma boa prática é conectar apenas as ferramentas necessárias para a tarefa/domínio em questão e aproveitar colaboração multiagente, uma espécie de roteamento de ferramentas ou um agente que primeiro decide qual subconjunto de ferramentas considerar.

MCP vs Function Calling

Function calling tradicional (como visto na API da OpenAI ou em outros LLMs) permite que um desenvolvedor defina um conjunto de funções, forneça suas definições ao modelo e faça o modelo “chamá-las” pelo nome com argumentos. Isso foi um grande passo para integração de IA, mas tem limitações. Uma diferença importante é quando e como as ferramentas são definidas. No function calling clássico, todas as funções possíveis devem ser declaradas antecipadamente (em tempo de design) no prompt ou por meio da API. O modelo só pode chamar essas funções fixas. No MCP, as ferramentas são descobertas em tempo de execução, a IA pode consultar o que está disponível e até receber novas ferramentas no meio da sessão.

MCP vs GPT Actions & Plugins

GPT Actions/Plugins se referem ao ecossistema da OpenAI no qual você podia habilitar plugins (como um navegador web ou um leitor de PDF) para o ChatGPT, ou os “GPTs” (agentes ChatGPT personalizados) que podem usar ferramentas. Eles foram interessantes, mas exigiam desenvolvimento personalizado para cada plugin e eram limitados às plataformas da OpenAI. Se você quisesse um plugin do ChatGPT para uma tarefa, precisava criar uma API e um manifesto, e passar pela aprovação da OpenAI ou pelo menos habilitá-lo manualmente. Cada plugin era essencialmente um silo, um plugin de clima, um plugin de viagens etc., cada um com seus próprios endpoints e lógica. O MCP melhora esse conceito ao unificá-lo e abri-lo.

MCP vs RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) é uma técnica na qual um LLM é complementado com uma base de conhecimento externa. Normalmente, RAG envolve um banco de dados vetorial ou índice de busca: a consulta do usuário é usada para buscar documentos ou dados relevantes (por busca semântica ou outros métodos), e esses documentos são fornecidos ao modelo como contexto adicional para “ler” ao formar uma resposta. RAG trata de dar ao modelo conhecimento que ele não tinha originalmente, especialmente útil para QA factual ou informações específicas de domínio. No entanto, RAG é somente leitura, o modelo recupera trechos de texto, mas não executa ações além da recuperação.

MCP, em contraste, trata de executar ações ou realizar operações arbitrárias, não apenas recuperar contexto informativo. Com MCP, uma IA pode fazer coisas: escrever em um banco de dados, enviar um email, executar código etc. Ele não se limita a buscar conhecimento. Pode acionar mudanças em sistemas externos. Portanto, de muitas formas, RAG e MCP servem a propósitos diferentes.