O que é MCP? Model Context Protocol, JSON-RPC, agentes de IA e chamadas de ferramentas

De cara: MCP (Model Context Protocol) não é outro nome para Function Calling, e não é um modelo. É um protocolo aberto entre um app de IA (o Host) e processos de ferramentas externas (MCP Servers). As mensagens são JSON-RPC 2.0. O modelo continua falando o Tool Calling / Function Calling de cada fornecedor. O Host traduz tools/list no array tools do modelo e depois traduz tool_calls em tools/call. Essas três camadas juntas são o jeito em que a maioria dos agentes de 2026 chama ferramentas.

Este artigo está datado de 7 de setembro de 2026. A spec atual é 2026-07-28: sem sessão de protocolo, sem handshake de initialize, cada requisição carrega _meta, e a descoberta de capacidades usa server/discover. O texto de agosto fluxo de dados JSON do Agent ainda mostra o exemplo antigo de initialize; trate este guia como a leitura vigente. Para «preciso mudar o código do Server?», veja o guia de migração MCP 2026.

O que é o MCP

Model Context Protocol é um padrão aberto para como aplicações de IA descobrem, leem e invocam contexto externo. A Anthropic lançou em novembro de 2024; a governança depois foi para a Agentic AI Foundation. Ele especifica como o contexto é trocado. Não especifica qual modelo você usa, como orquestra um agent de vários passos, nem como escreve a lógica de negócio.

Pense no USB-C: o soquete é padrão; se o que entra é disco, tela ou fonte de energia, fica fora do escopo. O MCP padroniza o soquete Host ↔ Server. Um filesystem, GitHub, uma API interna de pedidos ou um validador JSON como este site são só Servers.

Duas camadas: a camada de dados é JSON-RPC 2.0 (métodos, params, códigos de erro, notificações); a camada de transporte é como esses frames JSON se movem — stdio na mesma máquina, Streamable HTTP à distância. Troque o transporte e a forma da mensagem permanece. Por isso o debug de MCP começa separando «o envelope é JSON-RPC; o payload de negócio muitas vezes também é JSON».

Host, Client, Server

O triângulo da spec é fácil de misturar com o «cliente / servidor» do dia a dia:

• Host: o app de IA que o usuário abriu. Ele cria Clients, alimenta schemas de ferramentas no modelo, autoriza e valida antes da execução, e escreve os resultados de volta na conversa.
• Client: um objeto de conexão dentro do Host. Um Server, um Client. VS Code falando com um filesystem e com o Sentry são dois Clients em runtime.
• Server: o programa que serve contexto. Pode compartilhar a máquina com o Host (stdio) ou rodar em outro lugar (Streamable HTTP). «Server» é um papel, não uma exigência de hostname público.

O modelo não está nesse triângulo. GPT-5.5, Claude 4.8 e Gemini 3.7 veem o array tools traduzido pelo Host. Não veem JSON-RPC, e não veem Mcp-Session-Id (o header de sessão sumiu em 2026-07-28). «O modelo fala MCP» é marketing. Na engenharia, sempre há um Host no meio.

Como ler JSON-RPC 2.0

JSON-RPC é uma convenção para chamadas de procedimento remoto usando JSON — mais perto de «chamar uma função» do que de REST. O MCP escolheu isso porque os nomes de método ficam estáveis (tools/list, tools/call), a divisão requisição / resposta / notificação é limpa, e o envelope inteiro é JSON amigável ao modelo.

Um tools/call na spec 2026-07-28 é assim. Note: sem handshake, sem header de sessão. Versão e identidade do cliente moram em _meta, então qualquer instância de Server consegue tratar o frame.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "validate_json",
    "arguments": {
      "payload": {"orderId": "A-1001", "total": 42.5},
      "schemaId": "order.v1"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "json-toolbox-host",
        "version": "1.0.0"
      }
    }
  }
}

Uma resposta de sucesso é o mesmo envelope. O resultado de negócio fica em result.content, muitas vezes type: "text", e esse texto pode ser ele mesmo uma string JSON — protocolo do lado de fora, payload do lado de dentro. No debug, primeiro veja se o id casa com a requisição; depois valide o objeto interno contra o Schema.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "{\"valid\":true,\"schemaId\":\"order.v1\"}"
      }
    ]
  }
}

