O que é MCP (Modelo de Protocolo de Contexto)? Guia Completo de 2026

TL;DR — O Modelo de Protocolo de Contexto (MCP) é uma especificação JSON-RPC 2.0 aberta, introduzida pela Anthropic no final de 2024, que permite que agentes de IA se comuniquem com sistemas externos — sistemas de arquivos, bancos de dados, APIs, serviços personalizados — através de uma única interface padronizada. Um servidor MCP expõe capacidades (ferramentas, recursos e prompts); um cliente MCP (Claude Desktop, Cursor, Zed, Sourcegraph Cody, seu próprio agente) as consome. Escreva o servidor uma vez, e cada cliente compatível com MCP pode usá-lo — sem trabalho de integração por aplicativo.

Se você já construiu ferramentas de agente antes, pense no MCP como "LSP para ferramentas de IA": a mesma ideia que unificou servidores de linguagem entre editores, agora aplicada à infraestrutura entre agentes e os sistemas nos quais eles precisam atuar.

Por que o MCP Existe

Antes do MCP, cada estrutura de agente definia seu próprio formato de ferramenta. Uma ferramenta escrita para LangChain não funcionava no Claude Desktop, que não funcionava no seu agente personalizado, que não funcionava no Cursor. Cada integração era sob medida, cada "descrição de função" projetada era específica da estrutura, e cada equipe reconstruía a mesma roda.

Os pontos problemáticos que o MCP resolve:

• Fragmentação. Cinco estruturas, cinco formatos de ferramenta. Cinco vezes o trabalho.
• Sem descoberta. Os clientes não podiam enumerar o que um servidor de ferramentas oferecia sem um manifesto codificado.
• Sem portabilidade. Um assistente de depuração que você escreveu para um agente não se moveria para outro.
• A autenticação era ad hoc. Cada integração inventava sua própria maneira de lidar com chaves de API e OAuth.

O MCP torna o contrato uniforme: um servidor declara suas ferramentas, recursos e prompts; um cliente fala o mesmo dialeto JSON-RPC para descobri-los e chamá-los. O mesmo servidor MCP que é enviado com o SDK TypeScript da Anthropic hoje funcionará com qualquer cliente futuro que implemente a especificação, independentemente de qual LLM o cliente use por baixo.

O Protocolo de Comunicação em Uma Página

O MCP utiliza JSON-RPC 2.0, o que significa que cada mensagem é um objeto JSON com um envelope jsonrpc: "2.0", um método, params opcionais, e um id para solicitações que esperam uma resposta.

Existem dois transportes suportados:

1. stdio. O cliente inicia o servidor como um subprocesso e eles se comunicam via stdin/stdout. É assim que o Claude Desktop e o Cursor se comunicam com servidores MCP locais configurados em seu mcp.json ou claude_desktop_config.json.
2. HTTP + SSE (Eventos Enviados pelo Servidor). Acessível pela rede. O cliente envia solicitações JSON-RPC para um único endpoint, e o servidor pode transmitir notificações de volta através de Eventos Enviados pelo Servidor. Este é o transporte que ferramentas de navegador — incluindo o AllDevToolsHub MCP Server Tester — podem acessar diretamente.

Uma sessão normal se parece com isto:

1. initialize — o cliente envia sua versão de protocolo e capacidades; o servidor responde com sua versão e capacidades.
2. notifications/initialized — o cliente confirma que está pronto.
3. Descoberta e invocação — tools/list, tools/call, resources/list, resources/read, prompts/list, prompts/get, além de pings e notificações.
4. Conexão encerrada — qualquer uma das partes encerra a conexão.

O protocolo é simétrico. Os servidores também podem enviar solicitações ao cliente — por exemplo, pedindo ao modelo por conclusões em nome do servidor (o recurso de "amostragem") — embora esse seja um padrão avançado que a maioria dos servidores não utiliza.

A Tríade Ferramentas / Recursos / Prompts

Quase toda capacidade que um servidor MCP expõe se enquadra em um de três grupos. Compreender qual é qual é a maior chave para construir servidores que pareçam naturais de usar.

1. Ferramentas — a superfície de chamada de função

Ferramentas são funções que o modelo invoca com argumentos. Mesma estrutura que o uso de ferramentas do Claude ou a chamada de função da OpenAI — nome, descrição, entrada de JSON Schema:

{
  "name": "get_weather",
  "description": "Obter o clima atual para uma cidade.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "Nome da cidade" }
    },
    "required": ["city"]
  }
}

O modelo lê a descrição, decide quando chamar, e o cliente despacha tools/call com os argumentos escolhidos. O servidor executa a ferramenta e retorna blocos de conteúdo.

Erros comuns:

• Descrições vagas. "Obter dados" — o modelo não consegue dizer quais dados, ou quando. Seja específico: "Retorna o clima atual (temperatura, condições) para uma cidade nomeada. Use quando o usuário perguntar sobre o clima."
• Falta de required. Sem isso, os modelos podem chamar sem argumentos e se confundir.
• Formato de resposta errado. As ferramentas devem retornar { content: [{ type: "text", text: "..." }] } ou outros blocos de conteúdo tipados. Retornar uma string simples viola a especificação, e clientes rigorosos a rejeitam.

2. Recursos — a superfície de contexto somente leitura

Recursos são pedaços de dados que o modelo pode puxar para o contexto — arquivos, linhas de banco de dados, respostas de API. Eles são identificados por URI:

{
  "uri": "file:///path/to/log.txt",
  "name": "Log recente",
  "description": "Últimas 24 horas de logs da aplicação.",
  "mimeType":