PathrulePathrule vs. el servidor de memoria MCP
El servidor de memoria de referencia le da a un agente un grafo de conocimiento local de entidades, relaciones y observaciones, y ocho herramientas para escribirlo y leerlo. Pathrule habla el mismo protocolo, así que la diferencia no es el transporte. Es que el servidor de referencia espera a que lo llamen, mantiene un único grafo compartido sin noción de dónde estás trabajando y no puede hacer cumplir nada.
Para qué sirve el servidor de referencia
Es el ejemplo canónico de un servidor MCP que guarda estado, y es de verdad la forma más rápida de entender qué es MCP. Las entidades llevan observaciones, las relaciones las conectan en voz activa, todo se guarda en un archivo JSONL que puedes abrir en un editor, y el conjunto se ejecuta con un solo comando, sin cuenta y sin servicio.
Para un experimento en solitario, para aprender el protocolo o para un puñado de datos que quieres que un agente recuerde entre conversaciones, es suficiente, y nada de lo que hay aquí sostiene lo contrario.
Lado a lado
| Servidor de memoria MCP de referencia | Pathrule | |
|---|---|---|
| Transporte | MCP | MCP, además de hooks y archivos de instrucciones que instalan la CLI o la extensión de VS Code |
| Cómo llega el conocimiento | El agente tiene que llamar a una herramienta: `search_nodes`, `read_graph` | Se entrega antes de la primera llamada a una herramienta mediante los hooks o el archivo de reglas de cada agente |
| Ámbito | Un único grafo compartido, sin ámbito por ruta ni por usuario | Indexado por ruta del repositorio, por espacio de trabajo |
| Qué se guarda | Entidades, relaciones, observaciones | Memorias, reglas y skills, con tipo y prioridad |
| Aplicación | Ninguna | Una regla estricta puede bloquear un cambio que coincida en los clientes con hooks de herramientas |
| Equipo | Un archivo JSONL local | Espacio de trabajo compartido con roles y revisión |
| Conocimiento obsoleto | Te toca detectarlo | Se señala como una edición propuesta que tú apruebas |
Las afirmaciones sobre el servidor de referencia proceden de su README en modelcontextprotocol/servers, consultado en agosto de 2026. Si alguna fila es incorrecta, dínoslo y la corregiremos.
Las diferencias que se derivan de ello
Una herramienta que el agente tiene que acordarse de llamar. Su README deja claro que los agentes tienen que llamar a las herramientas; nada es automático. Así que el agente tiene que decidir buscar antes de actuar, que es el mismo hueco que tiene toda memoria basada en consultas: la restricción que más necesitas es la que nadie pensó en buscar.
Un grafo, sin noción de ubicación. No hay ámbito por ruta del repositorio ni aislamiento: es un único grafo compartido para todas las interacciones. Eso está bien para unas pocas decenas de datos y resulta inviable en cuanto dos servicios de un mismo monorepo discrepan sobre qué es un cambio válido.
Nada puede ser una restricción. Las observaciones son texto que un agente puede leer. Una regla de Pathrule lleva un ámbito, una prioridad y un nivel de aplicación, así que, en los clientes con hooks de herramientas, el hook local de Pathrule puede detener un cambio que coincida antes de que llegue al código, en lugar de dejarlo al criterio del modelo.
Cuándo el servidor de referencia es la opción correcta
Úsalo cuando estés aprendiendo MCP, cuando quieras un bloc de notas sin dependencias para un agente en una máquina o cuando el conocimiento sea de verdad un puñado de entidades y no las convenciones acumuladas de un equipo. Es una implementación de referencia que hace exactamente lo que debe hacer una implementación de referencia.
Recurre a Pathrule cuando el conocimiento tenga que vincularse al lugar donde ocurre el trabajo, cuando tenga que llegar a la sesión de un compañero y a un segundo motor, cuando una parte tenga que frenar un cambio en lugar de desaconsejarlo y cuando prefieras que el agente proponga qué conservar antes que mantener un grafo a mano.
Fuentes y verificación
Documentación oficial del servidor de referencia verificada el 1 de octubre de 2026. No se probó en local ninguna versión publicada del servidor de referencia. Las afirmaciones sobre Pathrule se revisaron frente a la versión publicada de Pathrule CLI 0.6.1 el 9 de octubre de 2026.
- Model Context Protocol: servidor de memoria de referencia
Fuente oficial sobre las herramientas, el modelo de grafo y la persistencia en JSONL del servidor de referencia.
Preguntas frecuentes
Pathrule también es un servidor MCP. ¿Qué cambia de verdad?
El protocolo es el mismo; la entrega, no. El servidor de referencia entrega conocimiento cuando un agente llama a una herramienta. pathrule setup además registra hooks y escribe archivos de instrucciones para el agente, así que la porción que rige la ruta en la que trabajas llega antes de la primera llamada a una herramienta, la hubiera pedido el agente o no. Claude Code y Codex reciben un hook de prompt, Cursor y GitHub Copilot reciben hooks de sesión y de herramientas, y Windsurf lee un archivo de reglas.
¿Puedo usar el servidor de memoria de referencia junto con Pathrule?
Nada te lo impide, pero se solapan: los dos son sitios donde un agente guarda conocimiento. Usar los dos suele significar dos almacenes mantenidos a medias, y el que no tiene ámbito por ruta es el que se deteriora. Elige uno por proyecto.
¿Pathrule funciona si solo puedo usar un endpoint MCP alojado?
Sí, con una limitación que conviene conocer. La CLI, la extensión de VS Code y Remote MCP son vías de entrada al mismo conocimiento de Pathrule. Remote MCP, en https://cloud.pathrule.io/mcp, expone el mismo espacio de trabajo y las mismas memorias, reglas y skills con OAuth y una cuenta de Pathrule, pero no instala hooks ni escribe archivos locales, y no tiene modo local, así que responde a petición en lugar de entregar antes de la primera llamada a una herramienta. La entrega desde los hooks llega con la CLI o la extensión de VS Code.
¿Pathrule guarda entidades y relaciones como un grafo?
Mantiene un grafo de conocimiento, pero el índice es la ruta del repositorio y no el nombre de una entidad, y el contenido tiene tipo: las memorias son hechos, las reglas son restricciones con ámbito y prioridad, y las skills son procedimientos con nombre. Esos tipos son lo que hace posibles la aplicación y la priorización.