O que é o MCP (Model Context Protocol) e como ele funciona

Todo assistente de IA esbarra no mesmo limite: ele conhece muita coisa sobre o mundo até a data de corte do treinamento, mas não sabe nada sobre os seus arquivos, o seu banco de dados ou a API interna da sua empresa. O Model Context Protocol (MCP) nasceu para fechar exatamente essa lacuna. Desde que a Anthropic o lançou como padrão aberto no fim de 2024, ele virou, na prática, uma espécie de USB-C para conectar modelos de linguagem a ferramentas e dados externos.

O que é o MCP

O Model Context Protocol é um protocolo aberto, baseado em JSON-RPC 2.0, que define uma forma padronizada de um modelo de linguagem (ou o aplicativo que o hospeda) se conectar a fontes de dados e ferramentas externas. Em vez de cada assistente de IA reinventar sua própria forma de ler um arquivo, consultar um banco de dados ou disparar uma automação, o MCP oferece uma interface comum que qualquer servidor pode implementar e qualquer cliente pode consumir.

Na prática, isso significa que quem constrói uma integração, por exemplo um conector para o GitHub ou para o Google Drive, faz esse trabalho uma única vez, na forma de um servidor MCP. Qualquer aplicativo compatível, como o Claude Desktop, o Claude Code, uma IDE ou um agente customizado, passa a conseguir usar essa integração sem escrever nenhum código específico para ela. O protocolo organiza a comunicação em três blocos: tools (ações que o modelo pode executar), resources (dados que o modelo pode ler) e prompts (modelos de instrução reutilizáveis), todos descritos em um formato que o próprio modelo interpreta em tempo de execução.

O problema que o MCP resolve

Antes do MCP, conectar um LLM a um sistema externo geralmente significava escrever uma integração sob medida: um plugin aqui, uma function calling customizada ali, um agente cercado de wrappers de API específicos. Cada aplicativo de IA tinha seu próprio jeito de expor ferramentas, e cada ferramenta precisava ser adaptada para cada aplicativo. Se uma empresa mantinha 5 ferramentas internas e queria que elas funcionassem em 3 assistentes diferentes, o resultado eram 15 integrações separadas para manter, cada uma com seu próprio esquema de autenticação e formato de request.

Esse é o clássico problema de "M vezes N": M ferramentas multiplicadas por N aplicativos geram M×N pontes de integração. O MCP achata essa equação para M+N. Cada ferramenta vira um servidor MCP, construído uma única vez; cada aplicativo vira um cliente MCP compatível, também construído uma única vez; e qualquer combinação entre os dois lados passa a funcionar sem trabalho extra. É basicamente o mesmo raciocínio por trás do Language Server Protocol, criado anos antes para que editores de código parassem de precisar implementar suporte nativo para cada linguagem de programação separadamente.

Arquitetura do protocolo

O MCP segue uma arquitetura cliente-servidor com três papéis bem definidos:

• Host: o aplicativo que o usuário final usa diretamente, como o Claude Desktop, uma IDE com IA embutida ou um agente próprio.
• Cliente MCP: um componente dentro do host que mantém uma conexão individual e isolada com um servidor MCP específico.
• Servidor MCP: um processo separado, local ou remoto, que expõe tools, resources e prompts sobre um sistema externo.

Um mesmo host pode manter vários clientes MCP ao mesmo tempo, cada um conectado a um servidor diferente: um para o sistema de arquivos, outro para o Slack, outro para um banco de dados Postgres. Essa regra de um cliente por servidor é proposital, porque garante isolamento. Uma falha ou travamento em um servidor não derruba a conexão com os outros.

O diagrama abaixo resume esse desenho:

A comunicação entre cliente e servidor acontece por dois transportes principais. Para servidores locais, o padrão é stdio, a entrada e saída padrão do processo, simples e rápido porque não exige rede. Para servidores remotos, o transporte é HTTP com Streamable HTTP, a evolução do antigo transporte baseado em Server-Sent Events, o que permite hospedar um servidor MCP na nuvem e atender vários clientes ao mesmo tempo.

O cliente MCP

O cliente vive dentro do host e cuida de três coisas: abrir e manter a conexão com um servidor, traduzir as decisões do modelo em mensagens JSON-RPC, e devolver as respostas do servidor de volta para o contexto da conversa. Na prática, o cliente também conduz o handshake inicial, a etapa de initialize em que cliente e servidor trocam informações de versão do protocolo e capacidades suportadas, além do processo de descoberta, no qual pergunta ao servidor quais tools, resources e prompts ele oferece.

Um detalhe pouco óbvio é que o cliente não decide sozinho quando usar uma ferramenta. Essa decisão é do modelo: o cliente entrega ao LLM a lista de tools disponíveis, formatada como parte do contexto da conversa, e é o próprio modelo que escolhe, com base no que o usuário pediu, se e qual ferramenta chamar. O cliente só executa a chamada técnica depois que o modelo já decidiu.

