MemoryRouter

Memoria de IA persistente compartida entre Claude, ChatGPT, agentes de codificación y clientes MCP compatibles.

Ver en memoryrouter.aiPrueba este MCPPatrocinado

Documentación

Integraciones Marcos y protocolos

El servidor MCP remoto de MemoryRouter, soporte de protocolos, alcances OAuth, herramientas, modelo de vault y configuración de plataforma.

MemoryRouter ejecuta un servidor remoto de Model Context Protocol que brinda a cualquier cliente compatible con MCP memoria duradera y portátil. Un vault, muchas aplicaciones de IA.

https://mcp.memoryrouter.ai/mcp

Esta es la dirección que pegas en ChatGPT, Claude, Claude Cowork, Codex o cualquier otro cliente MCP. La autenticación es OAuth 2.1 con PKCE; nunca pegas una clave de API en un conector.

Requisitos previos y primera conexión

Crea una cuenta de MemoryRouter y elige un vault que tengas permitido usar. Tu cliente debe admitir MCP remoto por HTTP Streamable y OAuth. Un cliente stdio solo local necesita un puente compatible; agregar esta URL HTTPS como ejecutable no funcionará.

Agrega https://mcp.memoryrouter.ai/mcp como servidor remoto, completa la autorización del navegador y selecciona el vault deseado. Sigue la interfaz exacta del host en ChatGPT, Claude o Cowork. La configuración de OAuth no requiere una clave de API del proveedor de modelos.

Prueba entre sesiones

En una conversación conectada, pregunta: "Guarda este dato de prueba sintético en MemoryRouter: la frase de lanzamiento del proyecto demo es ORCHID-7419."
Aprueba la escritura e inspecciona el resultado exitoso de store_memory.
Abre una conversación nueva con MemoryRouter habilitado, sin copiar el chat anterior.
Pregunta: "Busca en MemoryRouter la frase de lanzamiento del proyecto demo." Verifica que el resultado contenga ORCHID-7419.

Esta es una prueba que tú ejecutas, no una garantía de que un modelo llamará herramientas sin que se lo pidas. La recuperación se ordena por relevancia, no es el vault completo en cada solicitud. Las conexiones de solo lectura no pueden realizar el paso 1. Usa una conexión con escritura para sembrar el mismo vault primero.

Soporte de protocolo

	Versión
Revisión actual	`2026-07-28`
También aceptada	`2025-11-25`, `2025-06-18`, `2025-03-26`

El servidor implementa la revisión 2026-07-28, que es sin estado: cada solicitud se describe a sí misma y no hay un handshake de sesión que perder. Concretamente:

server/discover informa versiones compatibles, capacidades y sugerencias de caché.
Cada solicitud moderna lleva la versión de protocolo _meta y las capacidades del cliente, reflejadas por los encabezados MCP-Protocol-Version, Mcp-Method y Mcp-Name.
Cada resultado exitoso lleva un discriminador resultType e información del servidor por respuesta.
Los catálogos de herramientas y recursos son deterministas y almacenables en caché.

Los clientes antiguos de la era del handshake siguen funcionando: envían initialize y el servidor negocia una versión heredada sin afirmar nunca una moderna. Ningún cliente queda excluido.

Por qué lo sin estado importa para la memoria

El MCP basado en sesiones vincula tu memoria a una conexión activa. Si la conexión se cae o el cliente se reinicia, la sesión desaparece. La durabilidad de MemoryRouter vive en el vault, no en una sesión, por lo que un protocolo sin estado es el ajuste correcto. Cualquier solicitud, de cualquier cliente, en cualquier momento, llega a las mismas memorias.

Herramientas

El servidor expone exactamente diez herramientas. Si un cliente te muestra algo más, no proviene de MemoryRouter.

Herramienta	Requiere	Qué hace
`search_memories`	`memories:read`	Recuperación semántica del vault conectado, con filtros opcionales `tiers` y `importance`
`date_search_memories`	`memories:read`	Recuperación por ventana de tiempo con filtros opcionales `query`, `tiers` y `importance`, más cursores de continuación
`store_memory`	`memories:write`	Guarda una memoria duradera y concisa
`memory_status`	`memories:read`	Estado de la conexión, referencia opaca del vault, conteos, alcances otorgados, deuda de reflexión
`forget_all_memories`	`memories:delete`	Elimina todas las memorias del vault conectado
`consolidate_memories`	`memories:reflect`	Retira un lote de memorias no consolidadas para reflexión
`commit_reflections`	`memories:reflect`	Confirma las entradas de reflexión que escribió el modelo
`inspect_memory`	`memories:read`	Muestra las memorias fuente a partir de las cuales se construyó una reflexión
`delete_memories`	`memories:delete`	Elimina memorias específicas por id, en cualquier nivel
`search`	`memories:read`	Alias de compatibilidad para clientes que requieren una herramienta llamada `search`

