Por que agentes de IA não vivem sem JSON: fluxo de dados do Tool Calling ao MCP

Cada salto JSON de uma chamada Agent: Schema de ferramentas, Function Calling / Tool Calling, MCP JSON-RPC e o retorno das falhas de validação.

Nosso artigo anteriorPor que Agents de IA usam JSON Schema, Function Calling e MCPexplicadopor que essas três camadas existem. Esta peça observa obytes que realmente se movemem uma chamada real — quase todas elas JSON.

Os usuários veem a linguagem natural. Os Agents realizam o trabalho codificando a intenção como parâmetros JSON, codificando os resultados da ferramenta como mensagens JSON e codificando o protocolo de processo cruzado como JSON-RPC. JSON não é decoração; é a única linguagem mutuamente validável entre o modelo, o host e os servidores MCP.

Três nomes, uma carga útil JSON

Os documentos misturam três termos. Eles ficam em camadas diferentes, mas o formato da carga útil é quase o mesmo:

NomeEntreTrabalho de JSON
Chamada de funçãoModelo API ↔ hostdefinição de ferramentas + tool_calls.arguments
Chamada de ferramentaMesmo (nome genérico)As mesmas mensagens/ferramentas JSON
MCPHost ↔ processo da ferramentaMétodos JSON-RPC + inputSchema

One sentence: the model side uses JSON to pick a tool and fill parameters; the MCP side uses JSON to discover and execute tools. The host is the translator: MCP tools/list becomes the model tools array; model tool_calls become tools/call.

Por que tem que ser JSON

Um Agente deve satisfazer três partes ao mesmo tempo:

  • O modelo: os dados de treinamento estão cheios de JSON; emitir um objeto válido é muito mais fácil do que bytes protobuf
  • O programa: análise madura, validação de esquema, Diff e ferramentas JSONPath
  • O protocolo: OpenAPI, JSON-RPC e MCP inputSchema já compartilham uma descrição de tipo

A linguagem simples não pode falhar rapidamente: colchetes, aspas e linguagens mistas quebram os analisadores de regex. YAML é frágil em termos de recuo. Os protocolos binários são hostis tanto para humanos quanto para LLMs. JSON se torna o formato de ligação padrão que é auditável, validável e versável - é por isso que todas as ferramentas deste site giram em torno de JSON: você está depurando essa ligação.

Hop 1: Esquema na definição da ferramenta

The flow starts by telling the model which tools exist. Whether you use OpenAI-style tools or MCP tools/list, the core is a JSON Schema (or a subset):

{
  "name": "get_weather",
  "description": "Look up current weather for a city, read-only",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "City name, e.g. Shanghai" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["city"]
  }
}

In MCP the same constraint lives in inputSchema. Schema feeds two paths: the validator rejects illegal parameters; model context uses description to decide when to call. The more the field text reads like a product spec, the fewer mistaken calls.

Hop 2: Chamada de Função / Chamada de Ferramenta

Depois que o host envia a lista de ferramentas com mensagens, o modelonão executa código. Ele retorna uma chamada estruturada. Formato típico (os nomes dos campos variam de acordo com o fornecedor):

{
  "role": "assistant",
  "tool_calls": [
    {
      "id": "call_01",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\":\"Shanghai\",\"unit\":\"celsius\"}"
      }
    }
  ]
}

Note that arguments is often a stringified JSON object: JSON.parse first, validate against Schema, then execute. Results flow back as a tool-role message:

{
  "role": "tool",
  "tool_call_id": "call_01",
  "content": "{\"city\":\"Shanghai\",\"temp_c\":31,\"condition\":\"sunny\"}"
}

This hop is how the model reaches out. With parallel tools, the array holds multiple tool_calls; the host may run them concurrently and match results by id.

Salto 3: MCP JSON-RPC

Se a ferramenta não estiver no processo host, mas em um servidor MCP (sistema de arquivos, GitHub, ordens internas), o host e o servidor falam JSON-RPC 2.0. Uma consulta somente leitura consiste em aproximadamente três etapas:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"host","version":"1.0"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"get_weather","arguments":{"city":"Shanghai"}}}

A successful Server response is JSON too: content often has type: "text" whose text is another JSON string. That is JSON wrapping JSON — outer envelope vs inner business payload. When debugging MCP, split those layers, then Schema-validate the inner one.

O transporte pode ser stdio ou Streamable HTTP;a carga útil ainda é linhas JSON ou um corpo JSON. Para transporte de 2026 e se o código do servidor deve ser alterado, consulte oMCP Guia de migração 2026.

