Qu’est-ce que Memory (reference server) ?
Memory est l'un des sept serveurs de référence encore maintenus dans modelcontextprotocol/servers ; il n'a pas été déplacé vers servers-archived. Il stocke ce qu'un modèle apprend comme un petit graphe de connaissances : des entités (une personne, un projet), des relations dirigées entre elles, et de courtes observations textuelles attachées à chaque entité. Neuf outils créent, lisent, cherchent et suppriment ces enregistrements, et tout le graphe est aussi exposé comme la ressource memory://knowledge-graph.
Le graphe vit dans un seul fichier JSONL local, défini avec MEMORY_FILE_PATH ; par défaut il se trouve dans le répertoire d'installation du serveur. Faites-le tourner avec npx -y @modelcontextprotocol/server-memory, qui a besoin de Node.js 24 ou plus récent depuis la version 2.0.0 (19 octobre 2026), ou l'image Docker mcp/memory avec un volume nommé. Aucun compte ni clé n'est impliqué.
Installer Memory (reference server)
npx -y @modelcontextprotocol/server-memoryMemory (reference server) vaut-il le coup ?
Memory est un point de départ solide et inspectable pour la mémoire d'agent personnelle, et un mauvais choix une fois que le graphe dépasse ce qu'un modèle peut survoler. Sa force est que rien n'est caché : la mémoire est un fichier texte que vous pouvez ouvrir, comparer, sauvegarder ou supprimer, et rien ne quitte la machine.
La récupération est la partie faible. Dans le code source, search_nodes est une correspondance de sous-chaîne insensible à la casse sur les noms, types et texte des observations, avec les requêtes plafonnées à 2 048 caractères, et sans embeddings ni classement. Demandez « mon manager » quand l'observation dit « reporte à Priya » et rien ne revient. read_graph évite cela en renvoyant tout, ce qui est bien pour quelques dizaines d'entités et devient une facture de contexte à mesure que le fichier grandit. Les services de mémoire dédiés, et la mémoire intégrée à beaucoup d'applis de chat et d'agents de codage, tentent le rappel sémantique que ce serveur ne fait pas.
Les versions récentes ont corrigé les problèmes de perte de données qui rendaient le partage risqué. Depuis la version 1.0.0, chaque outil d'écriture prend un fichier de verrou, si bien que deux clients pointés vers un fichier ne rejettent plus les changements l'un de l'autre ; les lignes que le serveur ne peut pas analyser sont gardées plutôt que supprimées à la prochaine sauvegarde ; et le fichier garde des permissions 0600. Le verrou dépend de la création exclusive de fichier, si bien que le README avertit qu'un système de fichiers réseau ne peut toujours pas être partagé en sécurité.
Le modèle décide quoi retenir, ce qui est à la fois la conception et le risque. Sans un prompt système lui disant quand stocker et chercher les choses, le rappel est erratique, et le texte que l'agent a lu dans un e-mail ou une page web peut être écrit comme une observation et rejoué dans chaque session ultérieure. L'issue #4117 demande des quotas, de la rédaction et des garde-fous sur les opérations destructrices ; aucun n'est sorti.
Là où il fait la différence
Un développeur solo qui utilise Claude Desktop et Claude Code sur un seul portable
Faire que les deux clients se souviennent des conventions de projet et des personnes entre les sessions
Pointez les deux vers le même MEMORY_FILE_PATH ; le fichier de verrou sérialise les écritures pour qu'aucun ne perde les changements de l'autre. C'est gratuit et local, mais le rappel dépend d'un prompt système disant au modèle de chercher dans la mémoire au début de chaque chat.
Un ingénieur plateforme qui prototype une couche de mémoire d'agent
Essayer un modèle de mémoire entité-et-relation avant de s'engager sur un stockage vectoriel
Le format JSONL est facile à inspecter et migrer, si bien que les expériences ne coûtent que du temps. Attendez-vous à le remplacer une fois que les requêtes ont besoin de correspondre au sens plutôt qu'aux mots exacts, ou une fois que plusieurs utilisateurs partagent une mémoire.
Un relecteur de sécurité qui approuve les serveurs MCP pour une équipe d'ingénierie de 50 personnes
Décider si le personnel peut faire tourner un serveur de mémoire sur les portables de travail
Tout reste dans un fichier sur le portable, si bien qu'il n'y a pas de sous-traitant tiers à évaluer. Les risques à peser sont le texte injecté qui persiste entre les sessions et l'emplacement de fichier par défaut ; exiger MEMORY_FILE_PATH sur un chemin chiffré et sauvegardé couvre le second.
Avant de vous engager
- Mise en route
- Ajoutez npx -y @modelcontextprotocol/server-memory à la configuration du client (le README a des extraits Claude Desktop et VS Code) et définissez MEMORY_FILE_PATH ; Node.js 24+ est nécessaire à partir de 2.0.0. Les outils marchent au redémarrage, mais un rappel utile a besoin d'un prompt système disant au modèle quand lire et écrire.
- Intégrations
- Neuf outils : create_entities, create_relations, add_observations, delete_entities, delete_observations, delete_relations, read_graph, search_nodes et open_nodes. Six des neuf écrivent ; le graphe est aussi une ressource MCP à laquelle on peut s'abonner.
- Données et confidentialité
- Lit et écrit uniquement son fichier JSONL ; pas de réseau ni d'identifiants. Tout ce que l'agent a lu peut être sauvegardé comme une observation et réinjecté dans des chats ultérieurs, si bien qu'une injection de prompt peut survivre à la session qui l'a portée.
- Coût à grande échelle
- Gratuit, sans limites de débit. Le coût est le contexte : read_graph renvoie le graphe entier, si bien que son coût en tokens croît avec chaque entité et observation stockée.
- Limites
- Recherche par sous-chaîne, plafond de requête de 2 048 caractères ; pas d'embeddings, de classement, d'accès multi-utilisateur ni de quotas. Dangereux sur les systèmes de fichiers réseau ; un seul message JSON-RPC de plus de 10 Mio ferme la connexion stdio en 2.0.0.
Les points forts
- La mémoire est un seul fichier JSONL local que vous pouvez lire et éditer
- Le verrouillage d'écriture depuis 1.0.0 arrête les mises à jour perdues entre clients
- Pas de compte, de clé ni d'accès réseau
Les points faibles
- Recherche par sous-chaîne uniquement, pas de rappel sémantique
- Repose sur le fait d'inciter le modèle à stocker et chercher
- Pas de quotas ni de rédaction ; le texte injecté peut persister
Idéal pour
Les amateurs et développeurs qui apprennent comment fonctionne la mémoire persistante via MCP.
Alternatives à Memory (reference server)
Memory (reference server) : questions fréquentes
- Memory (reference server) vaut-il le coup ?
- Un fichier local lisible et une recherche par sous-chaîne en font un carnet correct pour un agent, et une mémoire à long terme faible une fois que le graphe grandit. Nous lui donnons 3.5 sur 5.
- Combien coûte Memory (reference server) ?
- Gratuit et open source.
- Quels sont les inconvénients de Memory (reference server) ?
- Recherche par sous-chaîne uniquement, pas de rappel sémantique; repose sur le fait d'inciter le modèle à stocker et chercher; pas de quotas ni de rédaction ; le texte injecté peut persister.
- À qui s’adresse Memory (reference server) ?
- Les amateurs et développeurs qui apprennent comment fonctionne la mémoire persistante via MCP.
- Combien coûte Memory (reference server) pour une équipe ou en production ?
- Gratuit, sans limites de débit. Le coût est le contexte : read_graph renvoie le graphe entier, si bien que son coût en tokens croît avec chaque entité et observation stockée.
- Memory (reference server) est-il sûr pour les données de l’entreprise ?
- Lit et écrit uniquement son fichier JSONL ; pas de réseau ni d'identifiants. Tout ce que l'agent a lu peut être sauvegardé comme une observation et réinjecté dans des chats ultérieurs, si bien qu'une injection de prompt peut survivre à la session qui l'a portée.
- Quelles sont les meilleures alternatives à Memory (reference server) ?
- Les alternatives les plus proches que nous avons testées sont Sequential Thinking (reference server), Filesystem (reference server) et MCP Memory Keeper.
Réponses vérifiées le 23 oct. 2026.