Automatically manages project configurations to ensure that the local chat history stored in the journal directory is excluded from version control via gitignore rules.
Records AI conversation turns, including user inputs, agent responses, and code modifications, into local Markdown journal files to create a searchable and persistent history.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenClaw Memory Search my history for the solution we found for the database timeout bug."
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.
Your AI conversations disappear after every session. OpenClaw Memory fixes that.
Every time you chat with an AI coding assistant, valuable context — decisions, solutions, debugging steps — vanishes when the session ends. The next session starts from zero.
OpenClaw Memory automatically records every conversation turn to local Markdown files, making your entire AI chat history searchable and browsable. No cloud, no database — just plain text files in your project.
You chat with AI → Every turn auto-saved to .openclaw_memory/journal/2026-02-24.md
→ Search past conversations via MCP tool or web viewerEach journal entry captures the complete conversation: timestamps, model used, your input, the AI's full response, and any code changes made.
Related MCP server: Amber
1. Install
pip install claw-memory2. Initialize in your project
cd your-project
claw-memory initThis creates:
.openclaw_memory/journal/ — where chat history lives
.cursor/mcp.json — connects the MCP server to Cursor
.cursor/rules/memory.mdc — tells the AI agent to auto-record
3. Restart Cursor — that's it. Every conversation is now being recorded.
The AI agent can search your history automatically. Just ask naturally:
"We discussed this before, what was the solution?"
"Last time we fixed a similar bug, how did we do it?"
The agent will call memory_search() behind the scenes and find matching conversations.
# Single project (current directory)
claw-memory web
# Multiple projects — scan a parent directory
claw-memory web --scan-dir ~/projectsOpens a browser-based viewer where you can:
Browse journal files by date
Full-text search across all conversations
Dark/light mode
Multi-project view: use --scan-dir to scan a parent directory and browse all projects in one place, with sidebar grouped by project
Each conversation turn is saved as Markdown:
## 14:32 | claude-4-opus
### User
How do I fix the N+1 query problem in the user list endpoint?
### Agent
The issue is in `api/users.py` where each user triggers a separate query for their roles...
### Code Changes
- `api/users.py` (modified)
- `tests/test_users.py` (modified)Tool | Purpose |
| Record a complete conversation turn |
| Append to the last turn (for long responses) |
| Search chat history by keyword |
All data is stored locally in .openclaw_memory/journal/ as plain Markdown files — one file per day. No database, no cloud sync. You own your data.
The .openclaw_memory/ directory is auto-gitignored to prevent accidental commits of chat history.
Each project gets its own .openclaw_memory/ directory. MCP tools always operate on the current project only.
To view multiple projects together, use the web viewer with --scan-dir.
Apache 2.0
Record one full conversation turn to today's journal.
You MUST pass the complete user message and your entire reply — no truncation, no summary, no "..." or "see above". If your reply is very long, pass the first part here then use memory_log_conversation_append() for the rest.
Args:
user_message: The user's full message in this turn.
agent_response: Your full reply (complete text, every paragraph).
model: The model used for this response (e.g. "claude-4-opus").
code_changes: Optional. Files created/modified, e.g. "- src/foo.py (created)".
title: Optional. One-line summary for this turn; if empty, derived from first line of user_message.
| Name | Required | Description | Default |
|---|---|---|---|
| user_message | Yes | ||
| agent_response | No | ||
| model | No | ||
| code_changes | No | ||
| title | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains temporal scoping ('today's journal'), integrity requirements ('complete' messages), and default title derivation logic. However, lacks disclosure on error handling, idempotency, or size limits before requiring the append sibling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear progression: purpose → constraints → workflow guidance → parameter docs. The Args section is necessary given 0% schema coverage. Slightly verbose format but every sentence earns its place by conveying required usage constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (per context signals), description appropriately omits return value details. Covers primary workflow and sibling coordination. Minor gap: does not specify maximum length thresholds before requiring append tool, which would be useful for 'complete' message handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (only titles, no descriptions), but the Args section compensates fully by providing semantic meaning for all 5 parameters, including format examples like 'claude-4-opus' for model and '- `src/foo.py` (created)' for code_changes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb+resource ('Record one full conversation turn to today's journal') and distinguishes from siblings by explicitly naming memory_log_conversation_append() for handling long replies, clearly differentiating initial logging vs continuation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit conditional guidance: 'If your reply is very long, pass the first part here then use memory_log_conversation_append() for the rest.' Also states mandatory constraints ('You MUST pass the **complete** user message... no truncation').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append more text to the last Agent section in today's journal.
Use after memory_log_conversation() when your full reply did not fit in one call. Can be called multiple times; each chunk is appended to the same turn.
Args: agent_response_chunk: Next part of your reply to append (no truncation).
| Name | Required | Description | Default |
|---|---|---|---|
| agent_response_chunk | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It effectively discloses key behaviors: it appends to 'today's journal', maintains 'the same turn' across multiple calls, and guarantees 'no truncation'. Missing minor details like error cases if no previous section exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences/stanzas: first defines the action, second explains the workflow timing and multi-call behavior, third documents the parameter. No wasted words; information is front-loaded with the core action in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema exists (so return values need not be described), the description is complete. It adequately explains the journaling workflow, chunking mechanism, and parameter semantics. Could be improved by mentioning error states or auth requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no property descriptions in the JSON schema). The description compensates by documenting the parameter in the Args section, explaining it is the 'Next part of your reply' and adding the 'no truncation' constraint which is not inferable from the schema type alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Append more text') on a specific resource ('the last Agent section in today's journal'). It clearly distinguishes this tool from sibling 'memory_log_conversation' by explaining this is for continuation/appending when a reply doesn't fit in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use after memory_log_conversation() when your full reply did not fit in one call') and includes repetition guidance ('Can be called multiple times'). It clearly references the sibling tool as the prerequisite/primary alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search chat history for a keyword, returning full conversation turns.
Args: query: Text to search for (case-insensitive). since: Only search from this date onward (YYYY-MM-DD format). max_results: Max turns to return (0 = no limit).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| since | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses case-insensitive matching and that results include 'full conversation turns,' but omits behavioral details like empty result handling, search scope limitations, or result ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with the main purpose front-loaded in the first sentence. The Args section, while slightly informal in formatting, efficiently documents three parameters without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately avoids repeating return value details. However, for a tool with no annotations and 0% schema coverage, it could further clarify behavior regarding date boundaries or result ranking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description effectively compensates via the Args section. It adds critical semantics: case-insensitive matching for 'query', date format constraint (YYYY-MM-DD) for 'since', and business logic clarification (0 = no limit) for 'max_results'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb (search), resource (chat history), and output format (full conversation turns). It implicitly distinguishes from siblings memory_log_conversation and memory_log_conversation_append by function (retrieval vs. storage), though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (memory_log_conversation, memory_log_conversation_append). It does not clarify that this is for retrieval while the siblings are for persistence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.1memory_log_conversationmemory_log_conversation_appendmemory_searchThe three tools have clearly distinct purposes with no overlap: memory_log_conversation records a complete conversation turn, memory_log_conversation_append extends that recording when needed, and memory_search retrieves past conversations. Each tool serves a unique function in the conversation logging workflow.
The naming follows a consistent memory_verb_noun pattern with minor deviations: memory_log_conversation and memory_search fit perfectly, while memory_log_conversation_append is slightly longer but maintains the same prefix structure. All use snake_case consistently.
Three tools is ideal for this server's purpose of conversation memory management. It covers the core workflow of logging, appending when responses are long, and searching history without being overly complex or insufficient for the domain.
The toolset provides solid coverage for basic conversation memory operations: logging, extending logs, and searching. A minor gap exists in lacking update/delete capabilities for recorded conversations, but agents can work effectively with the provided CRD (create, read, delete via omission) functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for AI agents — log and recall conversation context over MCP.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/liuhao6741/openclaw-memory'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
