collective-memory
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., "@collective-memoryrecall recent decisions and context"
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.
Collective Memory
MCP server for persistent, semantic memory across AI sessions. Store context, decisions, and learnings — recall them later with natural language search.
Why
AI assistants forget everything between sessions. Collective Memory fixes that. Store what matters, search by meaning, build context that compounds.
Related MCP server: Selti
Features
Semantic search — Find memories by meaning, not keywords (OpenAI embeddings + LanceDB)
Automatic deduplication — Won't store near-duplicates (>95% similarity)
Project scoping — Organize memories by project
Type classification — Categorize as
decision,milestone,context,learning, orsession_summaryZero config storage — Embedded vector database, no server required
Installation
npm install -g collective-memoryOr clone and build:
git clone https://github.com/Hustada/collective-memory.git
cd collective-memory
npm install
npm run buildSetup
1. Get an OpenAI API key
Required for embeddings. Get one at platform.openai.com.
2. Add to Claude Code
Add to ~/.claude/settings.json under mcpServers:
{
"mcpServers": {
"collective-memory": {
"type": "stdio",
"command": "npx",
"args": ["collective-memory"],
"env": {
"OPENAI_API_KEY": "sk-..."
}
}
}
}Or if installed from source:
{
"mcpServers": {
"collective-memory": {
"type": "stdio",
"command": "node",
"args": ["/path/to/collective-memory/dist/index.js"],
"env": {
"OPENAI_API_KEY": "sk-..."
}
}
}
}3. Add usage instructions to CLAUDE.md
Add to your global ~/.claude/CLAUDE.md:
## Memory
Collective Memory is active. Two tools:
- `remember(content, project?, type?, tags?)` — Persist important context
- `recall(query, project?, type?, limit?)` — Search memory
**On session start**: Run `recall("recent decisions and context")` to load relevant memory.
When to remember: after decisions, milestones, completed work, learned patterns.
When to recall: session start, context switches, referencing past work.
Types: decision, milestone, context, learning, session_summary.Tools
remember
Store a memory with semantic embedding.
Parameter | Type | Required | Description |
| string | yes | The memory to store — be specific and self-contained |
| string | no | Project context (e.g., "myapp", "client-x") |
| string | no | One of: decision, milestone, context, learning, session_summary |
| string[] | no | Tags for categorization |
Returns the stored memory ID, or existing ID if deduplicated.
recall
Search memories by semantic similarity.
Parameter | Type | Required | Description |
| string | yes | Natural language search query |
| string | no | Filter to specific project |
| string | no | Filter to specific memory type |
| number | no | Max results (default: 10) |
Returns array of matching memories with similarity scores.
CLI
Also usable from command line:
# Store a memory
collective-memory remember --content "Decided to use PostgreSQL for the auth service"
# Search memories
collective-memory recall --query "database decisions" --limit 5
# Pipe content from stdin
echo "Long content here" | collective-memory remember --content-stdin --project myappConfiguration
Environment Variable | Default | Description |
| (required) | OpenAI API key for embeddings |
|
| Storage location |
How it works
Store: Content is embedded using OpenAI's
text-embedding-3-small(768 dimensions)Dedupe: Before storing, checks for >95% similar existing memories
Index: Stored in LanceDB, an embedded vector database
Search: Queries are embedded and matched via cosine similarity
Data
Memories are stored locally at ~/.collective-memory/data (or COLLECTIVE_MEMORY_PATH). It's a LanceDB database — portable, no server process.
To export memories:
npm run export # Outputs to viz/memories.jsonTo visualize:
npm run dash # Opens UMAP visualization at localhost:3333License
MIT
Credits
Built by The Victor Collective.
Available Tools
2 toolsrecallA
Search collective memory. Use at session start, when switching context, when referencing past work.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter to specific memory type | |
| limit | No | Max results to return (default 10) | |
| query | Yes | Natural language search query | |
| project | No | Filter to specific project |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only states 'Search collective memory' without indicating whether it is read-only, destructive, or any other side effects. The agent cannot infer safety or behavior from this.
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 extremely concise with two sentences, the first being the purpose and the second the usage guidelines. It is front-loaded and contains no extraneous information.
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 that there is no output schema and no annotations, the description provides the purpose and usage context but lacks behavioral transparency. It is adequate for a simple search tool but not fully comprehensive.
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?
The input schema has 100% coverage with descriptions for all parameters. The description does not add any additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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 verb 'Search' and resource 'collective memory', providing a clear purpose. However, it does not differentiate from the sibling tool 'remember', which likely has a related function.
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 explicitly specifies when to use the tool: 'at session start, when switching context, when referencing past work.' This provides good guidance, but it does not mention when not to use or contrast with the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberA
Persist important context to collective memory. Use after decisions, completed work, architectural choices, status changes. Be specific and self-contained.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags for categorization | |
| type | No | Memory type: "decision", "milestone", "context", "learning", "session_summary" | |
| content | Yes | The memory to store — specific, self-contained | |
| project | No | Project context: "companycam", "alvis", "victorcollective", "global" |
TDQS
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 indicates the tool is for persisting data (write operation) and advises specificity, but it fails to disclose key behavioral traits such as whether data can be overwritten, deleted, or if there are any side effects. The description is too minimal to adequately inform an AI agent about the tool's behavior.
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 extremely concise—two sentences that front-load the purpose and immediately follow with usage guidance. Every sentence adds value, and there is no redundancy or fluff.
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 4 parameters, no output schema, and no annotations, the description provides a basic framework but is not fully complete. It lacks information about error handling, persistence guarantees, or any limits. While adequate for simple use, it could be more comprehensive.
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 100%, meaning the input schema already describes each parameter (tags, type, content, project). The tool description adds no additional semantic information beyond the schema, so a baseline score of 3 is appropriate.
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 tool's purpose: 'Persist important context to collective memory.' It uses a specific verb ('persist') and resource ('context to collective memory'), and distinguishes itself from the sibling tool 'recall' by implication (remember stores, recall retrieves). The use cases are explicitly listed: after decisions, completed work, architectural choices, status changes.
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 clear usage context, specifying when to use the tool ('after decisions, completed work, architectural choices, status changes') and gives guidance to be specific and self-contained. However, it does not explicitly state when not to use it or mention alternatives like 'recall', so it falls short of a 5.
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.
2 tool updates
v0.1.2- First observed
recall - First observed
remember
TDQS
Each tool has a clear, distinct purpose: one for storing context and one for retrieving it, with no functional overlap.
Both tool names are single verbs that follow a consistent pattern, making them predictable and easy to distinguish.
Two tools is minimal but appropriate for a focused read/write memory server; slightly thin but not excessive.
The server covers core create and read operations but lacks update or delete functionality, which could hinder management of stored memories.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
An MCP memory server. One memory your agents share — across models, devices and apps.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Persistent memory for AI agents — log and recall conversation context over MCP.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenancePersistent semantic memory server for AI assistants via MCP, enabling long-term context retention and semantic search across conversations.11MIT
- FlicenseNot gradedqualityBmaintenanceA persistent memory server for AI agents using MCP protocol, enabling semantic storage and retrieval of dialogues, documents, and agent states.-
- AlicenseNot gradedqualityBmaintenancePersistent memory MCP server for AI agents that stores, recalls, and searches conversation history, key-value context, and long-term entries across sessions with semantic search and FIFO queues.751-
- FlicenseNot gradedqualityAmaintenanceAn MCP server providing semantic vector search, dual memory engines, and Git version control for AI clients, enabling persistent memory with recall, forget, and rollback capabilities.1-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Hustada/collective-memory'
If you have feedback or need assistance with the MCP directory API, please join our Discord server