O servidor MCP

Do outro lado, o servidor é quem realmente sabe interagir com o sistema externo, seja ele um banco de dados, uma API de terceiros ou o sistema de arquivos local. Um servidor MCP bem construído expõe suas capacidades de forma autodescritiva: cada tool vem com um nome, uma descrição em linguagem natural e um schema, geralmente JSON Schema, que define quais parâmetros ela aceita.

Essa autodescrição é o que torna o MCP plugável. O servidor não precisa saber qual modelo vai consumi-lo, e o cliente não precisa de nenhum código específico para aquele servidor além de falar o protocolo. Hoje já existem centenas de servidores MCP publicados por empresas como GitHub, Stripe, Cloudflare e Sentry, além de um ecossistema grande de servidores comunitários para bancos de dados, ferramentas de produtividade e serviços internos.

As ferramentas (tools) do MCP

Tools são o tipo de capacidade mais usado no MCP: ações que o modelo pode executar e que normalmente têm efeito colateral ou retornam um resultado computado, como consultar uma previsão do tempo, criar um card no Trello ou rodar uma query SQL. O protocolo define mais dois tipos de capacidade que valem a pena conhecer:

• Resources: dados que o servidor expõe para leitura, como o conteúdo de um arquivo, uma linha de banco de dados ou o resultado de uma consulta. Diferente de tools, resources normalmente não têm efeito colateral, são apenas contexto que o host pode anexar à conversa.
• Prompts: templates de instrução reutilizáveis que o servidor disponibiliza, como um roteiro pronto para revisar um pull request ou resumir um ticket de suporte, que o usuário pode invocar diretamente.

Cada tool é descrita por um objeto com name, description e inputSchema. É essa descrição, escrita em linguagem natural mas estruturada, que permite ao modelo entender o que a ferramenta faz sem que ninguém precise programar regras explícitas de quando usá-la.

Fluxo completo de uma chamada MCP

Para entender como tudo isso se conecta na prática, vale seguir o ciclo de vida de uma chamada real, do jeito que ela trafega entre cliente e servidor via JSON-RPC 2.0.

Primeiro, na conexão, o cliente pergunta quais ferramentas o servidor oferece:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

O servidor responde com a lista completa, já incluindo o schema de cada ferramenta:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Retorna a previsão do tempo atual de uma cidade",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Esse catálogo é entregue ao modelo como parte do contexto disponível. Quando o usuário faz um pedido que o modelo interpreta como algo que exige a ferramenta get_weather, o cliente monta e envia uma chamada tools/call:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "São Paulo" }
  }
}

O servidor executa a lógica real por trás da ferramenta, nesse caso provavelmente uma chamada para uma API de clima de verdade, e devolve o resultado no mesmo formato JSON-RPC:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "23°C, céu limpo em São Paulo" }
    ]
  }
}

O cliente injeta esse resultado de volta na conversa, e o modelo usa a informação para formular a resposta final ao usuário. Do ponto de vista de quem está conversando com o assistente, tudo isso acontece de forma transparente: só se vê a pergunta e a resposta, sem saber que, nos bastidores, houve uma negociação inteira de protocolo.

MCP vs API tradicional

É comum surgir a dúvida: se toda ferramenta externa já tem uma API REST, por que não usar essa API diretamente? A resposta está na diferença entre integrar um sistema para um desenvolvedor humano ler a documentação e integrar um sistema para um modelo descobrir e usar sozinho, em tempo real.

Aspecto	API REST tradicional	MCP
Descoberta de capacidades	Documentação externa (Swagger/OpenAPI), lida por um humano	O cliente pergunta ao servidor em tempo real quais tools existem (tools/list)
Integração por sistema	Um conector dedicado para cada API	Um único protocolo padrão para qualquer servidor MCP
Formato de comunicação	HTTP + JSON, esquema varia por provedor	JSON-RPC 2.0 padronizado
Contexto para o modelo	O desenvolvedor decide manualmente o que expor ao LLM	O servidor descreve tools de um jeito que o próprio modelo decide o que usar
Transporte	Quase sempre HTTP	stdio (local) ou HTTP com Streamable HTTP (remoto)
Reuso entre apps de IA	Baixo, cada app reimplementa a integração	Alto, qualquer host compatível usa o mesmo servidor

Na prática, o MCP não substitui a API REST por trás do servidor, ele é uma camada de padronização em cima dela. Um servidor MCP para o GitHub, por exemplo, provavelmente chama a API REST do GitHub internamente. A diferença é que o modelo nunca precisa saber disso: ele só enxerga tools com nomes e schemas consistentes, não importa qual API está por trás.

Exemplo prático: um servidor MCP simples

Para tirar o protocolo do papel, um servidor MCP mínimo em Python, usando o SDK oficial com a classe FastMCP, cabe em poucas linhas:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("clima-server")
@mcp.tool()
def get_weather(city: str) -> str:
    """Retorna a previsão do tempo atual de uma cidade."""
    # a chamada real a uma API de clima entraria aqui
    return f"23°C, céu limpo em {city}"
