Un agente que «recuerda» tu proyecto entre sesiones no está recordando nada. Algo le entregó un archivo, y él leyó el archivo. La pregunta interesante no es cómo almacena el modelo el conocimiento, sino quién decide qué se entrega, y el Model Context Protocol responde a esa pregunta en una frase que casi todo el mundo se salta.
La frase que lo zanja
La especificación MCP describe los recursos, el mecanismo por el cual un servidor expone datos a un modelo, y expone su intención de diseño con toda claridad:
Los recursos en MCP están diseñados para estar dirigidos por la aplicación, siendo las aplicaciones anfitrionas las que determinan cómo incorporar el contexto según sus necesidades.
Fíjate en lo que eso asigna y a quién. El servidor ofrece. La aplicación anfitriona decide. El modelo recibe lo que haya sobrevivido a esa decisión.
La especificación se niega después a normalizar la decisión en sí: las implementaciones son libres de exponer los recursos mediante cualquier patrón de interfaz que les convenga, y el propio protocolo no impone ningún modelo específico de interacción con el usuario. Sugiere posibilidades, un selector en vista de árbol o de lista, un campo de búsqueda, o la inclusión automática basada en heurísticas o en la propia selección del modelo, sin exigir ninguna de ellas.
Así que dos agentes que hablan el mismo protocolo, conectados al mismo servidor, pueden acabar con contextos completamente distintos. Eso no es un defecto. Es el protocolo negándose a tomar una decisión de producto en tu nombre.
Qué es un recurso, en concreto
Un recurso es un dato identificado por una URI: un archivo, un esquema de base de datos, información específica de la aplicación. Los servidores que los admiten deben declarar una capacidad resources, y pueden anunciar dos funciones opcionales:
listChanged, si el servidor emite una notificación cuando cambia la lista de recursos disponibles.subscribe, si admite notificaciones de actualización para recursos concretos que un cliente ha pedido vigilar.
Un servidor puede anunciar una, ambas o ninguna. Los clientes descubren lo que existe con resources/list y leen el contenido con resources/read.
Merece la pena detenerse en una restricción de la especificación, porque descarta toda una categoría de diseños ingeniosos. El conjunto de recursos que devuelve un servidor no debe variar por conexión ni como efecto secundario de otras solicitudes en la conexión. Puede cambiar con el tiempo, y puede variar según la autorización presentada en la solicitud, ya que las credenciales son una entrada por solicitud y no un estado de conexión.
Dicho de otro modo: un servidor no puede mostrarte discretamente un catálogo distinto por lo que preguntaste antes en la sesión. Lo que varía es lo que tus credenciales permiten, no lo que tu historial da a entender.
Las anotaciones son la verdadera política de memoria
Si hay un lugar donde se decide la «memoria», es este. Los recursos llevan anotaciones opcionales que sugieren a los clientes cómo usarlos:
audience: para quién es el contenido,"user","assistant", o ambos.priority: un número de 0.0 a 1.0. La especificación es inusualmente directa sobre los extremos de esa escala: 1 significa lo más importante, efectivamente requerido, mientras que 0 significa lo menos importante, totalmente opcional.lastModified: una marca de tiempo ISO 8601.
Los clientes las usan para filtrar por audiencia, para priorizar qué recursos incluir en el contexto y para ordenar por actualidad.
Ese es todo el mecanismo. Lo que un agente «recuerda» es lo que puntuó lo bastante alto en el campo de prioridad de otra persona como para sobrevivir al presupuesto de contexto. No hay evocación, ni olvido, ni consolidación. Hay una lista ordenada y un límite.
Dos reglas de error que revelan la filosofía de diseño
El manejo de errores de la especificación dice algo sobre lo en serio que se toma la ambigüedad.
Un recurso inexistente debe devolver un error JSON-RPC, código -32602. Y luego esto: los servidores no deben devolver un array contents vacío para un recurso inexistente, porque un array vacío es ambiguo, podría significar que el recurso existe pero no tiene contenido, o que no existe en absoluto.
Un protocolo que se molesta en explicar por qué un array vacío es inaceptable es un protocolo diseñado por gente que ha depurado agentes. El vacío silencioso es la forma en que un agente acaba razonando con total confianza sobre un archivo que nunca leyó.
Las reglas de seguridad que heredas al usarlo
Como los recursos se direccionan por URI y a menudo se corresponden con archivos, la especificación impone obligaciones explícitas. Los servidores deben validar todas las URI de recursos. Deben sanear las rutas de archivo para impedir ataques de traversía de directorios al servir recursos file://. Deberían implementarse controles de acceso para los recursos sensibles, y deberían comprobarse los permisos antes de las operaciones.
No son requisitos exóticos, y ese es justamente el punto. Exponer tu sistema de archivos a un modelo mediante un protocolo no cambia lo que es una traversía de rutas. Solo aumenta el número de manos que sujetan la cuerda.
Qué cambia esto en tu forma de pensar sobre los agentes
Deja de preguntar qué recuerda el modelo. Pregunta qué recursos decidió incluir la aplicación anfitriona, con qué prioridad y bajo qué credenciales. Esa es la respuesta completa, y vive en la aplicación, no en el modelo.
La persistencia es un archivo, no una facultad. Un agente que recuerda tus convenciones entre sesiones está leyendo un documento que algo eligió volver a exponer. Cambia la exposición y la memoria cambia, de forma instantánea y total.
La prioridad es donde ocurre el verdadero diseño. Un campo de 0.0 a 1.0 decide qué sobrevive a un contexto limitado. Ese número, fijado por quien escribió el servidor, moldea el comportamiento del agente más que la mayor parte de la ingeniería de prompts.
La palabra «memoria» importa expectativas de la cognición humana que el mecanismo no sostiene. Lo que MCP especifica en realidad es un catálogo, una política de acceso y una clasificación. Saberlo es la diferencia entre diseñar deliberadamente el contexto de un agente y llevarse una sorpresa con él.
La descripción de los recursos MCP que aparece aquí, incluida la intención de diseño dirigida por la aplicación, la afirmación de que el protocolo no impone un modelo de interacción con el usuario, la capacidad resources con listChanged y subscribe, la restricción de que el conjunto de recursos no debe variar por conexión aunque sí puede variar según la autorización, las anotaciones audience, priority y lastModified, el código de error -32602, la prohibición de devolver un array contents vacío, y los requisitos de validación de URI y saneamiento de rutas, está tomada de la especificación del Model Context Protocol, comprobada en el momento de la redacción. La especificación evoluciona; verifica con la revisión actual antes de confiar en un detalle concreto.
