Agents ou MCP: Qual escolher?

Anatomia de um agente

Um agente reúne quatro elementos fundamentais. Cada um deles resolve uma parte diferente do problema.

Modelo (LLM): o núcleo responsável pelo raciocínio, pela tomada de decisão e pela geração de respostas.

Memória: pode ser de curto prazo, como o contexto da conversa atual. Também pode ser de longo prazo, com recuperação semântica via embeddings ou banco de dados.

Ferramentas (tools): funções que o agente pode invocar para agir no mundo real. Por exemplo, buscar dados, executar código, enviar e-mails ou consultar APIs.

Orquestração: a lógica que controla o ciclo de vida do agente. Ela define quando o agente para, quando delega para outro agente e como lida com falhas.

Padrões de orquestração

Existem diferentes padrões para estruturar agentes em produção. Os dois mais comuns são o single agent e o multi-agent.

No padrão single agent, um único agente executa todas as etapas de uma tarefa. Assim, ele atende bem fluxos simples e bem delimitados.

No padrão multi-agent, vários agentes especializados colaboram entre si. Nesse caso, um agente orquestrador distribui subtarefas e, no final, consolida os resultados.

Frameworks como o Microsoft Agent Framework implementam essa arquitetura de forma nativa. Segundo a documentação oficial do Microsoft Agent Framework, ele é o sucessor direto do Semantic Kernel e do AutoGen, criado pelas mesmas equipes.

Além disso, o framework oferece workflows para controlar caminhos de execução entre agentes. A comunicação entre agentes de plataformas diferentes também pode usar o protocolo A2A (Agent-to-Agent).

Primitivos do MCP

O protocolo se apoia em três primitivos principais. A especificação do Model Context Protocol também define quem controla cada um deles.

Resources: representam fontes de dados que o modelo pode consultar, como arquivos, registros de banco de dados ou resultados de APIs. Na especificação, a aplicação cliente controla esses recursos.

Tools: funções que o modelo pode invocar para executar ações. Cada tool traz nome, descrição e parâmetros descritos em JSON Schema, e o próprio modelo decide quando chamá-la.

Prompts: templates reutilizáveis que o servidor expõe para estruturar interações específicas. Normalmente, o usuário escolhe esses prompts, como acontece com um comando de barra no editor.

Como o MCP funciona na prática

A arquitetura do MCP segue o modelo cliente e servidor. Portanto, existem dois papéis bem definidos.

O MCP server é o componente que expõe recursos, ferramentas e prompts. Ele pode rodar localmente, via stdio, ou remotamente, via HTTP com Streamable HTTP ou o transporte SSE mais antigo.

O MCP client é o componente que consome o servidor. Pode ser um editor como o VS Code, um framework como o Microsoft Agent Framework ou uma aplicação própria em C#.

A comunicação usa JSON-RPC 2.0. Com isso, o protocolo garante interoperabilidade, independentemente da linguagem ou da plataforma de cada lado.

O benefício da padronização

Antes do MCP, um agente que precisasse acessar um banco de dados, um repositório no GitHub e uma API de calendário integrava três sistemas com três contratos diferentes.

Com o MCP, cada um desses sistemas expõe um servidor próprio. Então, o agent se conecta a todos eles usando o mesmo protocolo MCP.

Isso reduz bastante o acoplamento entre o agente e os sistemas que ele consome. Além disso, facilita trocar ou adicionar fontes de dados sem mexer no núcleo do agente.

A adoção confirma esse benefício. Segundo a Anthropic, no momento da doação já existiam mais de 10 mil servidores MCP públicos ativos, com suporte em produtos como ChatGPT, Cursor, Gemini, Microsoft Copilot e VS Code.

Descoberta dinâmica de ferramentas

Uma das propriedades mais poderosas dessa combinação é a descoberta dinâmica. Ela muda a forma de evoluir o sistema.

Quando um agent se conecta a um servidor MCP, ele lista todas as ferramentas disponíveis em tempo de execução. Em seguida, o LLM recebe essa lista como contexto e escolhe quais ferramentas invocar.

Na prática, você adiciona novas capacidades ao agente registrando um novo servidor MCP. Ou seja, não há necessidade de recompilar nem de publicar o agente de novo.

MCP em sistemas multi-agent

Em arquiteturas multi-agent, o MCP ganha um papel ainda mais relevante. Isso acontece porque um agente também pode virar ferramenta de outro.

Cada agent especializado pode expor suas capacidades como um servidor MCP. Assim, o agente orquestrador descobre e invoca esses agentes como se fossem ferramentas comuns.

O Microsoft Agent Framework suporta esse cenário de forma direta. A documentação mostra como envolver um agente com AsAIFunction() e registrá-lo como tool de um servidor MCP.

Essa abordagem permite que times diferentes desenvolvam agentes independentes, cada um com responsabilidades claras. Depois, todos se integram de forma padronizada via protocolo.

Criando um servidor MCP em C#

O primeiro passo é adicionar o pacote ModelContextProtocol.AspNetCore a um projeto web. Em seguida, registre o servidor e mapeie o endpoint.

var builder = WebApplication.CreateBuilder(args);

// Registra o servidor MCP com transporte HTTP (Streamable HTTP)
builder.Services
    .AddMcpServer()
    .WithHttpTransport()
    .WithTools<CodeReviewTools>();

var app = builder.Build();

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

O atributo [McpServerToolType] marca a classe que contém ferramentas. Já o atributo [McpServerTool] marca cada método exposto pelo servidor.

using System.ComponentModel;
using ModelContextProtocol.Server;

[McpServerToolType]
public class CodeReviewTools
{
    [McpServerTool(Name = "analyze_code")]
    [Description("Analyzes C# code for common issues")]
    public static string AnalyzeCode(
        [Description("The C# source code to analyze")] string sourceCode)
    {
        // aqui entraria a análise real com Roslyn
        var lineCount = sourceCode.Split('\n').Length;
        return $"Analyzed {lineCount} lines. No issues found.";
    }
}

O atributo [Description] é essencial. Afinal, é essa descrição que o modelo lê para decidir quando usar a ferramenta.

Conectando um agent ao servidor MCP

Com o Microsoft Agent Framework, a integração com um servidor MCP é direta. Primeiro, você cria um cliente MCP e lista as ferramentas do servidor.

Depois, entrega essas ferramentas ao agent no momento da criação. O exemplo abaixo segue o padrão da documentação de MCP no Agent Framework.

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using ModelContextProtocol.Client;
using OpenAI;

// Conecta ao servidor MCP remoto
await using var mcpClient = await McpClient.CreateAsync(
    new HttpClientTransport(new HttpClientTransportOptions
    {
        Endpoint = new Uri("http://localhost:5000/mcp"),
        Name = "CodeReview"
    }));

// Descobre as ferramentas expostas pelo servidor
var mcpTools = await mcpClient.ListToolsAsync();

// Cria o agente com as ferramentas do MCP
AIAgent agent = new OpenAIClient(apiKey)
    .GetChatClient("gpt-4o-mini")
    .AsAIAgent(
        instructions: "You review C# code using the available tools.",
        tools: [.. mcpTools.Cast<AITool>()]);

var result = await agent.RunAsync("Review the code in the Program.cs file");
Console.WriteLine(result);

O método ListToolsAsync() devolve as ferramentas já convertidas para o tipo AITool. Dessa forma, o agente as utiliza conforme necessário para completar o objetivo.

Repare na divisão de papéis. O servidor só expõe analyze_code, enquanto o agent decide se, quando e quantas vezes chamar essa ferramenta.