if name == "main":
    mcp.run(transport="stdio")

Esse servidor expõe uma única tool chamada get_weather. O decorador @mcp.tool() já cuida de gerar o schema JSON a partir da assinatura da função e do docstring, então não é preciso escrever o JSON Schema na mão. Ao rodar esse script, ele fica escutando via stdio, pronto para qualquer cliente MCP, como o Claude Desktop configurado localmente, se conectar e descobrir a ferramenta automaticamente.

Esse exemplo é propositalmente simples, mas o mesmo padrão vale para servidores mais complexos: a lógica de negócio (consultar um banco, chamar uma API paga, disparar uma automação) entra no corpo da função, e o SDK cuida de toda a parte de protocolo, handshake e serialização.

Segurança no MCP

Dar a um modelo de linguagem acesso direto a ferramentas que leem arquivos, escrevem em bancos de dados ou chamam APIs de terceiros levanta uma pergunta óbvia: quem garante que isso não sai do controle? O protocolo define algumas salvaguardas, mas a responsabilidade final é dividida entre servidor, cliente e quem configura o sistema.

No nível do servidor, a boa prática é aplicar o princípio do menor privilégio: um servidor MCP para o sistema de arquivos, por exemplo, deve restringir o acesso a diretórios específicos, nunca ao disco inteiro. Servidores remotos que usam transporte HTTP normalmente exigem autenticação via OAuth 2.1, e a especificação do protocolo trata isso com bastante detalhe, justamente porque servidores mal configurados são o vetor de ataque mais óbvio.

No nível do cliente e do host, a camada de segurança mais visível para o usuário final é o consentimento humano: hosts como o Claude Desktop pedem confirmação antes de executar tools sensíveis, como escrever um arquivo ou enviar uma mensagem, especialmente na primeira vez que uma ferramenta é usada. Também existe o risco de prompt injection via resources, quando um conteúdo malicioso embutido em um documento que o modelo lê tenta manipular o próprio modelo a executar uma ação indevida. Servidores que expõem conteúdo de fontes não confiáveis, como páginas web ou e-mails recebidos, merecem atenção redobrada tanto de quem constrói o servidor quanto de quem decide conectá-lo a um agente com permissões amplas.

Limitações do MCP

O MCP resolve o problema de padronização, mas não é uma solução mágica para tudo. Vale conhecer os limites reais antes de decidir construir em cima dele.

Primeiro, o protocolo ainda é relativamente novo, lançado no fim de 2024, e o ecossistema, embora cresça rápido, ainda tem lacunas: nem toda ferramenta popular já tem um servidor MCP maduro e mantido oficialmente. Segundo, mais tools disponíveis ao mesmo tempo significam mais tokens gastos descrevendo essas tools no contexto da conversa, o que pode encarecer chamadas e, em casos extremos, disputar espaço de contexto com o restante da conversa. Terceiro, o protocolo não resolve sozinho o problema de confiabilidade do modelo: ele ainda pode escolher a tool errada, montar argumentos incorretos ou interpretar mal um resultado retornado pelo servidor, então a orquestração cuidadosa continua sendo trabalho de quem constrói o agente.

Por fim, a autenticação e a governança de acesso em ambientes corporativos, ou seja, quem pode conectar qual servidor, com quais permissões, auditado de que forma, ainda é um espaço em amadurecimento, com bastante trabalho acontecendo na comunidade e nas empresas que adotam o protocolo em produção.

FAQ

O MCP é exclusivo da Anthropic e do Claude?

Não. O MCP é um protocolo aberto, com especificação pública, e outras empresas de IA e frameworks de agentes já anunciaram suporte a ele, embora tenha nascido dentro da Anthropic.

Preciso saber programar para usar um servidor MCP?

Para usar um servidor já pronto, como o de acesso a arquivos ou ao Google Drive, dentro de um app como o Claude Desktop, não. Programar é necessário só para quem quer construir um servidor novo do zero.

MCP substitui function calling?

Não exatamente. Function calling é a capacidade do modelo de escolher e formatar uma chamada de ferramenta. O MCP usa essa capacidade por baixo, mas adiciona a camada de descoberta, padronização e transporte entre cliente e servidor que o function calling isolado não define.

Um servidor MCP pode rodar na nuvem?

Sim. Servidores remotos usam transporte HTTP e podem ser hospedados normalmente, atendendo vários clientes ao mesmo tempo, com autenticação via OAuth.

O ganho real do MCP não é técnico no sentido de "mais uma API", é organizacional: ele transforma um problema que crescia de forma multiplicativa, cada ferramenta para cada aplicativo, em um problema que cresce de forma aditiva. Para quem constrói agentes de IA hoje, entender esse protocolo deixou de ser opcional. Ele já é a peça de infraestrutura mais próxima de um padrão de fato para conectar modelos a tudo que existe fora do próprio modelo.