Capítulo 2 — Revelando o Model Context Protocol (MCP)

Segunda postagem do passeio capítulo a capítulo pelo LLM Primer IV: Projetando a Cognição da IA com MCP. Em que construímos o modelo mental — três papéis, um wire format JSON-RPC, uma superfície dinâmica de descoberta, e um ciclo de vida de sessão — com cuidado suficiente para que o resto do livro possa se apoiar nele.

Por que este capítulo existe

O Capítulo 1 nomeou o problema. Este capítulo constrói o modelo mental da resposta. O MCP pode ser resumido numa frase e mal-entendido num parágrafo, então o capítulo toma seu tempo: o que o protocolo é no nível do wire, o que os três papéis significam e o que cada um detém, como se diferencia de uma API REST nos casos que de fato importam em produção, e o que acontece durante uma sessão da conexão ao desmonte. A meta é que, no final, você consiga prever — antes de ler o próximo capítulo — o que uma primitiva de servidor deve ser, o que uma primitiva de cliente deve ser, e por que o MCP ganha a estrutura que tem.

2.1 O que o MCP é e o que "USB-C para IA" de fato significa

O Model Context Protocol é uma especificação aberta de como aplicações LLM descobrem, descrevem e invocam capacidades externas. No wire é JSON-RPC 2.0 sobre um pequeno conjunto de transportes. No nível arquitetural é o contrato que permite a um host trabalhar com qualquer servidor conforme sem código de integração sob medida. Uma ferramenta construída uma vez contra o protocolo funciona com todo host que o fala. Um host construído uma vez contra o protocolo pode usar toda ferramenta que o fala.

A abreviação que pegou foi "USB-C para IA". O formato estrutural de fato espelha o USB-C — um padrão único de conexão mediando entre uma população aberta de dispositivos e uma população aberta de hosts. Os limites da metáfora valem ser nomeados: o USB-C padroniza um conector mais uma pilha acima dele; o MCP padroniza apenas o protocolo. O USB-C roda em escalas de tempo elétricas com framing imposto por hardware; o MCP roda em escalas de tempo de rede com framing definido por software, o que significa que o MCP pode ser mais flexível e também tem que lidar com conexões caídas e pares lentos que o USB-C não precisa.

Uma comparação mais próxima, para engenheiros, é o LSP. O Language Server Protocol definiu um protocolo que qualquer editor e qualquer language server pudessem falar; o MCP define um que qualquer host LLM e qualquer provedor de capacidade possam falar. O formato do ganho é idêntico — muitos-para-muitos colapsado por um protocolo compartilhado em algo que escala aditivamente. A escolha de basear o MCP em JSON-RPC 2.0 em vez de inventar um wire format novo foi deliberada: JSON-RPC é pequeno, maduro, agnóstico de linguagem, e sem glamour. As escolhas arquiteturais interessantes não estão no nível do wire. Estão em como Hosts, Clientes e Servidores dividem responsabilidade.

2.2 Hosts, Clientes e Servidores — o que cada papel detém

O MCP define três papéis, e a primeira coisa a entender é que "Cliente" e "Servidor" não significam o que frequentemente significam em outros contextos. Um Servidor expõe capacidades — tools, resources, prompts. Um Cliente é uma única conexão falando o protocolo com um Servidor, gerenciada dentro de uma aplicação maior. A aplicação maior é o Host. O Host detém o modelo, a sessão do usuário, e a política sobre o que o modelo está autorizado a fazer. Os Servidores detêm suas superfícies de capacidade. Os Clientes são os fios entre eles, um por Servidor.

A divisão importa porque cada papel tem responsabilidade diferente e postura de confiança diferente. O Host é a fronteira de confiança que importa do ponto de vista do usuário; todo o resto é algo que o Host decidiu deixar entrar. Um Host falando com cinco Servidores tem cinco Clientes rodando dentro, cada um com seu próprio estado de sessão, suas próprias assinaturas, sua própria visão de quais capacidades foram negociadas. Se um Servidor cai, o Cliente correspondente cai; os outros Clientes seguem rodando; o Host fica vivo. Os Clientes são isoladores por conexão que impedem um Servidor ruim de envenenar a sessão inteira.

Há também um argumento de segurança para a divisão. Todo Servidor é, no mínimo, código escrito por outra pessoa. O Cliente medeia tudo que o Servidor pode fazer que afete o Host — notificações, elicitations, requisições de sampling, resources publicados — e é onde a política por Servidor pertence. Host, Cliente e Servidor são papéis lógicos, não estritamente físicos: numa configuração local o Servidor é frequentemente um subprocesso por stdio; num deploy remoto é um serviço por transporte baseado em HTTP. O protocolo não se importa; as fronteiras de papel se importam.

