RAG ou MCP: qual escolher?

Componentes de um pipeline RAG

Um pipeline RAG bem construído envolve ao menos quatro componentes. São eles: um mecanismo de ingestão de documentos, um modelo de embedding, um banco de dados vetorial e um LLM para a geração final.

A qualidade do resultado depende diretamente de cada etapa. Um documento mal fragmentado, um modelo de embedding inadequado ou uma recuperação ingênua degradam a resposta gerada.

Por isso, cenários de produção costumam exigir técnicas avançadas. Entre elas estão o HyDE (Hypothetical Document Embeddings), o reranking com cross-encoders, a busca híbrida e a expansão de consultas.

A busca híbrida, por exemplo, junta a similaridade vetorial com a busca lexical tradicional. Dessa forma, termos exatos como códigos de produto também entram no resultado.

Quando RAG é a solução certa

O RAG é ideal quando o modelo precisa acessar grandes volumes de documentos textuais não estruturados ou semiestruturados. Nesse caso, a busca vetorial escala bem e mantém o prompt enxuto.

Entre os casos típicos estão chatbots sobre documentação técnica e assistentes de suporte com acesso à base de conhecimento. Também se encaixam a busca semântica em acervos de artigos e a análise de contratos.

Em outras palavras, o RAG brilha quando o problema é "o modelo precisa saber o que está escrito em algum lugar". Ele resolve o problema de conhecimento.

Arquitetura do MCP

A especificação oficial do MCP define três primitivas que um servidor pode expor. São elas as tools, os resources e os prompts.

As tools são funções que o modelo pode invocar para executar ações. Por exemplo, buscar dados em uma API, inserir registros em um banco, enviar notificações ou rodar comandos.

Os resources representam conteúdo que a aplicação lê e anexa ao contexto do modelo. Arquivos, páginas, registros de banco e histórico de um repositório Git são bons exemplos.

Os prompts, por sua vez, são templates reutilizáveis que guiam o modelo em fluxos específicos. Além disso, eles aceitam parâmetros para se adaptar a cada situação.

A especificação também deixa claro quem controla cada primitiva. O modelo controla as tools, a aplicação controla os resources e o usuário controla os prompts.

Transportes e JSON-RPC

A comunicação entre cliente e servidor usa mensagens JSON-RPC 2.0. Para processos locais, o transporte padrão é o stdio, em que o cliente inicia o servidor como subprocesso.

Para servidores remotos, a versão original do protocolo usava HTTP com SSE (Server-Sent Events). Contudo, a revisão de março de 2025 substituiu esse modelo pelo transporte Streamable HTTP.

No Streamable HTTP, o servidor expõe um único endpoint que aceita POST e GET. Então, ele pode responder com JSON simples ou abrir um stream SSE quando precisa enviar várias mensagens.

Quando MCP é a solução certa

O MCP é ideal quando o objetivo é dar ao modelo a capacidade de agir, não apenas de saber. Afinal, a diferença está entre recuperar informação passiva e executar operações com efeitos colaterais.

Entre os casos típicos estão agentes que criam tarefas em gerenciadores de projetos e assistentes que consultam APIs em tempo real. Também entram ferramentas de desenvolvimento que interagem com repositórios e automações que encadeiam vários serviços.

Em resumo, o MCP brilha quando o problema é "o modelo precisa fazer algo no mundo". Ele resolve o problema de capacidade de ação.

Latência e determinismo de RAG e MCP

Em termos de latência, o RAG adiciona o tempo da busca vetorial antes da geração. Já o MCP adiciona o tempo das chamadas de rede às ferramentas durante a geração.

Quanto ao determinismo, o RAG tende a ser mais previsível, porque o conteúdo recuperado é estável para uma mesma consulta. Enquanto isso, o MCP varia mais, já que o modelo decide quais ferramentas chamar e em qual ordem.

Portanto, ao comparar RAG ou MCP nesse eixo, considere quanto de autonomia o seu sistema realmente precisa. Mais autonomia significa mais flexibilidade, mas também mais pontos de falha.

Escopo dos dados

Em termos de escopo, o RAG funciona melhor com corpora grandes e estáticos, ou de atualização pouco frequente. Afinal, todo documento novo precisa passar pela ingestão e pela vetorização.

O MCP, em contrapartida, acessa dados estruturados diretamente pela API de origem.

Nesse eixo, a escolha entre RAG ou MCP depende de quão rápido a informação muda. Assim, a informação chega sempre atualizada e sem etapa de indexação.

RAG exposto como tool MCP