Falhas usam o objeto error do JSON-RPC: code, message, data opcional. 2026-07-28 mudou «recurso não encontrado» do -32002 específico do MCP para o padrão -32602 (Invalid Params). Clients que casam o literal antigo vão perder o caso. Notificações não têm id e não esperam resposta — por exemplo, uma mudança na lista de tools.

Tools, Resources, Prompts

Um Server pode expor três primitivas. Agentes vivem em Tools; as outras duas são fáceis de pular e muitas vezes poupam uma rodada de chute do modelo.

Uma ferramenta é name, description e inputSchema. inputSchema é JSON Schema (2020-12 a partir de 2026-07-28; a raiz ainda precisa ser type: "object"; oneOf / $ref / $defs são permitidos). O outputSchema opcional restringe a forma do retorno. Hosts copiam quase 1:1 o inputSchema para parameters / input_schema da API do modelo.

{
  "name": "validate_json",
  "title": "Validate JSON",
  "description": "Check a JSON payload against a named schema. Returns valid and errors.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "payload": { "type": "object", "description": "Already parsed JSON object, not a raw string" },
      "schemaId": { "type": "string", "description": "Stable schema id such as order.v1" }
    },
    "required": ["payload", "schemaId"]
  }
}

Resources cabem em «leia, depois pense»: carregar schema://order.v1 é mais barato do que fazer o modelo decorar um Schema de 200 linhas na conversa. Prompts cabem nas aberturas prontas da equipe. Roots, Sampling e Logging estão deprecados em 2026-07-28: passe caminhos de workspace como argumentos de ferramenta ou URIs de resource; Servers não devem pedir um completion ao Host; logs vão para stderr ou OpenTelemetry.

Como se empilha com Tool Calling

Três nomes viram uma coisa só. Não são a mesma camada — o artigo de fluxo de dados JSON do Agent rastreia cada salto. Aqui, só o mapeamento:

Function Calling é o nome antigo da OpenAI; Tool Calling é o termo genérico posterior (Claude tools, Gemini Function Calling, OpenAI Tools API). Para quem desenvolve, é um fluxo só: o Host manda um Schema, o modelo devolve uma chamada com argumentos JSON, o Host executa e enfia um resultado JSON de volta na conversa.

O MCP não substitui essa camada. Um Host que chama funções no mesmo processo só com Tool Calling continua válido. O MCP torna as ferramentas descobráveis, entre processos e reutilizáveis entre Hosts. Agentes corporativos quase sempre empilham as duas; scripts e demos muitas vezes pulam o MCP.

Duas armadilhas de mapeamento: APIs de modelo muitas vezes entregam arguments como string; params.arguments do MCP é um object. E o name de tools/list precisa chegar ao modelo e ao tools/call sem mudança — não invente um alias «mais amigável» no meio. Valide antes do tools/call de verdade; veja Tool Calling e validação com JSON Schema.

Uma chamada de ferramenta completa

O usuário diz: «Valide este JSON de pedido com order.v1.» Em 2026-07-28, o caminho é:

1. Host → Server: server/discover (cacheável) para confirmar tools; ou mande a próxima requisição e tente de novo se a versão falhar.
2. Host → Server: tools/list devolve itens com inputSchema; o resultado pode trazer ttlMs / cacheScope.
3. Host → modelo: mapeie a lista para tools[].parameters (ainda JSON Schema).
4. Modelo → Host: tool_calls com name validate_json; arguments costuma ser JSON stringificado.
5. Host valida: JSON.parse, depois cheque inputSchema. Se falhar, escreva o erro como resultado de tool — não toque no Server de verdade.
6. Host → Server: tools/call com arguments objeto e versão de protocolo em _meta.
7. Server → Host: result.content; o Host pode checar outputSchema de novo.
8. Host → modelo: uma string JSON role: tool; o modelo responde ao usuário ou começa outra rodada de ferramenta.

Linguagem natural do usuário
    │
    ▼
Host ──JSON Schema──► LLM Tool Calling
    │                      │
    │                      ▼
    │                 arguments JSON
    ▼                      │
MCP JSON-RPC ◄──── tools/call só depois da validação
    │
    ▼
