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 MCP Server Remember that the user prefers dark mode"
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 memory for AI agents — store, retrieve and search knowledge across sessions. No more forgetting between conversations.
AI agents lose all context when a session ends. This MCP server gives agents a persistent knowledge store that survives across sessions, tools, and even different agent frameworks.
Related MCP server: haksnbot-memory
Store & Retrieve — Key-value storage with full persistence
Namespaces — Separate memories by project, user, or context
Tags — Categorize memories for easy filtering
Full-Text Search — Search across all stored knowledge
Access Tracking — See which memories are accessed most
Statistics — Dashboard showing memory usage
pip install agent-memory-mcp-server{
"mcpServers": {
"memory": {
"command": "uvx",
"args": ["agent-memory-mcp-server"]
}
}
}Tool | Description |
| Store a key-value pair persistently |
| Retrieve stored knowledge by key |
| Full-text search across all memories |
| List all memories in a namespace |
| Remove a memory |
| List all namespaces |
| Usage statistics |
"Remember that the user prefers dark mode"
"What do you know about Project Alpha?"
"Store this API response for later"
"What were the key decisions from last session?"Uses SQLite for zero-configuration persistent storage. Data is stored locally — no cloud, no API keys, no costs. The database file (memory.db) is created automatically in the server directory.
Category | Servers |
đź”— Blockchain | |
🌍 Data | Weather · Germany · Agriculture · Space · Aviation · EU Companies |
đź”’ Security | |
🤖 Agent Infra | Memory · Directory · Hub · Reputation |
🔬 Research | Academic · LLM Benchmark · Legal |
→ Full catalog (40+ servers)
MIT
Ein Memory löschen.
Args: key: Schlüssel des zu löschenden Eintrags namespace: Namespace (Standard: "default")
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| namespace | No | default |
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 states it deletes a memory but does not disclose that the action is irreversible, whether it requires specific permissions, or any side effects. A simple statement of behavior is insufficient.
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 very short and front-loaded with the purpose. The Args section is clear and well-structured. Every sentence adds value 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?
For a simple delete operation, the description provides the essential information. However, it lacks details about return values, error cases, or confirmation. With no output schema, more context would be beneficial.
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 explicitly explains both parameters: 'key: key of the entry to delete' and 'namespace: namespace (default "default")'. This provides meaning beyond the schema's type/title, fully compensating for the 0% schema description coverage.
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 'Ein Memory löschen' (Delete a memory), specifying the verb and resource. However, it does not explicitly distinguish from sibling tools like memory_store or memory_retrieve, which could cause confusion in a larger toolset.
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 on when to use this tool versus alternatives, nor any conditions or prerequisites. The description only explains the parameters, missing context like 'Use this to permanently delete a memory entry.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alle Memories auflisten.
Args: namespace: Optional — nur diesen Namespace zeigen limit: Maximale Anzahl (Standard: 20)
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that the tool lists memories with optional namespace and limit. Missing details on ordering, pagination, read-only vs write, auth requirements, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose then formatted Args. Every sentence adds value with no fluff. Front-loaded with the action verb.
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 6 siblings and no output schema, the description is moderately complete for a simple list operation. However, it lacks return value description, sorting, or pagination behavior beyond the limit parameter.
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 carries the full burden. It explains namespace as 'nur diesen Namespace zeigen' (show only this namespace) and limit as 'Maximale Anzahl' (maximum number, default 20). Though short, it adds clear meaning beyond schema types and defaults.
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 'Alle Memories auflisten' (list all memories), specifying the verb 'auflisten' and resource 'Memories'. It also mentions optional namespace and limit parameters, distinguishing it from siblings like memory_retrieve (single item) and memory_search (query-based).
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 explicit guidance on when to use this tool vs alternatives. The description implies listing all memories, but does not mention when not to use (e.g., for specific retrieval or search) or provide any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alle Namespaces mit Anzahl Memories auflisten.
Zeigt eine Ăśbersicht aller verwendeten Namespaces.
| 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 bears full responsibility. It only states the action but does not disclose any behavioral traits such as side effects, data freshness, permissions, 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 extremely concise with two short sentences, front-loading the action (list namespaces with counts). Every word serves a 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 zero parameters and no output schema, the description is sufficient for a simple list operation. It covers the functionality adequately, though additional context about the return format could be beneficial.
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?
There are zero parameters, so the description adds no parameter-specific meaning. Per guidelines, 0 parameters baseline is 4.
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 it lists all namespaces with their memory counts, making the purpose unambiguous. It distinguishes from sibling tools that operate on individual memories or stats.
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 obtaining a namespace overview, but provides no explicit guidance on when to use vs alternatives. No when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gespeichertes Wissen abrufen.
Args: key: SchlĂĽssel des gesuchten Eintrags namespace: Namespace (Standard: "default")
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| namespace | No | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'retrieve' but does not mention idempotency, performance characteristics, error behavior, or whether it returns the full entry or a summary. The description is insufficient for an agent to understand side effects or reliability.
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 very short and front-loaded, with the purpose stated first. However, the args section is formatted as a Python docstring which may not be ideal for an AI agent. Still, it is concise with no 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 absence of an output schema, annotations, and minimal description, the tool is underspecified. An agent cannot infer what the return value is (e.g., full object, summary, success indicator). The description leaves too many gaps for an agent to use the tool confidently.
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 schema description coverage is 0%, meaning the description does not explain the parameters beyond what the schema shows. The description lists 'key' and 'namespace' but adds no meaning beyond their existence. For instance, it doesn't explain that 'key' is unique or how retrieval works when no namespace is provided.
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 'Retrieve stored knowledge', which indicates the tool's purpose. The name 'memory_retrieve' and the sibling tools (delete, list, search, store, stats, namespaces) help distinguish it as the retrieval tool by key. However, it does not explicitly differentiate from 'memory_search', which might also retrieve knowledge but with different parameters.
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. For example, it doesn't say to use this when you have a specific key, and to use 'memory_search' for full-text queries. The description lacks any context-specific usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Memories durchsuchen.
Sucht in Keys und Values nach dem Suchbegriff. Optional filterbar nach Namespace und Tags.
Args: query: Suchbegriff namespace: Optional — nur in diesem Namespace suchen tags: Optional — nur Memories mit diesen Tags limit: Maximale Ergebnisse (Standard: 10)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| namespace | No | ||
| tags | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it searches keys and values, implying read-only, but doesn't disclose effects, performance, or authorization needs.
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?
Concise with purpose first, then parameter list. No extra fluff, though could be more compact.
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?
Covers all parameters and basic behavior, but lacks description of return format or pagination for limit.
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?
Description adds meaning to each parameter (query, namespace, tags, limit) beyond the schema, which only has titles.
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?
Clear verb 'durchsuchen' with resource 'Memories', and distinguishes from sibling tools like memory_delete or memory_retrieve by explicitly stating it searches keys and values.
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?
Implies usage for searching memories with optional filters, but no explicit when-to-use vs alternatives like memory_retrieve or memory_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Speicher-Statistiken abrufen.
Zeigt: Gesamtzahl Memories, Namespaces, meistgenutzte und zuletzt aktualisierte Einträge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the tool shows specific statistics (total memories, namespaces, most used, recently updated), which is sufficient for a read-only stats tool. It does not mention side effects or permissions, but they are likely minimal.
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 well-structured sentences. Every word adds value, front-loading the primary action and listing specifics.
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 adequately covers the tool's functionality by enumerating the statistics returned. It could mention the output structure, but for a simple stats tool, this is sufficient.
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, and the description does not add any param info, which is irrelevant. Per instructions, baseline for 0 parameters is 4.
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 retrieves memory statistics and specifies the exact metrics shown (total count, namespaces, most used, recently updated). This distinguishes it from sibling tools like memory_list or memory_search.
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 the tool is for getting an overview, but it does not explicitly state when to use it over alternatives like memory_list (list entries) or memory_search (query). No when-not or prerequisite guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wissen persistent speichern.
Speichert einen Key-Value-Eintrag der über Sessions hinweg erhalten bleibt. Ideal für Fakten, Präferenzen, Kontext.
Args: key: Eindeutiger SchlĂĽssel (z.B. "user_preference_language") value: Der zu speichernde Inhalt (Text, JSON, etc.) namespace: Namespace zur Trennung (z.B. "project_x", "user_123") tags: Optionale Tags zum Kategorisieren (z.B. ["preference", "important"])
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes | ||
| namespace | No | default | |
| tags | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions persistence across sessions but omits details such as idempotency, duplicate key handling, side effects, or any security/rate limit considerations. This is insufficient for a write operation.
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 a clear title line, a short explanation, and a structured Args list. Every sentence adds value and there is no 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?
For a simple store tool with 4 parameters and no output schema, the description covers purpose, parameters, and usage context. However, it lacks details on return values, error handling, and duplicate key behavior, which limits completeness.
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 schema coverage is 0%, so the description must add meaning. The Args section explains each parameter: key as unique identifier, value as the content, namespace for separation, tags for categorization. This provides semantic context beyond the schema's type/default information.
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 'Wissen persistent speichern' (persistently store knowledge) and explains it stores a key-value entry that persists across sessions. The verb 'speichern' (store) and resource 'Key-Value-Eintrag' are specific, and the tool is distinct from siblings like memory_retrieve and memory_delete.
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 says 'Ideal für Fakten, Präferenzen, Kontext' (ideal for facts, preferences, context), giving usage context but no explicit guidance on when not to use or alternatives. It implies usage for persistent storage but does not differentiate from siblings.
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.
v0.1.1memory_deletememory_listmemory_namespacesmemory_retrievememory_searchmemory_statsmemory_storeEach tool has a clearly distinct purpose: store, retrieve, list, search, delete, list namespaces, and stats. No overlap or ambiguity.
Tools follow a consistent 'memory_' prefix with verbs except for 'memory_namespaces' and 'memory_stats', which use nouns. Minor deviation from the verb_noun pattern.
Seven tools are appropriate for a memory management server, covering essential operations without being too few or too many.
Covers all basic memory operations (create, read, list, search, delete, stats, namespace listing), but lacks an explicit update operation, though store can overwrite existing keys.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent cloud memory for AI agents. Store and search key-value memories across sessions.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory for AI agents — verbatim conversations, searchable by meaning.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AiAgentKarl/agent-memory-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
