A persistent, intelligent long-term memory system for AI agents with BM25 full-text search, auto-tagging, importance scoring, and recency weighting.
store_memory — Save any information (facts, preferences, project details, notes) with a unique key; auto-detects tags and importance (1–10) if omitted.
search_memory — BM25 full-text ranked search across all memories, with optional tag filtering and result limits.
get_relevant_context — Automatically surface the most relevant memories for a given query or task; ideal for injecting context at session start.
update_memory — Modify the content, tags, or importance score of an existing memory by its key.
list_memories — Browse stored memories with optional tag filtering, sorted by recency, importance, or access count.
forget_memory — Permanently delete a specific memory by its key.
memory_summary — Get a high-level overview: total memory count, top tags, most important/accessed memories, and statistics.
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., "@agent-memory-hub store that my favorite color is blue"
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.
Persistent, intelligent, searchable long-term memory for AI agents.
Store facts, preferences, notes, and project context. Retrieve them with full-text BM25 search, importance scoring, and recency weighting. No API keys. No external servers. Works out of the box.
7 powerful tools — store, search, retrieve context, update, list, forget, summarize
BM25 full-text search — proper ranked search with IDF, not just string matching
Auto-tagging — automatically infers categories (preference, project, technical, task, credential, etc.)
Auto importance scoring — detects urgency signals in content
Recency + importance weighting — more relevant memories surface first
Atomic writes — corruption-safe file persistence
Zero dependencies — only the MCP SDK; no native binaries, no Python, no Docker
Configurable storage — override path with AGENT_MEMORY_DIR env var
Related MCP server: MemoryClaw
git clone https://github.com/yourname/agent-memory-hub
cd agent-memory-hub
npm install
npm run buildEdit %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"agent-memory-hub": {
"command": "node",
"args": ["C:\\Users\\HP\\agent-memory-hub\\build\\index.js"]
}
}
}claude mcp add agent-memory-hub -- node "C:\Users\HP\agent-memory-hub\build\index.js"{
"mcpServers": {
"agent-memory-hub": {
"command": "node",
"args": ["C:\\Users\\HP\\agent-memory-hub\\build\\index.js"],
"env": {
"AGENT_MEMORY_DIR": "C:\\Users\\HP\\my-agent-memories"
}
}
}
}Default storage: ~/.agent-memory/memories.json
store_memoryStore any piece of information worth remembering.
key: "user_preferred_language"
content: "User always prefers TypeScript over JavaScript"
tags: ["preference", "technical"] ← auto-detected if omitted
importance: 7 ← auto-scored if omitted
overwrite: true ← upsert: update if key exists, create if notBy default, storing a key that already exists returns an error. Set overwrite: true to silently update the existing memory instead — useful when you want "set this value" semantics without checking first.
search_memoryBM25 full-text search across all memories.
query: "typescript preferences"
limit: 5 ← optional, default 5
tags: ["technical"] ← optional filterget_relevant_contextAuto-retrieve the best memories for a given query. Use this at session start.
user_query: "Help me set up the project authentication"
→ Returns: identity memories, project memories, technical preferencesupdate_memoryModify existing memory content, tags, or importance.
key: "user_preferred_language"
new_content: "User prefers TypeScript, but accepts Python for scripts"
importance: 8list_memoriesBrowse memories with sorting and filtering.
tags: ["project"]
sort: "importance" ← "recent" | "importance" | "access"
limit: 10forget_memoryPermanently delete a memory.
key: "old_api_key"memory_summaryGet a full overview — counts, top tags, most important and most accessed memories.
Memories are stored as plain JSON at ~/.agent-memory/memories.json. Human-readable, easy to backup or inspect.
{
"version": "1.0.0",
"created": "2025-01-01T00:00:00.000Z",
"lastUpdated": "2025-06-01T12:00:00.000Z",
"memories": [
{
"id": "uuid",
"key": "user_preferred_language",
"content": "User prefers TypeScript over JavaScript",
"tags": ["preference", "technical"],
"importance": 7,
"createdAt": "...",
"updatedAt": "...",
"accessCount": 12,
"lastAccessed": "..."
}
]
}The system auto-detects these categories from content:
Tag | Trigger signals |
| prefer, like, love, hate, favorite, avoid |
| project, working on, building, repository |
| I am, my name, I work, my role |
| code, api, database, framework, docker |
| todo, must, deadline, remind |
| password, secret, token, api key |
| note, remember that, fyi, heads up |
| name is, email, phone, contact |
| config, setting, env var, port, url |
npm run dev # watch mode
npm run build # production buildMIT
Permanently delete a specific memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The memory key to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the irreversible nature of the action ('permanently delete'), which is valuable. However, it does not mention side effects, permissions required, or error handling, leaving gaps.
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 a single, clear sentence with no redundant or extraneous information. It efficiently conveys the essential purpose.
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 simplicity of the tool (one parameter, no output schema), the description is fairly complete. It covers the action and irreversibility. However, it could add information about success/failure behavior or preconditions, but the minimal context is acceptable for a straightforward delete operation.
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 already provides a description for the 'key' parameter ('The memory key to delete'). The tool description adds only the context 'by key', which does not significantly enhance understanding beyond the schema. With 100% schema coverage, baseline is 3.
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 action ('permanently delete'), the resource ('specific memory'), and the identifier ('by key'). It distinctly differentiates from sibling tools like store_memory, update_memory, and list_memories.
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 explicit guidance on when to use this tool versus alternatives, such as update_memory or search_memory. The only clue is the tool's name and the word 'delete', which is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-retrieve the most relevant memories for a given user query or task. Use this at the start of any session or when the user references past context. Returns formatted context ready to inject into your reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| user_query | Yes | The current user query, task description, or topic to find context for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states 'Returns formatted context ready to inject into your reasoning', hinting at output but not detailing read-only nature, potential side effects, or limitations. Adequate but could be more explicit.
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 concise with two sentences, each serving a purpose: defining the tool's action and guiding when to use it. No unnecessary words.
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 simplicity of the tool (one parameter, no output schema), the description covers purpose, usage guidance, and output format sufficiently. It is complete for the tool's complexity.
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% with a clear description for the single parameter 'user_query'. The tool description does not add further meaning beyond what the schema provides, so 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 verb 'Auto-retrieve' and the resource 'memories', specifying the objective 'for a given user query or task'. It effectively distinguishes from sibling tools by implying a broad, automated retrieval versus more specific operations.
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 recommends using the tool 'at the start of any session or when the user references past context', providing clear context for invocation. However, it does not mention when not to use it or alternatives, but the given guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse stored memories with optional tag filtering and sort order.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter to only memories with these tags | |
| limit | No | Max results (default: 20) | |
| sort | No | Sort by: recent (default), importance, or access count |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention that this is a read operation with no side effects, any rate limits, or required permissions. The description merely restates the schema's core functionality without adding behavioral context.
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?
A single, well-structured sentence that conveys the tool's purpose and key affordances without redundancy. Front-loads the action and resource, followed by the modifiable options.
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 lack of annotations and output schema, the description provides a sufficient overview for a simple browse operation with filtering and sorting. It covers the essential distinction from sibling tools, though it omits defaults (e.g., sort order default of 'recent') and does not address potential edge cases like empty results.
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% description coverage for all three parameters, so the description adds only marginal value by labeling the filtering as 'optional' and mentioning sort order. It does not elaborate on the meaning of sort values (e.g., how 'importance' is determined) or default behaviors.
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 uses a specific verb 'Browse' with a clear resource 'stored memories' and highlights optional filtering and sorting, effectively distinguishing it from sibling tools like search_memory or memory_summary.
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 implies usage for casual browsing rather than targeted recall, but it does not explicitly state when to use this tool versus alternatives like search_memory (for specific queries) or memory_summary (for aggregation). No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a high-level overview of what the agent knows — total count, top tags, most important memories, and access statistics. Good for orientation at session start.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It implies a read-only operation and lists output components, but it does not explicitly state non-destructiveness, error handling for empty memories, or performance characteristics.
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 two sentences, front-loaded with the core purpose and ending with a succinct usage hint. Every word is useful, and there is no superfluous 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 no output schema, the description reasonably covers what the tool returns. It mentions four specific components (count, tags, important memories, statistics) and provides a usage context. However, it does not specify the output format or structure, leaving minor gaps.
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 zero parameters, so no parameter documentation is needed. The description adds value by outlining the output content (total count, top tags, etc.), which helps the agent understand what the tool returns beyond the empty schema.
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 provides a high-level overview with specific components: total count, top tags, most important memories, and access statistics. It distinguishes itself from siblings like get_relevant_context or search_memory by focusing on a summary rather than specific queries.
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 suggests using the tool 'for orientation at session start,' which is a positive usage guideline. However, it does not explicitly state when not to use it or mention alternative tools for detailed queries, lacking exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memories using BM25 full-text search with importance and recency weighting. Supports optional tag filtering to narrow scope.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query — natural language or keywords | |
| limit | No | Max results to return (default: 5) | |
| tags | No | Only search memories with these tags |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of transparency. It discloses the BM25 algorithm and importance/recency weighting, which are behavioral details beyond the schema. However, it omits potential limitations like pagination or result format.
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?
Description is two sentences, front-loaded with the core action, and no extraneous information. Every phrase earns its place.
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 no output schema, the description could be more complete by mentioning return format (e.g., relevance score) or error behavior. It adequately covers the main purpose and tag filtering but lacks guidance on handling edge cases or large result sets.
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?
Input schema has 100% description coverage, so baseline is 3. The description adds context for tag filtering ('Supports optional tag filtering to narrow scope') but does not significantly enhance meaning beyond the schema's parameter descriptions. The query parameter description is adequate.
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 'Search memories using BM25 full-text search with importance and recency weighting', providing a specific verb and resource. It distinguishes search from listing or retrieval tools but does not explicitly differentiate from siblings like 'list_memories' or 'get_relevant_context'.
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 implies usage for content-based search but offers no explicit guidance on when to use this tool versus alternatives like 'list_memories' or 'get_relevant_context'. No when-not-to-use or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a new memory — fact, preference, project detail, note, or any information worth remembering. Tags and importance are auto-detected from content if not provided.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Unique snake_case identifier (e.g. "user_name", "preferred_language", "project_deadline") | |
| content | Yes | The memory content — be descriptive and specific for better retrieval | |
| tags | No | Categorization tags (auto-detected if omitted) | |
| importance | No | Importance score 1-10 — higher = retrieved first (auto-scored if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose key behaviors such as whether it overwrites memories with the same key, side effects, or idempotency.
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?
Two concise sentences with the purpose front-loaded and no redundant 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 no output schema or annotations, the description could include more on success/error behavior and whether store_memory overwrites or fails on duplicate keys.
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 description adds value beyond the schema by recommending descriptive content for better retrieval and clarifying auto-detection for tags and importance, which is not in the schema.
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 'Store' and resource 'memory', with explicit examples of memory types (fact, preference, etc.), and it is distinct from sibling tools like forget_memory or update_memory.
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 mentions auto-detection of tags and importance but does not specify when to use this tool over alternatives like update_memory for existing keys or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the content, tags, or importance of an existing memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The memory key to update | |
| new_content | No | Replacement content (omit to keep existing) | |
| tags | No | New tag list — replaces existing tags | |
| importance | No | New importance score 1-10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It states 'update' but does not clarify partial vs full replacement semantics for tags or importance, nor does it mention side effects, permissions, or return value. The schema clarifies 'tags' replaces, but the description omits this detail.
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 a single sentence with key information front-loaded. It is concise but could include a brief note on usage or behavior without becoming verbose.
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?
With no output schema and no annotations, the description is too minimal. It does not explain the return value, confirm the key must exist, or differentiate from sibling tools. The 4-parameter complexity demands more context for correct invocation.
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?
Input schema coverage is 100%, so parameters are already documented. The description lists 'content, tags, or importance' as updatable fields, providing a quick overview but no additional semantic value beyond the schema.
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 specifies the verb 'update', the resource 'memory', and the mutable attributes 'content, tags, or importance'. It differentiates from sibling tools like 'store_memory' (create) and 'forget_memory' (delete) by explicitly stating it operates on an existing memory.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., memory must exist), nor does it contrast with 'store_memory' (for new memories) or 'forget_memory' (for deletion). The agent is left to infer usage context.
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.0.0forget_memoryget_relevant_contextlist_memoriesmemory_summarysearch_memorystore_memoryupdate_memoryMost tools have distinct purposes, but get_relevant_context and search_memory both retrieve memories based on relevance, which could cause confusion. However, descriptions differentiate automatic context retrieval from explicit search.
Majority follow verb_noun pattern (forget_memory, list_memories, search_memory, store_memory, update_memory). Two exceptions: get_relevant_context adds an adjective, and memory_summary inverts the order. Overall, mostly consistent with minor deviations.
7 tools is well-scoped for a memory management system. Each tool addresses a essential operation: create, read, update, delete, search, browse, and summarize, without unnecessary bloat.
Core CRUD and retrieval operations are covered. However, there is no direct 'get memory by key' tool; agents must infer keys from list or search results. This is a minor gap that agents can work around using existing tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Hosted persistent memory with semantic search, importance and TTL for AI agents.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AIsofialuz/agent-memory-hub'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
