O que o MCP realmente padroniza e o que deixa para você

A cada poucos meses, um protocolo aparece e é descrito como o USB de algo. O MCP ganhou essa comparação mais do que a maioria, mas a analogia para. Aqui está o que o Protocolo de Contexto do Modelo tira do seu prato e o que ele deliberadamente não faz.

O Problema de Integração Antes do MCP

Antes do MCP, cada integração de ferramenta de IA era sob medida. Você queria um modelo para consultar seu banco de dados, então você escreveu código para aquele modelo, aquele banco de dados e aquele aplicativo. Então você queria um segundo modelo para fazer a mesma coisa e você o escreveu novamente. Mesmo banco de dados, mesma operação, implementação diferente, e ambos apodreciam independentemente.

O MCP substitui isso por um protocolo cliente-servidor construído sobre JSON-RPC 2.0. Você constrói um servidor que expõe uma capacidade, e qualquer cliente compatível com MCP pode descobrir e invocá-la sem código de integração escrito para aquela combinação específica. Descoberta, invocação e formatação de resultados funcionam da mesma forma, independentemente de qual modelo está do outro lado.

Hosts, Clientes e Servidores

Os três papéis valem a pena serem esclarecidos, porque a maior parte da confusão nas discussões vem de misturá-los. O host é o aplicativo em que o usuário está realmente. O cliente vive dentro do host e mantém uma conexão. O servidor é o processo que expõe capacidades, e pode ser um binário local falando sobre stdio ou um serviço remoto via HTTP.

Essa separação é a razão pela qual um host pode manter muitos servidores ao mesmo tempo sem cola combinatória: um servidor de sistema de arquivos, um servidor do GitHub, um interno que você escreveu esta tarde. O host é responsável pelo que é conectado e pelo que o usuário vê, e os servidores permanecem ignorantes uns dos outros.

Ferramentas, Recursos e Prompts

Existem três primitivas e elas respondem a três perguntas diferentes. Ferramentas são funções que o modelo pode chamar, e são aquelas com efeitos colaterais. Recursos são dados que o aplicativo pode ler no contexto, mais próximos de um arquivo do que de uma função. Prompts são templates que o usuário invoca deliberadamente, o que é importante porque coloca um humano no loop por design, em vez de por convenção.

A maioria das implementações busca ferramentas e ignora as outras duas, e acaba reconstruindo o carregamento de recursos de forma inadequada dentro de uma chamada de ferramenta. Se o seu servidor está retornando principalmente documentos, isso é um recurso, e tratá-lo como tal mantém a superfície de decisão do modelo menor.

Onde Está o Ônus da Segurança

Esta é a parte que a especificação devolve a você. Uma descrição de ferramenta é texto, e esse texto chega ao modelo como instrução. No momento em que um terceiro fornece o servidor, suas descrições são entradas não confiáveis que podem moldar o comportamento do seu agente antes que qualquer chamada aconteça. A deriva de versão torna isso pior: puxar a mais recente e uma ferramenta renomeada ou expandida muda o que seu agente faz sem nenhuma alteração no seu código.

Respostas práticas são pouco glamourosas. Prenda servidores de terceiros a versões que você revisou. Mantenha operações destrutivas atrás da sua própria camada de confirmação em vez do julgamento do modelo. Registre as chamadas de ferramentas com seus argumentos para que um incidente possa ser reconstruído. Nada disso está no protocolo porque nada disso pode estar, é uma propriedade da sua implementação.

A Conclusão

O MCP padroniza o formato de transmissão, o aperto de mão e a forma de uma capacidade. Ele não decide o que seu agente pode fazer, e nunca fará. Se você quiser a versão mais longa, cobrindo arquitetura, transportes, negociação de capacidade e todo o modelo de segurança, eu mantenho um guia completo em autolearningagents.com.

Trate o protocolo como resolvido e concentre seu esforço na fronteira de confiança, que é onde as falhas reais acontecem.