result JSON ──► tool message ──► resposta final do modelo

No transporte remoto, os headers HTTP precisam incluir MCP-Protocol-Version, Mcp-Method e Mcp-Name, e precisam bater com o body ou o Server deve recusar. Load balancers podem rotear pelos headers sem parsear JSON. stdio local não tem esses headers; os nomes de método JSON-RPC são os mesmos.

O que lembrar de 2026-07-28

A spec de julho é a maior revisão desde o lançamento, e 28 de julho de 2026 é a data de publicação final. Para «o que é MCP», fique com a lista abaixo. Se o seu Server precisa de mudanças de código, continua sendo a árvore de decisão do artigo de migração.

• Sem handshake, sem sessão de protocolo: initialize / initialized e Mcp-Session-Id sumiram. Cada requisição é autocontida. Encadeie estado de aplicação com um basket_id explícito (ou similar) como argumento normal. Não espere que o transporte lembre de você.
• A descoberta é server/discover: opcional, mas uma chamada devolve versões suportadas, capabilities e serverInfo. Resultados de lista trazem ttlMs; um stream SSE longo já não é o único jeito de saber que as tools mudaram.
• Schemas são JSON Schema 2020-12: a raiz de entrada continua object; composição e refs são permitidos; não resolva automaticamente $ref externos. Schemas de saída já não são só object.
• Roots / Sampling / Logging estão deprecados: os métodos ainda funcionam na janela de um ano. Servers novos não devem implementar Sampling para pedir um completion ao Host.
• Extensions: Tasks e MCP Apps são extensões oficiais, não obrigações do core. Trabalho longo usa um task handle + tasks/get. Não invente a sua própria sessão.

Hosts e Servers ainda em 2025-11-25 continuam usando initialize. Quando as versões se misturam, use o protocolVersion negociado. Não mande os frames sem sessão deste artigo para um Server antigo. Para o que instalar, veja rankings de MCP Server 2026.

O que fazer agora

1. Desenhe três camadas antes de escrever código: Tool Calling da API do modelo, orquestração do Host, MCP Server. Scripts podem parar nas duas primeiras. Reuso entre IDEs é quando você escreve um Server.
2. Use um SDK oficial; não escreva frames JSON-RPC na mão: @modelcontextprotocol/sdk e os outros pacotes oficiais já tratam descoberta, transporte e códigos de erro. SSE escrito à mão ou campos privados são o caso clássico de «você precisa mudar código» no guia de migração.
3. Escreva inputSchema como um contrato que você valida sozinho: additionalProperties: false, required, enums, tetos de comprimento. Modelos omitem campos e stringificam números. Bloqueie uma vez com o mesmo Schema antes de executar.
4. stdio no local, Streamable HTTP à distância: debug pessoal não precisa de HTTP. Acesso compartilhado da equipe, muitos Clients ou um gateway é quando você vai remoto — mais OAuth e privilégio mínimo.
5. Cacheie listas, recorte resultados: respeite ttlMs. Não despeje stacks crus de volta no modelo. Janela maior não torna JSON sujo seguro — veja janelas de contexto de 1M tokens.
6. Confira fixtures no navegador antes de bater num Server ao vivo: salve inputSchema, arguments bons / ruins e retornos de exemplo do Server como JSON; valide e faça Diff neste site. Nada é enviado. O mesmo hábito de testar um contrato REST.

FAQ

Conclusão

MCP é o soquete de ferramentas do agent em 2026: JSON-RPC 2.0 transporta descoberta e invocação entre Host e Server; do lado do modelo continua sendo Tool Calling; JSON Schema é o contrato compartilhado. Não é um modelo, não é um framework e não substitui o OpenAPI. A spec 2026-07-28 tirou sessões do protocolo, então as requisições precisam ser autocontidas. As três primitivas — Tools, Resources, Prompts — não mudaram.

Este guia é só o empilhamento. A forma dos bytes em cada salto está no artigo de fluxo de dados; se um Server antigo precisa mudar código está no artigo de migração; quais Servers instalar está no artigo de ranking. Antes de ligar qualquer coisa ao vivo, valide o Schema e o JSON de exemplo no local — você pode trocar o modelo; nomes de campo e required não deveriam se mover.