También hay dos recursos MCP disponibles cuando el host expone recursos: memory://vault/stats y memory://vault/recent.

Eliminación: qué es y qué no es posible

Existen dos herramientas de eliminación y son deliberadamente diferentes:

delete_memories elimina memorias específicas por sus ids (hasta 500 por llamada). Los ids provienen de resultados de search_memories o inspect_memory. Requiere el alcance memories:delete y un argumento explícito confirmation, y el host debe mostrar al usuario qué se eliminará antes de llamarla. Eliminar una memoria cruda no elimina las reflexiones construidas a partir de ella.
forget_all_memories es solo para todo el vault. Requiere el alcance memories:delete, la frase de confirmación exacta DELETE ALL MEMORIES y devuelve un resultado que confirma que se limpiaron tanto el almacenamiento primario como el reflejado. Cualquier cosa menor devuelve "no se eliminó nada" y nunca llega al almacenamiento.

Un recibo de store_memory no es un identificador de eliminación. El panel en app.memoryrouter.ai también admite la eliminación por memoria.

Reflexiones en este servidor

La Jerarquía de Reflexión está activa de extremo a extremo: tres niveles de memoria, consolidación, linaje y eliminación por memoria, todo utilizable desde dentro de un chat.

El ciclo de consolidación funciona así:

El modelo llama a consolidate_memories. El servidor retira las memorias no consolidadas más antiguas bajo un arrendamiento de 15 minutos y devuelve sus textos, fechas e instrucciones reflection_contract redactadas por el servidor.
El modelo lee los textos y escribe de 5 a 10 entradas de reflexión independientes, calificando la importancia de cada entrada del 1 al 10, siguiendo el contrato al pie de la letra.
El modelo llama a commit_reflections con el id del lote y sus entradas. El servidor las incrusta y almacena en el nivel superior, vincula el linaje a cada fuente y marca las fuentes como consolidadas.

Entonces, en ChatGPT o Claude puedes decir literalmente "consolida mis memorias" y el modelo con el que ya estás hablando hace la reflexión. Si el arrendamiento expira antes de confirmar, no se pierde nada: las memorias vuelven al grupo y el siguiente retiro las toma.

memory_status informa la deuda de reflexión (cuánto material no consolidado lleva el vault), y los resultados de search_memories incluyen consolidation_available cuando el vault cruza el umbral de consolidación, para que el modelo sepa cuándo vale la pena sugerir una reflexión.

inspect_memory es la herramienta de recibos: dale cualquier id de memoria de un resultado de búsqueda y devuelve las memorias de nivel inferior a partir de las cuales se construyó la reflexión, encadenable hasta llegar a las crudas. Pregunta "¿por qué crees eso?" y el modelo puede mostrártelo.

Filtros de búsqueda

search_memories acepta dos filtros opcionales además de la consulta:

tiers: un subconjunto no vacío de [1, 2, 3] para restringir resultados a memorias crudas, reflexiones o reflexiones de alto nivel. Omítelo para buscar en todos los niveles combinados.
importance: un umbral mínimo entero del 1 al 10. Solo las reflexiones tienen calificaciones de importancia, por lo que esto filtra a contenido de nivel 2 y 3.

Guía de niveles: el nivel 3 contiene las reflexiones consolidadas de mayor nivel (identidad, principios, lo que más importa); el nivel 2 contiene reflexiones de eventos significativos específicos; el nivel 1 contiene memorias crudas verbatim. Ajusta los filtros a la pregunta en lugar de aplicar una receta rígida:

