04Capítulo 4: MCP: a tomada padrão

O MCP (Model Context Protocol) é um protocolo aberto para conectar ferramentas e dados a aplicativos de IA. A Anthropic publicou a primeira versão no fim de 2024 e hoje ele funciona nos principais apps: Claude, ChatGPT, VS Code, Cursor e vários outros.

A comparação que todo mundo usa é a do USB-C: em vez de um cabo para cada aparelho, uma tomada padrão. Alguém escreve um servidor MCP para o GitHub uma vez, e ele funciona em qualquer app que fale MCP. Era exatamente o problema do fim do capítulo 3.

As três peças

• Host. O aplicativo que você usa: Claude Code, Claude Desktop, VS Code, Cursor. Ele tem o modelo e decide o que mostrar e o que permitir.
• Cliente. A conexão que o host abre com cada servidor. Um cliente por servidor, sempre dentro do host.
• Servidor. O programa que oferece as capacidades. Pode rodar na sua máquina ou na internet.

O que um servidor oferece

Um servidor pode expor três tipos de coisa:

• Tools (ferramentas). Ações que o modelo pode pedir: criar_issue, rodar_consulta, abrir_pagina. É de longe o mais usado, e funciona do jeito que você viu no capítulo 3.
• Resources (recursos). Dados para leitura, cada um com um endereço (URI): um arquivo, um registro, um documento. O app decide quando colocar no contexto.
• Prompts. Modelos de pedido prontos, que você chama pelo app, muitas vezes como um comando de barra.

No sentido contrário, a versão atual da especificação mantém a elicitation: o servidor pode pedir uma informação a você no meio de uma tarefa, como uma confirmação ou um dado que faltou. Recursos mais antigos desse lado, como sampling e roots, estão marcados como obsoletos.

Como eles conversam

As mensagens seguem o JSON-RPC 2.0: objetos JSON com method, params e um id que casa cada pedido com a sua resposta. Elas viajam por um de dois transportes:

• stdio. O host inicia o servidor como um processo na sua máquina e troca mensagens pela entrada e saída padrão, uma por linha. É o caso de npx algum-servidor, que você vai ver muito no próximo capítulo.
• Streamable HTTP. O servidor roda num endereço e recebe cada mensagem como um POST. Serve para servidores remotos e costuma usar OAuth para login. O transporte antigo, HTTP com SSE, está obsoleto.

Role o texto abaixo e acompanhe no diagrama. O exemplo é um servidor de observabilidade, inventado, com uma ferramenta buscar_logs. As mensagens estão simplificadas: os campos de versão e de metadados foram omitidos.

{ "jsonrpc": "2.0", "id": 1, "method": "server/discover" }

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

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "buscar_logs",
        "description": "Busca logs de um serviço num período",
        "inputSchema": {
          "type": "object",
          "properties": {
            "servico": { "type": "string" },
            "desde": { "type": "string" }
          },
          "required": ["servico"]
        }
      }
    ]
  }
}

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "buscar_logs",
    "arguments": { "servico": "api", "desde": "15m" }
  }
}

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      { "type": "text", "text": "12:04:11 ERROR conexão recusada em db:5432 (x214)" }
    ]
  }
}

O que isso significa na prática

Você quase nunca vai escrever essas mensagens. Quem conversa é o host, e quem implementa o servidor usa um SDK. O que você precisa saber é:

• Instalar um servidor é dizer ao host como iniciá-lo (stdio) ou onde ele está (HTTP). É só isso que vai no arquivo de configuração.
• As descrições das ferramentas entram no seu contexto. Cada servidor instalado custa tokens em toda conversa.
• Um servidor local roda com as suas permissões. Ele pode ler o que você lê e apagar o que você apaga.

No próximo capítulo você instala o primeiro.