Um agente que «se lembra» do seu projeto entre sessões não está a lembrar-se de nada. Algo lhe entregou um ficheiro, e ele leu o ficheiro. A questão interessante não é como o modelo armazena conhecimento, é quem decide o que é entregue, e o Model Context Protocol responde a essa questão numa frase que quase toda a gente salta.
A frase que resolve a questão
A especificação MCP descreve os recursos, o mecanismo pelo qual um servidor expõe dados a um modelo, e declara sem rodeios a sua intenção de conceção:
Os recursos no MCP são concebidos para serem orientados pela aplicação, com as aplicações anfitriãs a determinarem como incorporar o contexto de acordo com as suas necessidades.
Repare no que isso atribui, e a quem. O servidor oferece. A aplicação anfitriã decide. O modelo recebe aquilo que sobreviveu a essa decisão.
A especificação recusa depois normalizar a própria decisão: as implementações são livres de expor recursos através de qualquer padrão de interface que lhes convenha, e o próprio protocolo não impõe qualquer modelo específico de interação com o utilizador. Sugere possibilidades, um seletor em vista de árvore ou de lista, um campo de pesquisa, ou a inclusão automática baseada em heurísticas ou na seleção do próprio modelo, sem exigir nenhuma delas.
Assim, dois agentes que falam o mesmo protocolo, ligados ao mesmo servidor, podem acabar com contextos completamente diferentes. Isso não é uma falha. É o protocolo a recusar tomar uma decisão de produto em seu nome.
O que é um recurso, concretamente
Um recurso é um dado identificado por um URI: um ficheiro, um esquema de base de dados, informação específica da aplicação. Os servidores que os suportam devem declarar uma capacidade resources, e podem anunciar duas funcionalidades opcionais:
listChanged, se o servidor emite uma notificação quando a lista de recursos disponíveis muda.subscribe, se suporta notificações de atualização para recursos específicos que um cliente pediu para vigiar.
Um servidor pode anunciar uma, ambas ou nenhuma. Os clientes descobrem o que existe com resources/list e leem o conteúdo com resources/read.
Vale a pena deter-nos numa restrição da especificação, porque exclui toda uma categoria de soluções engenhosas. O conjunto de recursos que um servidor devolve não deve variar por ligação nem como efeito secundário de outros pedidos na ligação. Pode mudar ao longo do tempo, e pode variar consoante a autorização apresentada no pedido, uma vez que as credenciais são uma entrada por pedido e não um estado da ligação.
Por outras palavras: um servidor não pode mostrar-lhe discretamente um catálogo diferente por causa daquilo que perguntou antes na sessão. O que varia é o que as suas credenciais permitem, não o que o seu histórico dá a entender.
As anotações são a verdadeira política de memória
Se há um sítio onde a «memória» é decidida, é aqui. Os recursos transportam anotações opcionais que sugerem aos clientes como os utilizar:
audience: a quem se destina o conteúdo,"user","assistant", ou ambos.priority: um número de 0.0 a 1.0. A especificação é invulgarmente direta quanto aos extremos dessa escala: 1 significa o mais importante, efetivamente exigido, ao passo que 0 significa o menos importante, inteiramente opcional.lastModified: uma marca temporal ISO 8601.
Os clientes usam-nas para filtrar por destinatário, para dar prioridade aos recursos a incluir no contexto, e para ordenar por atualidade.
É este todo o mecanismo. Aquilo de que um agente «se lembra» é o que pontuou alto o suficiente no campo de prioridade de outra pessoa para sobreviver ao orçamento de contexto. Não há evocação, não há esquecimento, não há consolidação. Há uma lista ordenada e um limite.
Duas regras de erro que revelam a filosofia de conceção
O tratamento de erros da especificação diz alguma coisa sobre a seriedade com que ela encara a ambiguidade.
Um recurso em falta deve devolver um erro JSON-RPC, código -32602. E depois isto: os servidores não devem devolver um array contents vazio para um recurso inexistente, porque um array vazio é ambíguo, pode significar que o recurso existe mas não tem conteúdo, ou que não existe de todo.
Um protocolo que se dá ao trabalho de explicar por que razão um array vazio é inaceitável é um protocolo concebido por quem já depurou agentes. O vazio silencioso é a forma como um agente acaba a raciocinar com toda a confiança sobre um ficheiro que nunca leu.
As regras de segurança que herda ao utilizá-lo
Como os recursos são endereçados por URI e correspondem muitas vezes a ficheiros, a especificação impõe obrigações explícitas. Os servidores devem validar todos os URI de recursos. Devem sanear os caminhos de ficheiros para impedir ataques de travessia de diretórios ao servir recursos file://. Devem ser implementados controlos de acesso para os recursos sensíveis, e as permissões devem ser verificadas antes das operações.
Não são requisitos exóticos, e é precisamente esse o ponto. Expor o seu sistema de ficheiros a um modelo através de um protocolo não altera aquilo que é uma travessia de caminhos. Apenas aumenta o número de mãos a segurar a corda.
O que isto muda na forma de pensar sobre agentes
Pare de perguntar do que o modelo se lembra. Pergunte que recursos a aplicação anfitriã decidiu incluir, com que prioridade e sob que credenciais. É essa a resposta completa, e vive na aplicação, não no modelo.
A persistência é um ficheiro, não uma faculdade. Um agente que recorda as suas convenções entre sessões está a ler um documento que algo escolheu voltar a expor. Mude a exposição e a memória muda, instantânea e completamente.
É na prioridade que acontece a verdadeira conceção. Um campo de 0.0 a 1.0 decide o que sobrevive a um contexto limitado. Esse número, definido por quem escreveu o servidor, molda o comportamento do agente mais do que a maior parte do prompt engineering.
A palavra «memória» importa expectativas da cognição humana que o mecanismo não sustenta. O que o MCP especifica na realidade é um catálogo, uma política de acesso e uma ordenação. Sabê-lo é a diferença entre conceber deliberadamente o contexto de um agente e ser surpreendido por ele.
A descrição dos recursos MCP aqui apresentada, incluindo a intenção de conceção orientada pela aplicação, a afirmação de que o protocolo não impõe um modelo de interação com o utilizador, a capacidade resources com listChanged e subscribe, a restrição de que o conjunto de recursos não deve variar por ligação embora possa variar consoante a autorização, as anotações audience, priority e lastModified, o código de erro -32602, a proibição de devolver um array contents vazio, e os requisitos de validação de URI e de saneamento de caminhos, foi retirada da especificação do Model Context Protocol, verificada no momento da redação. A especificação evolui; confirme com a revisão atual antes de depender de um detalhe específico.
