Model Context Protocol (MCP)

Para que serve o MCP

Antes de existir um protocolo comum, cada combinação de assistente e ferramenta era uma integração própria, escrita duas vezes e mantida para sempre: cinco assistentes e vinte ferramentas significavam cem conexões sob medida. O MCP transforma isso em soma em vez de multiplicação. Quem faz a ferramenta escreve um servidor, quem faz a aplicação escreve um cliente, e qualquer coisa de um lado consegue falar com qualquer coisa do outro. A Anthropic o publicou como padrão aberto no fim de 2024 e a adoção foi bem além disso desde então. Ele lembra mais uma interface de driver de dispositivo do que uma API de produto: o valor não está no que ele faz, e sim no fato de todo mundo ter concordado com o formato.

O arranjo é cliente-servidor. A aplicação que hospeda o modelo é o cliente; cada capacidade que você quer expor roda como um servidor que descreve o que oferece de forma legível por máquina, para o modelo ver as opções e escolher. É independente de transporte — um servidor pode ser um processo local na mesma máquina ou algo acessível por HTTP —, e é por isso que a mesma integração funciona num assistente de desktop, num agente de IA rodando num servidor e numa ferramenta de programação sem ser reescrita para cada um.

O que um servidor expõe

Um servidor oferece três tipos de coisa, e a distinção importa quando você constrói um:

• Ferramentas — ações que o modelo pode invocar: enviar uma mensagem, consultar uma tabela, criar um registro. São as que têm consequências e com as quais vale ter cuidado.
• Recursos — dados que o cliente pode trazer para o contexto: um arquivo, um documento, uma linha, o conteúdo de uma página. Material somente leitura entregue ao modelo, não algo que ele faz.
• Prompts — instruções reutilizáveis e parametrizadas que uma pessoa escolhe deliberadamente, em vez de algo que o modelo aciona por conta própria.

O que o protocolo não resolve

Um padrão de conexão elimina o encanamento e deixa tudo que é difícil de pé. A primeira coisa que aparece na prática é que ter ferramentas não é de graça. Toda capacidade que um modelo pode chamar precisa ser descrita para ele, e essas descrições ocupam o mesmo contexto limitado que o trabalho em si, então um catálogo grande compete silenciosamente com a tarefa. Batemos exatamente nisso construindo agentes para clientes na AgentCeres — o Diretor de Crescimento com IA em agentceres.com: passado certo número de capacidades disponíveis, o catálogo precisa ser resumido para caber, o que significa que cada integração a mais custa alguma coisa mesmo que ninguém a use. A disciplina de engenharia acaba sendo decidir o que um agente *não* deveria conseguir alcançar.

A segunda lacuna é a autoridade. O protocolo descreve como chamar uma ferramenta; não diz nada sobre se este agente, agindo por este cliente, agora, deveria poder. Uma ferramenta que lê uma planilha e outra que publica na conta social de uma empresa são idênticas para o protocolo e completamente diferentes para o negócio. Essa fronteira pertence ao seu próprio produto, e é por isso que tudo com consequência pública do nosso lado espera atrás de um portão de aprovação com uma pessoa no comando, não importa como a capacidade foi conectada.