O que é MCP (Model Context Protocol)?

O problema que o MCP resolve

Antes do MCP, cada aplicação de IA que precisava conversar com um serviço externo construía uma integração personalizada. Ou seja, um conector para o GitHub, outro para o banco de dados e mais um para o sistema de chamados.

Pense em uma equipe com cinco modelos diferentes e cinco fontes de dados. Nesse caso, eram necessárias até 25 integrações distintas para cobrir todas as combinações possíveis.

Esse cenário ficou conhecido como problema NxM. Nele, N representa a quantidade de modelos e M a quantidade de ferramentas ou fontes de dados.

Além do custo inicial, cada integração exigia manutenção própria. Por isso, qualquer mudança em uma API externa podia quebrar vários conectores ao mesmo tempo.

O MCP elimina essa fragmentação com um protocolo único e padronizado. Dessa forma, qualquer fonte de dados exposta por um servidor MCP pode ser consumida por qualquer aplicação compatível.

Na prática, o problema deixa de ser NxM e passa a ser N+M. Cada modelo implementa o cliente uma vez, e cada ferramenta implementa o servidor uma vez.

A própria Anthropic descreveu a motivação no anúncio oficial do Model Context Protocol. Segundo o texto, até os modelos mais sofisticados ficam limitados pelo isolamento dos dados, presos em silos e sistemas legados.

A analogia do MCP com o USB-C

Uma forma simples de entender o protocolo é compará-lo ao padrão USB-C dos dispositivos físicos. A documentação oficial usa exatamente essa analogia.

Antes do USB, cada periférico, como mouse, teclado ou impressora, exigia um conector diferente e um driver específico. Assim, conectar um equipamento novo era quase sempre uma pequena aventura.

O USB-C unificou essa comunicação. Com isso, qualquer dispositivo compatível se conecta a qualquer acessório usando o mesmo conector.

O MCP faz o mesmo para a inteligência artificial. Ele padroniza a comunicação entre modelos de linguagem e fontes de dados, ferramentas e serviços externos.

No entanto, a analogia tem um limite importante. O protocolo define apenas o formato da troca de contexto e não determina como a aplicação usa o modelo ou gerencia esse contexto.

Como o MCP funciona

A arquitetura segue o modelo cliente e servidor, com três componentes que trabalham de forma coordenada. Primeiro vem o host, depois o cliente e, por fim, o servidor.

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_order_status",
    "arguments": {
      "orderId": 42
    }
  }
}

Os três pilares de integração do MCP

O protocolo define três tipos principais de informação que o servidor oferece ao cliente. Na documentação, eles aparecem como primitivas do servidor.

Os Resources são dados que a IA pode ler. Por exemplo, arquivos de texto, documentos, registros de banco de dados ou respostas de uma API.

As Tools são funções executáveis que a IA pode acionar. Enviar um e-mail, executar um script ou fazer uma busca na web são exemplos típicos.

Os Prompts são templates de instruções pré-configurados. Eles orientam o comportamento do modelo em contextos específicos, como um roteiro de revisão de código.

Cada primitiva tem métodos de descoberta no padrão */list, como tools/list e resources/list. Dessa forma, o cliente primeiro descobre o que existe e só depois executa.

Imagine um servidor MCP para um banco de dados. Ele pode expor uma tool para consultas, um resource com o esquema das tabelas e um prompt com exemplos de uso.

Por outro lado, o cliente também oferece primitivas ao servidor. A elicitation, por exemplo, permite que o servidor peça uma informação adicional ou uma confirmação ao usuário.

O handshake e a descoberta de capacidades

Quando um cliente MCP se conecta a um servidor, o primeiro passo é um handshake de descoberta de capacidades. Na especificação 2025-11-25, essa etapa usa a requisição initialize.

Nessa fase, cliente e servidor trocam informações sobre o que suportam. O cliente informa a versão do protocolo que compreende, e o servidor responde com as ferramentas e os recursos que consegue fornecer.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "elicitation": {}
    },
    "clientInfo": {
      "name": "ExampleClient",
      "version": "1.0.0"
    }
  }
}