Existe ainda uma terceira via, que dissolve de vez o dilema entre RAG ou MCP. Um servidor MCP pode expor uma tool de busca que, internamente, executa todo o pipeline RAG.

Dessa forma, o agente decide sozinho quando precisa consultar a base de conhecimento. O RAG continua cuidando da recuperação, e o MCP cuida da forma padronizada de expor essa capacidade.

Bibliotecas para RAG

Para RAG, o pacote Microsoft.Extensions.VectorData.Abstractions oferece abstrações para trabalhar com bancos vetoriais de forma agnóstica. Assim, você escreve o código uma vez e troca o provedor depois.

Há implementações para Qdrant, Azure AI Search, SQL Server, Cosmos DB, MongoDB e Elasticsearch, entre outros. Além disso, a documentação de bancos vetoriais para .NET recomenda o provedor em memória apenas para protótipos.

A ingestão de documentos, por sua vez, pode ser orquestrada com Microsoft.Extensions.DataIngestion, ainda em preview. A biblioteca encadeia leitores, processadores, estratégias de chunking e writers em um IngestionPipeline<T>.

Esse tema ganhou um artigo próprio no blog, sobre ingestão de dados para aplicações .NET com RAG.

SDK oficial do MCP em C#

Para MCP, o SDK oficial em C# permite criar servidores que expõem ferramentas e recursos, além de clientes que se conectam a servidores existentes. O pacote ModelContextProtocol.AspNetCore integra tudo ao ASP.NET Core.

O exemplo abaixo registra um servidor com transporte Streamable HTTP e descobre automaticamente as classes marcadas como tools.

var builder = WebApplication.CreateBuilder(args);

// Registra o servidor MCP com transporte HTTP e descobre as tools do assembly
builder.Services
    .AddMcpServer()
    .WithHttpTransport()
    .WithToolsFromAssembly();

var app = builder.Build();

// Expõe o endpoint MCP em /mcp
app.MapMcp("/mcp");

app.Run();

Em seguida, uma classe pode expor a busca na base de conhecimento como tool. Nesse caso, o RAG vira uma capacidade acessível via MCP.

using System.ComponentModel;
using Microsoft.Extensions.VectorData;
using ModelContextProtocol.Server;

[McpServerToolType]
public sealed class KnowledgeBaseTools(VectorStoreCollection<Guid, DocumentChunk> collection)
{
    [McpServerTool(Name = "search_knowledge_base")]
    [Description("Searches the internal documentation and returns the most relevant excerpts.")]
    public async Task<IReadOnlyList<string>> SearchAsync(
        [Description("The user question in natural language")] string query,
        CancellationToken cancellationToken)
    {
        var results = new List<string>();

        // Busca vetorial: o embedding da consulta é gerado pelo gerador configurado na coleção
        await foreach (var result in collection.SearchAsync(query, top: 3, cancellationToken: cancellationToken))
        {
            results.Add(result.Record.Content);
        }

        return results;
    }
}

public sealed class DocumentChunk
{
    [VectorStoreKey]
    public Guid Id { get; set; }

    [VectorStoreData]
    public string Content { get; set; } = string.Empty;

    [VectorStoreVector(1536)]
    public string Embedding => Content;
}

Com isso, qualquer cliente MCP, como o GitHub Copilot ou um agente próprio, passa a consultar a documentação interna. Quem quiser conhecer o SDK a fundo pode ler sobre o lançamento da versão 1 do SDK oficial do MCP para C#.

Microsoft Agent Framework

O Microsoft Agent Framework chegou à versão 1.0 em abril de 2026, com APIs estáveis para .NET e Python. Ele sucede o Semantic Kernel e o AutoGen e reúne as duas abordagens em um único orquestrador.

Os agentes do framework consomem servidores MCP como ferramentas e usam provedores de contexto com busca vetorial para RAG. Assim, em uma arquitetura multiagente, cada especialista pode ter suas próprias tools MCP e seu próprio índice vetorial.

Na prática, o framework torna a dúvida entre RAG ou MCP uma questão de configuração de cada agente. Ou seja, você não precisa abrir mão de nenhuma das duas.

Cuidados de segurança com RAG e MCP

Com o MCP, o modelo decide quais ferramentas chamar, então a autorização merece atenção redobrada. Defina escopos restritos e implemente autenticação adequada nos servidores.

Além disso, a especificação pede que servidores HTTP validem o cabeçalho Origin para evitar ataques de DNS rebinding. Em contextos críticos, inclua também uma confirmação humana antes de ações irreversíveis.

No RAG, o cuidado principal está no controle de acesso aos documentos indexados. Afinal, um trecho recuperado vai direto para o contexto e pode expor informação sensível.