MCPs como plano de controle de sistemas cognitivos
Muitos profissionais ainda descrevem protocolos de contexto como um detalhe de integração entre ferramenta e modelo. Essa leitura subestima a função estratégica dos MCPs. Em arquitetura séria, o protocolo não é mero conector. Ele define o plano de controle pelo qual identidade, capacidade, recurso, permissão e fluxo de execução passam a ser negociados de maneira inteligível. Quando esse plano não existe, cada integração cria sua própria semântica, sua própria superfície de risco e sua própria forma de ocultar falhas. O resultado é fragmentação operacional.
A importância dos MCPs aparece quando o sistema deixa de ser uma conversa isolada e passa a ser uma malha de agentes, ferramentas, memórias e serviços externos. Nesse ambiente o problema principal não é gerar um texto elegante. É coordenar acesso a capacidade distribuída sem perder previsibilidade. Um agente precisa saber o que pode chamar, com que contrato, sob quais restrições e com que forma de retorno. Um protocolo bem desenhado reduz improvisação sem matar flexibilidade. Ele torna a expansão do ecossistema cumulativa em vez de caótica.
A versão 2025-11-25 da especificação MCP define três transportes principais. O transporte stdio opera sobre stdin/stdout usando JSON-RPC 2.0 com delimitação por newline. É a opção canônica para servidores locais executados como subprocessos. O transporte HTTP com SSE (Server-Sent Events) usa GET para o canal server-to-client e POST para client-to-server, com a sessão identificada por um endpoint URI retornado no handshake inicial. O Streamable HTTP, introduzido na especificação mais recente, resolve a limitação de SSE para sessões longas com retomada de sessão e upgrade de stream.
A arquitetura MCP é estruturada em três camadas. O Host é o processo que contém o LLM e aceita interações do usuário — Claude Desktop, VS Code com Copilot, ou uma aplicação customizada. O Client é a camada dentro do Host que inicia conexões MCP e mantém sessões um-para-um com cada Server. O Server é o processo que expõe capacidades via as primitivas do protocolo. Essa separação garante que o Host nunca acesse ferramentas diretamente. Todo acesso passa pelo contrato negociado no handshake de inicialização.
As primitivas do protocolo cobrem quatro domínios funcionais. Resources expõem dados estruturados como documentos, snippets de código, entradas de banco de dados ou feeds de eventos. Tools definem ações executáveis que o LLM pode invocar com parâmetros tipados e retorno estruturado. Prompts permitem que servidores ofereçam templates reutilizáveis que o Host pode inserir em conversas. Sampling inverte o fluxo: o Server solicita ao Host que execute uma inferência LLM com parâmetros específicos de temperatura e max_tokens. Essa quarta primitiva é o que transforma MCP de um protocolo de integração em um protocolo genuinamente agêntico.
A questão de segurança nos MCPs é fundamental e frequentemente negligenciada. O vetor mais crítico é prompt injection via tool results. Um servidor MCP malicioso pode retornar conteúdo que instrui o LLM a executar ações não autorizadas. A especificação aborda isso através de tool annotations: readOnlyHint indica que a tool não altera estado externo; destructiveHint sinaliza operações com efeito permanente; idempotentHint declara que chamadas repetidas produzem o mesmo resultado; openWorldHint indica que a tool acessa dados que podem conter instruções arbitrárias. Essas anotações permitem que o Host aplique políticas de autorização antes de permitir invocações.
Para servidores remotos, a especificação MCP recomenda OAuth 2.1 com PKCE. O fluxo começa com o Client enviando uma solicitação de autorização ao Authorization Server com code_challenge usando SHA-256. O Authorization Server emite um code que o Client troca por um access token usando o code_verifier. O token é incluído em todos os requests subsequentes como Bearer. Implementações sérias também implementam token rotation, onde o access token tem vida curta e é renovado via refresh token, mantendo a sessão viva sem reautenticação constante.
A validação de schemas de ferramentas é onde o protocolo se torna mais exigente. Cada tool declara seu input schema como JSON Schema, idealmente com additionalProperties: false para rejeitar campos não esperados. O Host valida os argumentos do LLM contra esse schema antes de transmitir a chamada ao Server. O Server valida novamente. Essa dupla validação cria redundância defensiva que protege contre both malformed LLM outputs and malicious schema manipulation. Outputs também podem ser tipados, embora a especificação atual trate outputs como text, image ou resource unificados.
O protocolo A2A do Google complementa o MCP para coordenação agente-para-agente. Enquanto MCP foca na comunicação entre um Host e seus servidores, A2A define como agentes autônomos se descobrem, negociam capacidades e delegam tarefas entre si via Agent Cards — documentos JSON que anunciam habilidades, endpoints e esquemas de autenticação. A convergência eventual entre MCP e A2A criará uma malha de protocolos onde servidores MCP podem também atuar como agentes A2A, e vice-versa. Arquitetos que compreendem ambos os protocolos hoje terão vantagem significativa ao projetar sistemas multi-agente em produção.
O que diferencia um sistema MCP bem arquitetado de uma integração ad-hoc é a disciplina de contrato. Cada tool é uma API com garantias explícitas. Cada resource tem escopo declarado. Cada sampling request tem parâmetros justificados. Essa formalidade não é burocracia. É o que permite que um sistema cognitivo escale além do controlável por uma única mente humana, mantendo previsibilidade suficiente para auditoria e correção quando erros ocorrem.