Preguntas amplias de "las cosas más importantes que hemos hecho": niveles [3], importancia 8 o superior, un límite grande como 250. Las variantes con límite de tiempo ("las cosas más importantes del mes pasado") usan búsqueda por fecha con los mismos filtros.
Resúmenes generales ("qué sabes sobre esta área o período"): solo niveles [3], sin filtro de importancia. El filtro de importancia es opcional y puede excluir contexto útil.
Búsquedas de temas específicos ("encuentra la decisión sobre X"): omite los niveles por completo para que se busquen juntos crudo, nivel 2 y nivel 3, y deja la importancia sin configurar. Un filtro de importancia alto oculta el detalle específico que se busca.
Eventos significativos específicos donde no se quiere ruido crudo: niveles [2] (opcionalmente [2, 3]).
Detalle verbatim exacto o forense: si el detalle no está ya en contexto, profundiza por linaje: busca en niveles [3] para encontrar el hilo relevante, luego usa inspect_memory en el resultado para ver las reflexiones de nivel 2 que consolidó, y luego inspecciona esas para llegar a las memorias crudas subyacentes. La búsqueda directa en niveles [1] funciona cuando conoces la redacción exacta para coincidir.

Las mezclas de niveles son legítimas; ajusta el umbral de importancia a la pregunta en lugar de configurarlo siempre alto. Solo las reflexiones (niveles 2 y 3) tienen calificaciones de importancia.

Las descripciones de herramientas servidas enseñan este manual a cada modelo conectado automáticamente.

Cada fila de resultado está etiquetada con su tier, y las filas de reflexión incluyen su importance.

Búsqueda por fecha

date_search_memories recupera memorias de una ventana de tiempo específica: from (fecha ISO 8601 u hora-fecha obligatoria), opcionalmente to, query, tiers, importance y max_tokens (1000 a 200000). Omite query para una revisión cronológica; inclúyelo para clasificar por relevancia dentro de la ventana. Las páginas truncadas devuelven cursores de continuación next_to / next_from. Frases relativas como "últimamente" deben resolverse a fechas ISO concretas antes de llamar.

Autenticación y alcances

MemoryRouter ejecuta un servidor de autorización OAuth 2.1 completo con PKCE (S256), registro dinámico de clientes, Documentos de Metadatos de ID de Cliente, rotación de tokens de actualización y revocación.

Existen cuatro alcances y son independientes:

Alcance	Otorga
`memories:read`	Recuperación, estado e inspección de linaje
`memories:write`	Guardar nuevas memorias
`memories:reflect`	Retiro y confirmación de consolidación
`memories:delete`	Eliminación por memoria y de todo el vault

Deliberadamente no hay jerarquía ni alcance de administrador. memories:write no otorga recuperación, la autoridad de reflexión no otorga eliminación y la autoridad de eliminación nunca se hereda de la escritura. Un conector configurado para guardar notas, por lo tanto, no puede borrar tu vault.

La autorización por defecto es de solo lectura. Los clientes solicitan más solo cuando lo necesitan, y el servidor responde a una llamada con alcance insuficiente con un desafío de reautorización en lugar de realizar la acción.

La aplicación de solo lectura está en capas

Un token OAuth de solo lectura también se degrada en la capa de clave de API posterior, por lo que incluso un error interno de enrutamiento no puede convertir una conexión de lectura en una de escritura. Las convenciones existentes de clave de solo lectura (modos mk_ro_, mk-ro- y :read /:off) siguen funcionando y nunca se amplían.

Vaults: personal, de proyecto y de organización

Una conexión OAuth está vinculada a un vault, elegido durante el inicio de sesión.

Ese es todo el modelo de aislamiento, y vale la pena ser precisos al respecto:

Los vaults personales, de proyecto y de organización son vaults separados. Tú eliges cuál usa una conexión cuando la autorizas.
Para cambiar de vault, desconecta y vuelve a conectar el conector y elige un vault diferente.
Los "identificadores" de proyecto y organización que aparecen dentro de una conversación son etiquetas de comportamiento para compatibilidad, no argumentos verificados por el servidor. Las herramientas MCP actualmente no aceptan un parámetro de proyecto o vault, por lo que un modelo no puede seleccionar ni escapar de un alcance pidiéndolo.

Si necesitas aislamiento estricto, usa un vault separado y una conexión separada. No confíes en las etiquetas de alcance conversacional como límite de seguridad.

Configuración por plataforma

El selector canónico separa conexión, captura e importación histórica:

Plataforma	Ruta recomendada	Captura	Importación histórica
Claude	Revisa y agrega el conector personalizado; Free admite uno	Dirigida por el modelo	No
Claude Cowork	Conector personalizado (opcionalmente, skill/plugin de repositorio)	Dirigida por el modelo	No hay importador de archivos compatible
ChatGPT	Configuración manual de MCP en modo Developer; no aparece en el directorio de plugins	Dirigida por el modelo	No
Claude Code	`npx -y memoryrouter-claude init`	Hooks automáticos de prompt/final tipados	No
Codex	`npx -y memoryrouter-codex init --scope user` más OAuth	Hooks automáticos de ciclo de vida	No hay importador de archivos de ChatGPT compatible
OpenClaw	`openclaw plugins install npm:mr-memory`	Hooks automáticos de relay	Sí, `openclaw mr upload` separado
Otros clientes MCP	Agrega el endpoint según el cliente	Depende del cliente	No

"Dirigida por el modelo" significa que la IA decide si y cuándo buscar o guardar. No está garantizado en cada turno. Una conexión hace posibles futuras llamadas a herramientas; nunca implica que los chats históricos fueron importados. La compatibilidad genérica con MCP debe probarse por cliente: el soporte de Streamable HTTP por sí solo no prueba el descubrimiento/llamada de OAuth, el alcance, las herramientas o el comportamiento de los recursos.

Claude Code, Codex y OpenClaw usan hooks locales fuera del transporte MCP remoto genérico. Claude Code 2.1.0 captura de forma duradera un prompt tipado más una respuesta final visible para el usuario de un turno completado y excluye los datos de transcripción de herramientas/intermedias. Los hooks de Codex requieren una clave de API de MemoryRouter además de OAuth. OpenClaw usa hooks de relay; las claves de inferencia y de proveedor permanecen en OpenClaw.

Consulta la comparación de plataformas para planes, estado de distribución/listado, unidades de captura exactas, limitaciones y límites de aceptación manual actuales.

Solución de problemas

El cliente dice que se requiere autenticación. Esperado en el primer uso. El servidor responde a llamadas protegidas no autenticadas con un 401 y un desafío WWW-Authenticate para que tu cliente abra el flujo de conexión. Inicia sesión y reintenta.

Se rechaza un guardado o borrado por alcance insuficiente. A la conexión le falta memories:write o memories:delete. Esto no es reintentable; desconecta, reconecta y aprueba el alcance. ChatGPT muestra esto como un aviso de reautorización.

La recuperación no devuelve nada. Confirma con memory_status que estás conectado al vault que esperas. Una causa común es estar conectado a un vault diferente del que contiene los recuerdos.

Claude o ChatGPT nunca usan memoria. En esas superficies, el uso de herramientas es dirigido por el modelo. Pide explícitamente ("revisa mi memoria para…"), o usa Claude Code / Codex donde los hooks lo hacen determinista.

Una herramienta de la que leíste no existe. Solo existen las diez herramientas anteriores. Los argumentos de proyecto del lado del servidor no están implementados.

La consolidación se rechaza por alcance insuficiente. consolidate_memories y commit_reflections necesitan el alcance memories:reflect. Desconecta, reconecta y aprueba el acceso de reflexión cuando tu cliente lo solicite.

Para clientes con un comando de doctor, ejecuta npx memoryrouter-claude doctor o npx memoryrouter-codex doctor para un diagnóstico local.

Endpoints de descubrimiento

Endpoint	Propósito
`/.well-known/oauth-protected-resource/mcp`	Metadatos de recursos protegidos RFC 9728
`/.well-known/oauth-authorization-server`	Metadatos del servidor de autorización RFC 8414

El valor anunciado de resource es la URL completa de /mcp, que coincide con lo que escribes en el cliente, y los tokens de acceso están vinculados a ese mismo recurso RFC 8707.

Privacidad y eliminación

Los recuerdos se almacenan en el vault que seleccionaste durante OAuth; no se comparten entre vaults.
memory_status devuelve una referencia de vault opaca. Tu clave de memoria nunca se expone al modelo, en la salida de herramientas ni en una reclamación de token legible por el cliente.
La eliminación de todo el vault es permanente y se confirma contra el almacenamiento primario y el reflejado.
La eliminación por recuerdo está disponible mediante la herramienta delete_memories o el panel de control.

Próximos pasos

Ver la integración · Crear una cuenta · Todas las integraciones

[

Herramientas de codificación

Conecta clientes de codificación a través de configuraciones de proxy o MCP compatibles, con configuración específica del cliente y límites de compatibilidad.

](https://docs.memoryrouter.ai/coding-tools)[

LangChain

Agrega herramientas explícitas de retención y recuperación a aplicaciones Python de LangChain con langchain-memoryrouter.

](https://docs.memoryrouter.ai/langchain)