Rastreamento ponta a ponta de uma chamada

O usuário pergunta: “Quão quente está em Xangai hoje?” De ponta a ponta:

  1. Host → MCP Server: tools/list returns tools with inputSchema (JSON)
  2. Host → model API: mapped to tools[].parameters (still JSON Schema)
  3. Model → Host: tool_calls with arguments {"city":"Shanghai"}
  4. Host valida:contra o esquema; campos ausentes ou tipos errados recusam execução e erro de feed JSON de volta ao modelo
  5. Host → MCP: tools/call with params.arguments as an object (not a string)
  6. MCP → Host:resultado do clima JSON
  7. Host → model: role: tool content string
  8. Modelo → usuário:linguagem natural; se um sistema downstream deseja apenas estrutura, restrinja o JSON final com um esquema de saída
User natural language
    │
    ▼
Host orchestration ──JSON Schema──► LLM Tool Calling
    │                                  │
    │                                  ▼
    │                             arguments JSON
    │                                  │
    ▼                                  ▼
MCP JSON-RPC ◄──────────── validate, then execute
    │
    ▼
Result JSON ──► tool message ──► model final reply

Um pequeno script pode pular MCP e chamar funções locais no host. Os agentes corporativos quase sempre empilham Tool Calling + MCP. Para escolhas de ecossistema, consulteClassificações do servidor MCP 2026.

Como as falhas de validação retornam

JSON pode atuar como o sistema de tipos do Agent porque as falhas também podem ser estruturadas. Use pelo menos dois portões:

PortãoO que você validaComo o fracasso retorna
Antes de executarModelo argumentosNão chame a ferramenta real; escreva erros de esquema como resultado da ferramenta ou dica do sistema para que o modelo seja recarregado
Antes de escrever de voltaMCP / retorno de funçãoTruncar, redigir ou marcar erros; não jogue pilhas brutas no próximo turno

No desenvolvimento, mantenha o Schema mais duas ou três cargas válidas/inválidas no git e valide-as localmente em JSON Toolbox — a mesma ideia dos testes de contrato REST, exceto que o consumidor é um modelo.

Perguntas frequentes

Tool Calling e Function Calling são a mesma coisa?

Para os desenvolvedores, eles são quase o mesmo fluxo de dados: o host envia o esquema da ferramenta para o modelo, o modelo retorna uma chamada com JSON arguments, o host executa e grava os resultados JSON de volta. Function Calling era o nome inicial do OpenAI; Tool Calling / Tools API é o nome genérico posterior.

Por que as mensagens MCP também são JSON?

MCP é JSON-RPC 2.0: solicitações e respostas initialize, tools/list e tools/call são objetos JSON. O inputSchema de cada ferramenta é JSON Schema, então um Host pode mapear ferramentas MCP um a um no array de ferramentas API do modelo.

Os argumentos do modelo são uma string ou um objeto?

A maioria das APIs do estilo Chat Completions colocam arguments em uma string JSON; o host deve JSON.parse e então validar no esquema. Algumas APIs mais recentes retornam um objeto. De qualquer forma, valide com o mesmo esquema antes da execução.

Por que não YAML ou protobuf em vez de JSON?

As implementações de ferramentas podem usar qualquer formato internamente, mas o contexto do modelo e os protocolos de vários fornecedores tratam JSON como o padrão de fato. YAML é frágil em termos de recuo; protobuf é hostil aos modelos. Padrão típico: JSON no limite, converta dentro.

Qual camada deve validar o Schema?

Pelo menos duas portas: depois de tool_calls e antes de executar a ferramenta real; e após o retorno do servidor MCP, antes de escrever de volta no modelo. O primeiro bloqueia parâmetros alucinados; o segundo bloqueia dados sujos no próximo turno.

Como posso validar este JSON localmente?

Salve inputSchema, exemplos de argumentos e exemplos de resultados de ferramentas como arquivos JSON. Use JSON Toolbox no navegador para verificar o esquema em relação aos dados. Nada é carregado.

Resumo

Agentess de IA não podem viver sem JSON porquecada salto deve ser legível por máquina: O esquema descreve as ferramentas, Tool Calling carrega a chamada, MCP a envia fora do processo como JSON-RPC. A linguagem natural só aparece nas extremidades voltadas para o usuário; o meio são objetos validáveis.

Start with one real tool: write the Schema → print and parse the model's arguments string → if the tool lives on an MCP Server, capture one tools/call. When those three JSON documents line up, the Agent is actually working. For the evolution story see o cronograma técnico. Validate Schema samples locally in JSON Toolbox before you ship.