Se o servidor suporta a versão pedida, ele responde com a mesma versão. Caso contrário, ele propõe outra, e o cliente decide se continua ou se desconecta.

Em seguida, o cliente envia a notificação notifications/initialized. A partir daí começa a fase de operação, também chamada de descoberta dinâmica, em que os dois lados colaboram para resolver os pedidos do usuário.

Nessa fase, o servidor pode avisar que sua lista de ferramentas mudou. Então, o cliente pede a lista atualizada e o modelo passa a enxergar as novas capacidades.

Vale acompanhar a evolução da especificação. A revisão 2026-07-28 torna o protocolo stateless e introduz a requisição server/discover, em que cada mensagem carrega a versão e as capacidades no campo _meta.

Transportes suportados pelo MCP

O protocolo suporta dois mecanismos principais de transporte. Além deles, a especificação permite transportes customizados, desde que preservem o formato JSON-RPC.

O stdio (entrada e saída padrão) atende conexões locais. Ele é rápido e seguro, pois os dados não saem da máquina onde o servidor e o host estão rodando.

Nesse modo, o cliente inicia o servidor como um subprocesso. Por isso, o servidor nunca escreve no stdout nada que não seja uma mensagem válida do protocolo, e os logs vão para o stderr.

O SSE (Server-Sent Events) foi o mecanismo original para conexões remotas. Com ele, a IA acessava dados em nuvem ou APIs externas por uma conexão HTTP persistente.

Contudo, a especificação de março de 2025 substituiu o HTTP com SSE pelo Streamable HTTP. Nele, o servidor expõe um único endpoint que aceita POST e GET e usa SSE apenas quando precisa enviar várias mensagens em sequência.

A documentação de transportes do MCP também traz alertas de segurança. Por exemplo, o servidor deve validar o cabeçalho Origin, e servidores locais devem escutar apenas em 127.0.0.1.

Adoção do MCP pelo mercado

Após o lançamento, outras grandes empresas do setor adotaram o protocolo rapidamente. Logo no anúncio, Block e Apollo já tinham integrado o padrão aos seus sistemas.

Ferramentas de desenvolvimento como Zed, Replit, Codeium e Sourcegraph também aderiram cedo. O objetivo era permitir que agentes de IA recuperassem informações relevantes do código com mais facilidade.

A OpenAI adotou oficialmente o protocolo em março de 2025. Com isso, ele chegou aos produtos da empresa, incluindo o ChatGPT Desktop.

O Google DeepMind também aderiu, sinalizando uma convergência do mercado em torno do padrão. No ecossistema Microsoft, Copilot Studio, o modo agente do GitHub Copilot no VS Code e o Agent Framework oferecem suporte.

Em dezembro de 2025, a Anthropic doou o MCP para a Agentic AI Foundation (AAIF). Trata-se de um fundo sob a Linux Foundation, cofundado por Anthropic, Block e OpenAI.

Segundo o blog oficial do protocolo, Google, Microsoft, AWS, Cloudflare e Bloomberg apoiam a fundação. Além disso, os mantenedores continuam decidindo os rumos técnicos da especificação.

SDKs disponíveis para MCP

O protocolo nasceu com kits de desenvolvimento para várias linguagens, incluindo Python, TypeScript, C# e Java. Depois, a lista cresceu e passou a incluir Kotlin, Go, Rust, Swift, PHP e Ruby.

A Anthropic também mantém um repositório de código aberto com servidores de referência. Ele cobre sistemas amplamente utilizados, como Google Drive, Slack, GitHub, Git, PostgreSQL e Puppeteer.

using System.ComponentModel;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using ModelContextProtocol.Server;

var builder = Host.CreateApplicationBuilder(args);

// Logs vão para o stderr, pois o stdout é reservado às mensagens do protocolo
builder.Logging.AddConsole(options =>
{
    options.LogToStandardErrorThreshold = LogLevel.Trace;
});

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

