MCP explicado: o protocolo que conecta seu agente de IA às ferramentas

MCP é a sigla de Model Context Protocol, um protocolo aberto que padroniza como um modelo de IA conversa com ferramentas e fontes de dados externas. A Anthropic anunciou o protocolo em novembro de 2024, e hoje ele aparece em Claude, ChatGPT, Cursor, VS Code, Zed e Replit.

O problema que o MCP resolve tem nome: integração M por N. Se você tem 5 aplicações de IA e 20 ferramentas para conectar, o mundo antes do protocolo pedia 100 integrações diferentes, cada uma com seu formato de autenticação e seu jeito de descrever o que a ferramenta faz. Com um protocolo comum, são 5 clientes e 20 servidores.

Os três papéis

A arquitetura tem três peças, e confundir elas atrapalha a leitura de qualquer documentação.

O host é a aplicação onde o modelo roda: o app do Claude, o Cursor, seu próprio produto.

O client é o componente dentro do host que fala o protocolo. Um client por conexão com servidor.

O server é quem expõe as capacidades: ler um arquivo, consultar um banco, criar uma tarefa no gerenciador de projetos. Pode rodar como processo local na sua máquina ou como serviço remoto atrás de HTTPS.

Toda a comunicação é JSON-RPC 2.0. Requisição, resposta e notificação em JSON, e nada mais que isso.

As primitivas do servidor

O servidor expõe três tipos de coisa, e a diferença entre elas é quem decide usar.

A maioria das integrações que você vê por aí usa só tools. Resources fazem sentido quando o dado é grande e você quer que a aplicação escolha o que entra no contexto, em vez de deixar o modelo pedir tudo.

Do lado do cliente existem outras três primitivas: sampling (o servidor pede uma geração ao modelo do host), roots (o cliente informa quais diretórios ou escopos estão disponíveis) e elicitation (o servidor pede uma informação ao usuário no meio de uma operação).

Os dois transportes

O Streamable HTTP entrou na revisão de março de 2025 e substituiu o transporte HTTP+SSE original. Em stdio existe uma regra que quebra muita implementação nova: o servidor não pode escrever nada no stdout que não seja mensagem MCP válida. Um console.log de depuração perdido no código derruba a conexão. Log vai para stderr.

Como isso aparece na prática

Conectar um servidor local a um host costuma ser um bloco de configuração assim:

{
  "mcpServers": {
    "meu-banco": {
      "command": "node",
      "args": ["/caminho/servidor-mcp/index.js"],
      "env": {
        "DATABASE_URL": "postgres://..."
      }
    }
  }
}

O host sobe esse processo, pergunta quais capacidades ele tem e passa a lista de ferramentas para o modelo junto do resto do contexto. Cada ferramenta chega ao modelo com nome, descrição e um schema de entrada:

{
  "name": "buscar_pedido",
  "description": "Busca um pedido pelo número. Use quando o usuário citar um número de pedido explícito.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "numero": { "type": "string", "description": "Número do pedido, formato PED-0000" }
    },
    "required": ["numero"]
  }
}

Essa descrição é a documentação que o modelo lê para decidir. Descrição vaga gera ferramenta chamada na hora errada, e isso não se conserta com mais instrução no system prompt.

A linha do tempo das revisões

O MCP usa versionamento por data, e a data marca a última mudança incompatível.

A negociação de versão existe justamente para implementações antigas e novas continuarem conversando. Antes de seguir tutorial encontrado por aí, confira de qual revisão ele fala.

MCP não substitui function calling

Function calling é o mecanismo do modelo para pedir a execução de uma função. MCP é o protocolo que padroniza como essas funções são descobertas, descritas e executadas por processos externos.

Se o seu agente chama duas funções que vivem no mesmo código do app, function calling direto resolve e MCP só adiciona camada. O protocolo compensa quando alguma destas condições aparece:

A mesma capacidade precisa ser usada por mais de um host, por exemplo pelo seu produto e pelo Claude no seu computador.

Quem mantém a ferramenta não é quem mantém o app, e um contrato estável entre os dois evita quebra a cada deploy.

Você quer aproveitar servidores prontos de terceiros em vez de escrever integração para cada API.

Erros comuns em servidor MCP próprio

Por onde começar

Instale um servidor pronto antes de escrever o seu. Conectar um servidor de sistema de arquivos ou de banco no app do Claude leva poucos minutos e mostra o ciclo completo: o host lista as ferramentas, o modelo escolhe uma, o servidor executa, o resultado volta para a conversa.

Depois disso, o servidor próprio vira uma questão de escrever três ou quatro ferramentas com descrição honesta e schema apertado. A parte difícil não é o protocolo. É decidir o que o modelo tem permissão de fazer no seu sistema.