Dei as chaves do blog a um agente. Estas são as regras.

As regras demoraram mais do que o código

Este artigo entrou no site por uma chamada HTTP. Não passou pelo painel de administração: saiu de uma conversa, nasceu como rascunho e ficou à espera. Fui eu que carreguei no publicar, depois de o ler todo. A porta que o agente usou (uma API de conteúdos e um servidor MCP construídos para este site) levou-me uma manhã a escrever, e decidir que regras lhe pôr levou bastante mais. É essa parte que vale a pena contar.

O calendário ajudou. A 28 de julho saiu a versão final da especificação 2026-07-28, a maior revisão do MCP desde que o protocolo nasceu, e o conteúdo dela diz mais do que qualquer anúncio: um núcleo sem estado, que corre atrás de um load balancer vulgar sem sessões pegajosas nem armazém partilhado; autorização encostada ao OAuth 2.1; e uma política formal de deprecação com doze meses de aviso. São as coisas que um protocolo arruma quando deixa de servir demonstrações e começa a servir sistemas que já estão a correr.

O que é o MCP, sem jargão

O MCP (Model Context Protocol) é uma norma aberta que define como um modelo de IA fala com sistemas externos: uma base de dados, uma aplicação, o gestor de conteúdos de um blog. Quem é dono do sistema constrói um servidor MCP, que expõe um conjunto de operações com nomes, tipos e limites, e qualquer cliente compatível liga-se lá (o Claude, o ChatGPT, um editor de código). Antes disto, cada ligação era um adaptador feito à medida, que servia àquele cliente e àquele sistema, e que morria assim que um dos dois mudasse de ideias.

A história é curta. A Anthropic publicou a norma em novembro de 2024 e, a 9 de dezembro de 2025, doou-a à Agentic AI Foundation, um fundo dirigido debaixo da Linux Foundation, cofundado com a Block e a OpenAI e apoiado pela Google, Microsoft, AWS, Cloudflare e Bloomberg. Treze meses de vida e já tinha estes rivais todos sentados à mesma mesa. Isso não acontece por acaso, e também não acontece a formatos que continuam a pertencer a uma empresa só.

Porque é que isto interessa a quem gere um site pequeno

Um agente só serve para alguma coisa quando toca nos sistemas reais, e as maneiras habituais de lhe dar esse toque são todas más. Automatizar o browser por cima do painel de administração funciona até alguém mudar um botão de sítio. Dar-lhe as credenciais da base de dados resolve o problema e cria outro bem maior, porque quem só precisava de escrever artigos passa a poder apagar utilizadores. O MCP abre uma terceira via: expor um conjunto pequeno de verbos, com tipos e regras, e mais nada.

Neste site são 12 ferramentas: criar artigo, editar, publicar, despublicar, traduzir, enviar imagem, listar, e pouco mais. O agente não vê utilizadores, não vê configuração, não vê as outras páginas do site. Desenhei eu a superfície de contacto, ferramenta a ferramenta, e é por isso que consigo dormir descansado.

O que o MCP não é

O MCP é canalização, e canalização não corrige o que passa lá dentro. Um agente mal orientado com boas ferramentas continua a errar, agora com mais alcance. E o protocolo também não traz segurança embrulhada: a OWASP documenta o tool poisoning, instruções maliciosas escondidas nas descrições das ferramentas, que o agente lê e executa sem o utilizador ver nada, e a prompt injection continua no topo da lista de riscos para aplicações construídas sobre modelos de linguagem. Permissões de escrita multiplicam as consequências de qualquer uma dessas falhas.

Daí a regra que organizou tudo o resto: pedir a um modelo que não apague nada não é uma política de segurança; é um desejo. As proteções vivem no servidor, onde o agente não lhes chega por muito bem que lhe peçam.

Como fiz, na prática

Este site corre em Wagtail (um gestor de conteúdos construído sobre Django). A porta são cerca de 700 linhas de API, com as regras cozidas no código, mais 225 linhas de servidor MCP que apenas traduzem chamadas. A regra que mais me custou a escrever foi a de apagar: só funciona em rascunhos que nunca chegaram a ser publicados. Conteúdo que já esteve visível exige despublicar primeiro e depois confirmação humana no painel, e é deliberadamente chato.

A seguir vem aquela que uso todos os dias sem dar por ela. Tudo o que o agente cria ou edita nasce rascunho, e publicar é uma chamada separada, o que me deu espaço para ler este texto inteiro antes de ele existir para alguém. O resto é rotina de administração de sistemas: a chave vive numa variável de ambiente e, sem ela, a API responde como se as rotas nunca tivessem sido escritas; as operações do agente ficam assinadas por um utilizador dedicado, o claude-api, para eu conseguir distinguir no histórico de revisões o que fiz eu do que fez ele; as imagens são validadas pelo conteúdo real do ficheiro, com 15 MB de tecto e 120 pedidos por minuto.

Nada disto é exótico. É o que se faz a um estagiário no primeiro dia: credenciais próprias, rascunhos por defeito, e as ações destrutivas ficam com a chefia. Este escreve a 200 palavras por segundo.

O que faria já, e o que ainda não

Se gere uma operação pequena e quer experimentar isto, comece pela leitura. Um servidor MCP que deixe o agente consultar encomendas, stocks ou conteúdo já poupa horas e arrisca pouco (o pior que acontece é uma resposta errada, que se corrige a olhar). O passo seguinte são escritas reversíveis, como os rascunhos deste blog. O que eu ainda não entrego a um agente é apagar, pagar, ou qualquer coisa que não se desfaça com um clique, um assunto que já tratei a propósito do comércio agêntico, onde a indústria anda a aprender a mesma lição pela ordem inversa.

Fica-me a pergunta que anda a incomodar-me desde a manhã em que escrevi a API. Se esta ligação entre modelos e sistemas se tornar mesmo infraestrutura aborrecida, normalizada e auditável, quantas das coisas que ainda faço à mão neste site farão sentido daqui a um ano? Não tenho resposta. Tenho o histórico de revisões, e por enquanto ainda consigo ler nele quem fez o quê.

#mcp #agentes #ia