[McpServerToolType]
public static class OrderTools
{
    // A descrição ajuda o modelo a decidir quando usar a ferramenta
    [McpServerTool, Description("Returns the shipping status of an order.")]
    public static string GetOrderStatus(
        [Description("Order identifier")] int orderId)
        => $"Order {orderId} is being shipped.";
}

Segurança e considerações importantes

Como envolve execução de código e acesso a dados externos, o protocolo exige atenção redobrada com segurança. Afinal, uma ferramenta mal desenhada dá ao modelo um poder que ninguém pretendia conceder.

Em abril de 2025, pesquisadores identificaram vulnerabilidades relevantes no ecossistema. Entre elas estavam riscos de prompt injection, permissões excessivas em ferramentas e servidores maliciosos se passando por servidores confiáveis.

Também houve alertas sobre ferramentas envenenadas. Nesse ataque, uma descrição manipulada leva o modelo a vazar dados por meio de outras ferramentas conectadas.

A especificação oficial recomenda que implementadores construam fluxos robustos de consentimento e autorização. Além disso, pede controles de acesso adequados para proteger os dados dos usuários.

Na prática, algumas medidas ajudam bastante:

• Instale apenas servidores de fontes confiáveis e revise o código quando possível.
• Conceda a cada ferramenta o mínimo de permissões necessário.
• Exija confirmação humana antes de ações destrutivas ou irreversíveis.
• Use OAuth ou outro mecanismo de autenticação em servidores remotos.

Hosts como o GitHub Copilot já pedem permissão antes de executar uma ferramenta. Ainda assim, a responsabilidade final continua com quem configura e publica o servidor.

MCP e RAG: tecnologias complementares

É importante compreender que o MCP não substitui técnicas como o RAG (Retrieval-Augmented Generation). Na verdade, os dois se complementam.

O RAG foca em enriquecer o contexto do modelo com dados recuperados e vetorizados previamente. Se quiser revisar o conceito, veja o artigo o que é RAG.

Por outro lado, o MCP viabiliza a execução de ações em tempo real e a integração direta com sistemas externos. Assim, um agente pode consultar um documento vetorizado e, logo depois, abrir um chamado em outro sistema.

As duas abordagens podem e devem ser usadas em conjunto em arquiteturas de agentes mais complexas. Para comparar os cenários lado a lado, confira RAG ou MCP: qual escolher.

Da mesma forma, vale entender a fronteira entre protocolo e agente. O artigo o que são agents explica como os agentes usam ferramentas para cumprir objetivos.

Conclusão sobre o que é MCP

Saber o que é MCP ajuda a enxergar uma mudança estrutural na forma como aplicações de IA se integram ao mundo real. O protocolo troca dezenas de conectores sob medida por um contrato único.

Ao padronizar a comunicação entre modelos e fontes de dados externas, o padrão reduz o custo de desenvolvimento e de manutenção das integrações. Ao mesmo tempo, ele amplia as capacidades operacionais dos agentes de IA.

Para equipes que desenvolvem soluções baseadas em LLMs, adotar o MCP tornou-se uma etapa fundamental. Com ele, os sistemas ficam mais conectados, escaláveis e eficientes, desde que a segurança acompanhe cada ferramenta exposta.

FAQ

O que significa a sigla MCP?

MCP significa Model Context Protocol. É um protocolo aberto que padroniza a conexão entre aplicações de IA e fontes de dados ou ferramentas externas.

Quem criou o Model Context Protocol?

A Anthropic lançou o protocolo em novembro de 2024. Em dezembro de 2025, ela o doou para a Agentic AI Foundation, sob a Linux Foundation.

Qual a diferença entre cliente e servidor MCP?

O cliente vive dentro do host e mantém a conexão com um servidor. Já o servidor expõe tools, resources e prompts de uma fonte de dados.

O MCP substitui o RAG?

Não. O RAG enriquece o contexto com dados recuperados, enquanto o MCP permite consultar sistemas e executar ações em tempo real.

Posso criar um servidor MCP em C#?

Sim. O SDK oficial em C# está disponível no NuGet e permite criar servidores com transporte stdio ou HTTP.