2.3 MCP versus REST — o que descoberta dinâmica e descrições semânticas compram

A pergunta razoável é "isso não é só REST?" As diferenças não são cosméticas. As mais consequentes são descoberta dinâmica, descrições semânticas escritas para um LLM, e um modelo de mensagem bidirecional.

Uma API REST publica endpoints em documentação escrita para desenvolvedores humanos. O conjunto de endpoints que um cliente usa é fixo em tempo de build; endpoints novos exigem redeploys. O MCP inverte isso. No início de sessão, o Cliente pergunta "o que você oferece?" e o Servidor responde com um catálogo tipado — schemas, descrições, metadados — que o host usa programaticamente. Se o Servidor depois adiciona uma ferramenta, uma notificação listChanged atualiza o Cliente em meio de sessão sem restart. O Servidor é a fonte autoritativa de verdade sobre suas próprias capacidades; a descrição não pode divergir da implementação porque não há cópia do lado do cliente para divergir.

Descrições semânticas são a segunda diferença. A documentação de um endpoint REST é escrita para um desenvolvedor que vai ler e decidir. A descrição de uma ferramenta MCP é escrita para um LLM que vai lê-la como parte do seu prompt e decidir autonomamente. Uma descrição que diz "POST para /users/:id/orders" é inútil para um LLM, que precisa saber que operação conceitual a ferramenta realiza, quando ela deve ser preferida, que efeitos colaterais tem, e o que suas entradas significam em termos de domínio. O trabalho de traduzir a API para termos legíveis por LLM foi empurrado uma vez, para dentro do Servidor, onde as pessoas mais próximas da capacidade podem mantê-lo.

A terceira diferença é bidirecionalidade. REST é requisição-resposta; a conexão fecha. MCP é bidirecional por design. O Servidor pode mandar notificações a qualquer momento, pode iniciar requisições de sampling de volta para o Cliente, pode elicitar respostas do usuário em meio de fluxo. Nenhuma destas é tecnicamente impossível sobre REST. Todas são desajeitadas lá. No MCP fazem parte do padrão.

2.4 Negociação de capacidades e o ciclo de vida de sessão

Uma sessão começa quando o Cliente abre um transporte e manda uma requisição initialize carregando sua versão de protocolo e capacidades. O Servidor responde com suas próprias capacidades — ele expõe tools, expõe resources, oferece subscriptions, suporta funcionalidades avançadas. O Cliente confirma com uma notificação initialized. A sessão entra então no estado operacional, e os tipos de mensagem disponíveis são exatamente o subconjunto que ambos os lados concordaram.

Esta negociação é o que permite que um Cliente e Servidor com conjuntos diferentes de funcionalidades coexistam produtivamente. É também onde versionamento é tratado: o Servidor escolhe a maior versão que ambos os lados suportam. Operacionalmente, o ciclo de vida tem consequências. A inicialização não é grátis — há um custo de round-trip e, para servidores remotos, setup de conexão por cima. Sessões de vida longa são o padrão preferido; mudanças de capacidade fluem como notificações em vez de reconexão. Hosts que respeitam isso — mantendo sessões quentes, reconectando em segundo plano após oscilações de rede — obtêm latência materialmente melhor. Hosts que desmontam e reinicializam para cada requisição funcionam corretamente mas ineficientemente.

Uma assimetria que vale fixar: requisições têm respostas; notificações não. Eventos de list-changed são notificações, então um Cliente que perde uma deve estar pronto para atualizar sua visão chamando list_tools de novo. A notificação é uma otimização, não uma garantia. Código MCP robusto a trata como dica, não como registro.

O que o Capítulo 2 prepara

Você tem agora o modelo mental. MCP é um protocolo JSON-RPC com três papéis, descoberta dinâmica que torna o Servidor autoritativo para suas próprias capacidades, descrições escritas para audiência LLM, um modelo de mensagem bidirecional com notificações e requisições iniciadas pelo servidor, e um ciclo de vida que abre com negociação explícita de capacidades e opera dentro de qualquer subconjunto que ambos os lados concordarem. Isso é andaime suficiente para falar concretamente sobre o que Servidores e Clientes cada um expõem, que é o que os próximos dois capítulos fazem.

Próximo — Capítulo 3: Primitivas de Servidor — Resources, Prompts, Tools. Os três substantivos que um servidor pode oferecer, por que cada um importa, e a disciplina de escolher a primitiva certa em vez de sobrecarregar uma no território de outra.