O Protocolo de Contexto do Modelo: A Revolução na Integração de Ferramentas de IA

Antes do MCP, conectar um aplicativo de IA a uma ferramenta era feito sob medida toda vez. Cada aplicativo escrevia seu próprio conector para cada ferramenta que queria acessar: M aplicativos × N ferramentas = M×N peças de cola, nenhuma delas reutilizável. O Modelo de Contexto de Modelo — um padrão aberto da Anthropic (2024) — colapsa essa confusão em M+N. É a estrutura USB-C para IA, e construir um visualizador para o fluxo real de mensagens foi o que tornou isso concreto para mim. Aqui está a forma disso.

Host, cliente, servidor

Três papéis, e a nomenclatura confunde as pessoas, então vamos esclarecer:

• Host — o próprio aplicativo de IA: Claude Desktop, um IDE, um agente personalizado. Ele contém o modelo.
• Cliente — um conector dentro do host que mantém uma conexão 1:1 com um servidor. Um cliente por servidor.
• Servidor — um processo separado que expõe alguma capacidade (seu sistema de arquivos, GitHub, um banco de dados) por meio de um protocolo uniforme.

Escreva um servidor uma vez e todo host MCP pode usá-lo. Escreva um cliente uma vez e ele pode se comunicar com todo servidor. Essa reutilização — um servidor construído para Claude Desktop funcionando inalterado em um IDE e em um agente sob medida — é todo o retorno de M+N.

Um servidor expõe três tipos de coisas

Não apenas ferramentas. Um servidor MCP pode anunciar três tipos de capacidade, e a distinção é sobre quem controla cada uma:

• Ferramentas — ações que o modelo pode invocar (write_file, run_query). Controlado pelo modelo.
• Recursos — dados somente leitura endereçados por URI (file:///path, uma linha). Controlado pelo aplicativo.
• Prompts — templates reutilizáveis que o usuário pode escolher. Controlado pelo usuário.

O cliente descobre eles com tools/list, resources/list, prompts/list, e invoca eles com tools/call ou resources/read.

É JSON-RPC na transmissão

Cada mensagem é um envelope JSON-RPC 2.0 simples. Um handshake de ciclo de vida único (initialize) abre a conexão; uma rodada de descoberta (tools/list) informa ao host o que está disponível; então o loop de uso se repete sempre que o modelo precisa da ferramenta:

1. initialize            host ↔ server handshake, capacidades trocadas   (uma vez)
2. tools/list            cliente pergunta o que o servidor oferece                (uma vez)
3. usuário faz uma pergunta
4. modelo decide chamar uma ferramenta
5. tools/call            cliente → servidor, código real é executado
6. resultado               servidor → cliente → modelo
7. modelo escreve a resposta

A descoberta acontece uma vez; depois disso, o host apenas emite tools/call sempre que o modelo decidir. O transporte é stdio para um servidor local ou HTTP para um remoto — o mesmo protocolo de qualquer maneira.

É construído sobre chamadas de função, não em vez de

Este é o ponto que as pessoas perdem. O MCP não substitui chamadas de função simples. O modelo ainda emite uma chamada de ferramenta estruturada, exatamente como sempre fez. O que o MCP padroniza é tudo ao redor dessa chamada: como a ferramenta é descoberta, como a solicitação é transportada, e como o resultado retorna. Chamar uma função é o modelo dizendo "chame isso com esses argumentos"; o MCP é a tubulação interoperável que torna a mesma ferramenta acessível de qualquer aplicativo sem reescrever a cola. É por isso que um servidor MCP se encaixa no Claude Desktop, em um IDE e em seu próprio agente — a definição da ferramenta é escrita uma vez, e o protocolo a transporta para todo lugar.

Por que a matemática M+N realmente compensa

O colapso de M×N para M+N não é apenas uma aritmética mais organizada — muda quem faz o trabalho. Sob o modelo antigo, se você construísse um novo aplicativo de IA, deveria um conector para todas as ferramentas que seus usuários queriam, e se você construísse uma nova ferramenta, deveria um conector para todos os aplicativos. Ambos os lados escalavam com o crescimento do outro lado. Sob o MCP, um autor de ferramenta escreve exatamente um servidor e está feito — todo host atual e futuro pode acessá-lo. Um autor de aplicativo escreve um cliente e herda todo o catálogo existente de servidores gratuitamente. O efeito de rede funciona da maneira certa: cada novo servidor torna cada host mais capaz, e cada novo host torna cada servidor mais valioso, sem ninguém reescrevendo a cola para chegar lá.

Então, o modelo mental é pequeno: um host executa um cliente por conexão, cada cliente fala JSON-RPC para um servidor que anuncia ferramentas, recursos e prompts, a descoberta é */list e o uso é */call. Transforme conectores sob medida M×N em reutilizáveis M+N e você obtém um ecossistema em vez de um monte de adaptadores únicos. Escolha um servidor e veja cada mensagem JSON-RPC cruzar a rede, passo a passo:

https://dev48v.infy.uk/ai/days/day51-model-context-protocol.html