How do I use Relax Memory MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Relax Memory MCP Store a memory: user's preferred language is Python." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Relax Memory MCP

by jgauffin

Overview Schema Related Servers Score Discussions

TypeScript

Local

Relax! Memory MCP

Archived. Claude can now use multiple files for memories.

A persistent memory server for AI agents, built on the Model Context Protocol.

Why this server?

Most AI agents lose context between sessions. Built-in memory features (like Claude Code's MEMORY.md) are plain files the agent must read and write manually — they have no structure, no categories, and no way to list or search entries without reading the entire file.

Relax! Memory MCP fixes this by giving agents structured, persistent memory via tools:

Categorised storage — memories are grouped by category (e.g. config, design, architecture), so an agent can store and retrieve related facts without scanning everything.
Minimal token cost — list_memories returns a lightweight hierarchical index. The agent only fetches full values when it needs them, keeping context windows small.
Upsert semantics — storing a memory with the same category + name overwrites the previous value. No duplicates, no cleanup needed.
Instant persistence — every write is flushed to a single JSON file on disk. Survives crashes, restarts, and agent re-connections.
Zero dependencies at runtime — just Node.js and the MCP SDK. No database, no cloud service, no API key.
Multi-instance friendly — use --dir and --name to run separate memory stores for different projects or agents from the same binary.

Related MCP server: Mem0 MCP Server

Tools exposed

Tool	Description
`add_memory`	Store or update a memory (category, name, description, value)
`get_memory`	Retrieve a specific memory by category and name
`delete_memory`	Delete a memory by category and name
`list_memories`	List all memories as a hierarchical index grouped by category

Installation

npm install
npm run build

This compiles TypeScript into dist/ and makes dist/index.js the executable entry point.

Configuration

Add the server to your MCP client config. Ommit --dir for currently running project.

Claude Code (CLI)

claude mcp add --scope user memory -- node d:/installdir/dist/index.js --dir d:/my-project

Claude Desktop / Claude Code (manual)

Add to your claude_desktop_config.json or .claude.json:

{
  "mcpServers": {
    "memory": {
      "command": "node",
      "args": [
        "d:/src/AI/MCP/Memory/dist/index.js",
        "--name", "Project Memory",
        "--dir", "d:/my-project"
      ]
    }
  }
}

CLI flags

Flag	Default	Description
`--name`	`Memory MCP for current project`	Server name reported to the MCP client (set if you have a general server that all projects shpuld be able to access)
`--description`	`Persistent memory storage`	Server description
`--dir`	Current working directory	Directory where `memories.json` is stored

Running

Start the server directly (stdio transport):

node dist/index.js

Or with flags:

node dist/index.js --dir ./my-project --name "My Project Memory"

The server communicates over stdin/stdout using the MCP stdio transport. It is designed to be launched by an MCP client, not called directly from a browser or HTTP client.

Debugging

Run tests

npm test

Uses Vitest. Tests create temporary directories and verify the full lifecycle: add, get, update, delete, persistence, and hierarchical indexing.

Inspect the stored data

Memories are stored as plain JSON in memories.json inside the configured --dir:

cat memories.json

[
  {
    "name": "tech-stack",
    "category": "architecture",
    "description": "Chosen technology stack",
    "value": "TypeScript, PostgreSQL, OpenLayers"
  }
]

Debug with MCP Inspector

Use the MCP Inspector to interactively call tools:

npx @modelcontextprotocol/inspector node dist/index.js -- --dir .

This opens a web UI where you can invoke add_memory, list_memories, etc. and see the raw JSON responses.

Attach a Node debugger

node --inspect dist/index.js --dir .

Then open chrome://inspect in Chrome or attach from VS Code using a launch configuration:

{
  "type": "node",
  "request": "launch",
  "name": "Debug Memory MCP",
  "program": "${workspaceFolder}/dist/index.js",
  "args": ["--dir", "."],
  "outFiles": ["${workspaceFolder}/dist/**/*.js"]
}

License

MIT

Available Tools

4 tools

add_memoryA

Store or update a memory. Overwrites if same category+name exists.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Memory name
`value`	Yes	The memory content
`category`	Yes	Category to group under
`description`	Yes	Brief description of what this memory is

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses a key behavioral trait: overwriting when the same category+name exists. This is non-obvious and important for an upsert operation. However, it doesn't mention return values or error conditions, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the main purpose, and includes only necessary information. There is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and the absence of an output schema, the description covers the core behavior adequately. It explains the upsert semantics and the overwrite key. However, it omits any mention of return type or success indicators, which would be helpful for a write operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by specifying that the combination of 'category+name' is the uniqueness key for overwriting, which is not directly stated in the schema. This clarifies how the parameters interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Store or update') and identifies the resource ('a memory'). It also distinguishes itself from siblings (get/delete/list) by focusing on write operations. The overwrite behavior adds precision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating or updating memories, but it does not explicitly state when to use this tool versus alternatives like 'get_memory' or 'delete_memory'. There are no stated exclusions or preferences, so guidance is minimal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_memoryA

