Claude Conversation Memory System
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLAUDE_MEMORY_PATH | No | Override the default storage location (~/claude-memory/) | ~/claude-memory/ |
| CLAUDE_MCP_LOG_FORMAT | No | Switch between human-readable text logs (default) and structured JSON logs for production (json or text) | text |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_conversationsC | Search through stored Claude conversations for relevant content |
| add_conversationB | Add a new conversation to the memory system.
|
| update_conversationA | Update fields on an existing conversation in place. Pass Tag ops: Metadata fields (tags, conversation_type, session_id, user_id) are validated/sanitized before storage since this data may originate from external imports.
|
| get_conversationA | Retrieve a stored conversation by an ID returned from a search tool. The complete record is read from the authoritative JSON store. Content is
capped to protect the model context; increase |
| generate_weekly_summaryC | Generate a summary of conversations from the past week |
| search_by_topicC | Search conversations by a specific topic |
| search_by_tagA | Search conversations tagged with a specific tag (D2 metadata field). Tags are universal metadata populated by the importers (e.g.
|
| search_by_session_idA | Find all conversations sharing a session_id (D2 metadata field). Useful for reconstructing a multi-turn session that spans several stored conversation records (e.g. a Cursor working session, a Claude thread continued across days). Results are sorted chronologically. Requires SQLite FTS. |
| search_by_conversation_typeB | Search conversations by conversation_type (D2 metadata field). Typical values: |
| get_search_statsA | Get search engine statistics and performance information |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools target distinct resources or actions: add/get/update are clear CRUD operations, and the metadata-specific searches (by_tag, by_session_id, by_conversation_type) are well-scoped. However, search_conversations and search_by_topic overlap conceptually, and the distinction between generic content search and topic search is not sharply defined.
The naming is predominantly verb_noun snake_case, with add_conversation, get_conversation, update_conversation, and generate_weekly_summary following a clear pattern. The search tools are slightly inconsistent because some use search_conversations while others use search_by_tag/search_by_session_id/search_by_conversation_type, but the style is still recognizable and predictable.
Ten tools is a reasonable size for a conversation memory system, and the CRUD core plus search variants cover most expected workflows. The count is slightly search-heavy, with six retrieval-related tools, but none feel redundant enough to remove outright.
The system covers add, get, update, search, summary, and stats, which handles the core lifecycle for stored conversations. Notable gaps include no delete/forget operation, no list-all conversations tool, and no dedicated search_by_user_id even though user_id is described as a universal metadata field.