Delete a memory by category and name.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`category`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It only says 'delete' without mentioning irreversibility, whether the operation is destructive, or what happens if the memory does not exist. The verb implies destruction but lacks explicit disclosure of side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no waste, front-loaded with the verb 'Delete'. It is appropriately concise for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description should provide more context. It omits return behavior, error handling, and whether the deletion is permanent. For a destructive tool, this is a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It merely restates the parameter names ('category and name') without explaining their meaning, valid values, or constraints. This adds minimal value beyond the schema's property names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete'), the resource ('a memory'), and the scope ('by category and name'). It inherently distinguishes itself from sibling tools (add/get/list) by specifying the delete operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for removing memories, which is clear context. However, it does not explicitly mention alternatives or when not to use it, so it misses the 'exclusions' level of guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_memoryA

Retrieve a specific memory by category and name.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`category`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose safety and behavioral traits. It only says 'Retrieve', which implies read-only but does not explicitly state that it has no side effects, what happens if the memory does not exist, or return format. This is a significant gap for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence, directly stating the action and the key parameters. It is efficient and easy to parse, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should at least mention return value or error behavior. It covers the basic purpose but lacks information about what the tool returns on success or failure, which is important for a retrieval operation. As a simple tool, it is minimally viable but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions 'by category and name' but adds no extra meaning beyond rephrasing the schema property names. No details on format, constraints, or how these parameters are used in the lookup.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Retrieve' and identifies the resource 'memory' with scope 'specific memory by category and name'. This clearly distinguishes the tool from siblings like list_memories (which lists) and add/delete_memory (which modify).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'specific memory' implies this is for fetching a single, known memory rather than listing all, providing clear context for use. However, it does not explicitly state when not to use it or name list_memories as an alternative, so a small deduction applies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_memoriesA

List all memories as a hierarchical index grouped by category.

ParametersJSON Schema

Name	Required	Description	Default
`include_description`	No	Include description in the index

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosing behavior. It states the output is a hierarchical index grouped by category, implying a read-only operation, but doesn't explicitly confirm no side effects or describe any return format details beyond grouping. It's adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly states the purpose and key output characteristics without any filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool with one optional parameter and no output schema, the description adequately conveys what the tool returns (hierarchical index) and its scope (all memories). It could mention more about the structure of entries, but the available information covers the essential expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, include_description, is fully documented in the schema with a clear description and default value. The tool description adds no additional meaning, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' with the resource 'memories' and clarifies scope as 'all memories' with a 'hierarchical index grouped by category.' This clearly distinguishes it from sibling tools like add_memory, get_memory, and delete_memory, which perform different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for retrieving a full overview of all memories, contrasting with get_memory for individual retrieval. While it doesn't explicitly name alternatives or exclusions, the context makes the appropriate use case clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv1.0.0Aug 10, 2026
- First observedadd_memory
- First observeddelete_memory
- First observedget_memory
- First observedlist_memories

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: add/update, retrieve, delete, and list. No overlap or ambiguity exists.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (add_memory, get_memory, delete_memory, list_memories). The pluralization of 'list_memories' is a minor stylistic variance but does not break the pattern.

Tool Count5/5

With only 4 tools, the set is well-scoped and perfectly sized for a simple memory storage service. Each tool serves a necessary CRUD function.

Completeness5/5

The tool surface covers the complete lifecycle of memories: create/update, read, delete, and list. No obvious gaps exist for the stated domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

XMemo AOAuth
io.github.yonro
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Autonomous Agents Knowledge & Memory
19212
Synap Memory A
ai.maximem
Persistent memory for AI agents — log and recall conversation context over MCP.
Knowledge & Memory AI & Machine Learning
4248
mifactory-agent-memory C
io.github.mifactory-bot
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
22
mem0OAuth
io.github.mem0ai
Persistent memory for AI agents: add, search, update, and delete long-term memories.
Knowledge & Memory AI & Machine Learning
2

Related MCP Servers

MCP-Mem0
Knowledge & Memory Vector Databases Autonomous Agents
coleam00
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides AI agents with persistent memory capabilities through Mem0, allowing them to store, retrieve, and semantically search memories.
Updated a year ago (2025-04-13 01:17 UTC)
681
MIT
Mem0 MCP Server
Knowledge & Memory RAG Systems
ryaker
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server that integrates AI assistants with Mem0.ai's persistent memory system, allowing models to store, retrieve, search, and manage different types of memories.
Updated a year ago (2025-08-12 00:12 UTC)
16
MIT
Eternity MCP
Knowledge & Memory Vector Databases RAG Systems
danttis
A
license
Not graded
quality
D
maintenance
A privacy-focused local memory server that provides long-term semantic storage and retrieval for AI agents using SQLite and ChromaDB. It enables LLMs to persist and query text, chat histories, and PDF documents across sessions through the Model Context Protocol.
Updated 7 months ago (2026-01-24 05:30 UTC)
MIT
GroundMemory
Knowledge & Memory Search
huss-mo
A
license
Not graded
quality
C
maintenance
An MCP-native, local-first memory server that gives AI agents persistent, structured memory across sessions and tools, enabling them to maintain identity and context without reconfiguration.
Updated 3 months ago (2026-05-26 16:39 UTC)
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jgauffin/memory-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server