This server acts as a provider-independent memory sidecar for AI agents, exposing two MCP tools to read from and write to durable long-term memory.
Store interactions as candidate memory: Use ingest_turn with a token, user input, assistant output, and metadata (including an explicit ingest reason) to save one interaction for later review.
Retrieve relevant context: Use get_context with an input and token to fetch compact durable memory to inform the agent before working on a task.
Tune retrieval per request: Optionally pass a session_id, include raw chunks, cap the returned context size with max_context_chars, or limit diary memory by diary_lookback_days.
Support the intended memory lifecycle: Written turns become candidate memory, later movable to active and eventually archived memory through maintenance workflows.
Keep memory provider-independent: The server is designed so different agent runtimes (Claude, ChatGPT, Gemini, etc.) can share the same persistent memory outside any single model vendor.
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., "@Personal Agent Memory MCP Remember this decision and link it to yesterday's project notes."
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.
Personal Agent Memory MCP is a provider-independent memory layer for AI assistants. It gives different agents and model providers a shared place to read and write persistent context.
It is not meant to run the full agent loop, make general tool-use decisions, or replace the short-term conversation state managed by an outer runtime such as Codex, Claude Desktop, Dify, Gemini, ChatGPT, or another agent host.
The project focuses on one boundary: long-term personal memory that lives outside any single model provider.
I do not want my assistant memory to be locked inside a single model provider.
In practice, I use different assistants in different contexts: sometimes ChatGPT, sometimes Claude, sometimes Gemini, and potentially other local or hosted agents later. Each of those tools has its own context and memory system, but those memories are disconnected from one another.
The goal of this project is to build a provider-independent memory layer: an overall assistant brain that can hold persistent context outside any single model provider, and let different AI agents read from and write to the same durable memory.
MCP, PostgreSQL, pgvector, embeddings, tags, links, and graph expansion are implementation choices for that goal. They are not the goal themselves.
Related MCP server: Cerefox
This project is designed as a memory sidecar for AI agents.
An outer agent runtime stays responsible for the actual conversation, reasoning, tool use, and response generation. This memory server only answers two questions:
What durable context should the agent know before working on this task?
What part of this interaction is worth saving after the task is done?
sequenceDiagram
participant User
participant Agent as Outer agent runtime
box rgba(235, 245, 255, 0.45) Provider-independent memory layer
participant Memory as Personal Agent Memory MCP
end
participant Tools as Other tools
User->>Agent: Ask for help
Agent->>Memory: get_context(task input)
Memory-->>Agent: Compact durable context
Agent->>Agent: Reason with current task and retrieved memory
Agent->>Tools: Call tools when needed
Tools-->>Agent: Tool results
Agent-->>User: Respond
Agent->>Memory: ingest_turn(interaction, ingest_reason)
Memory-->>Agent: Candidate memory savedThis keeps memory outside the model provider while still making it available to any assistant runtime that can speak the supported interface.
The main agent-facing entry point is MCP.
get_context: read relevant durable memory for the current task.
ingest_turn: write candidate memory from an interaction, with an explicit
metadata.ingest_reason.
There is also a small REST user API for user management, but it is not the primary interface for agent memory.
Planned maintenance entry points include:
reviewing candidate notes;
creating daily diary entries;
updating profile-derived memory;
normalizing tags;
repairing and updating links;
archiving stale or superseded memory.
Memory should be provider-independent, not owned by ChatGPT, Claude, Gemini, or any single model vendor.
Recent chat and durable memory are different things. The outer runtime owns short-term conversation state; this project owns long-term memory.
Memory should be explicit. The caller must provide an ingest_reason instead
of letting every interaction silently become permanent memory.
Memory should be inspectable and maintainable. Notes, diary entries, profile memory, tags, links, and lifecycle events should remain understandable outside any one agent session.
Retrieval should return bounded context, not perform reasoning on behalf of the agent.
Implementation details should be replaceable as long as the memory contract remains stable.
Pending. The local development flow is still being shaped.
The expected flow will be:
Install Python dependencies with uv.
Copy .env.example to .env.
Copy memory.example.json to memory.json.
Start PostgreSQL + pgvector and Ollama.
Run database migrations.
Start the stdio MCP server.
Run the smoke test against the real MCP tool boundary.
For now, the Chinese README has the most complete local setup notes: 中文 Quick Start.
The expected memory lifecycle is:
Read: an agent asks for relevant durable context.
Use: the agent reasons with that context in its own runtime.
Write: the agent saves meaningful outcomes or observations as candidate memory.
Review: maintenance workflows clean up, merge, split, link, and organize candidates.
Activate: reviewed memory becomes part of the long-term assistant brain.
Archive: stale, duplicate, or superseded memory is kept out of active retrieval.
Memory item status is intentionally simple:
candidate -> active -> archivedP0 focuses on durable text memory:
note: explicit knowledge, ideas, project notes, and reusable information.
diary: chronological daily context and observations.
profile_memory: retrieval-friendly memory derived from the user profile.
Recent chat is intentionally outside the core database for now. The outer agent runtime should manage short-term conversation state.
The README is meant to explain the project intent and usage model. Technical details live in:
Planned later work includes:
better extraction from interactions;
full-text search and reranking;
daily maintenance workers;
note merge and split flows;
profile stability rules;
richer link types;
heat and importance scoring;
stronger provenance support.
See TODO.md for the longer backlog.
Retrieve compact durable memory context for the caller input.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| token | Yes | ||
| session_id | No | ||
| include_chunks | No | ||
| max_context_chars | No | ||
| diary_lookback_days | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 that the tool 'retrieves' context, which implies a read operation, but it does not disclose authentication expectations, side effect behavior, failure modes, or how the durable memory is selected or scoped.
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, focused sentence with no filler. It front-loads the core action and object efficiently, earning every word.
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 six parameters, zero schema coverage, no annotations, and only one sibling, the description is too thin to support correct invocation. The presence of an output schema reduces the need to describe return values, but the tool's parameter semantics, authentication context, and selection behavior remain unclear.
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 description coverage is 0%, so the description must compensate, but it barely does. 'Caller input' loosely maps to the input parameter and 'compact' hints at max_context_chars, but token, session_id, include_chunks, and diary_lookback_days are entirely unexplained.
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 states a specific verb ('Retrieve') and resource ('compact durable memory context') tied to the caller input. It clearly distinguishes itself from the only sibling, ingest_turn, by framing this as a retrieval operation versus an ingestion one.
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 given on when to use this tool versus ingest_turn, nor any mention of alternatives or exclusions. The description implies a retrieval use case but does not explain when this is the right choice or when another tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store one interaction as candidate durable memory.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| metadata | Yes | ||
| user_input | Yes | ||
| assistant_output | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure. The phrase 'candidate durable memory' does add meaningful context—it implies the stored interaction is not necessarily permanent and may be subject to later promotion or filtering. However, it does not mention auth requirements, idempotency, storage limits, or what happens to the candidate after ingestion.
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, front-loaded sentence with no filler; every word contributes to the core meaning. It earns a 4 rather than a 5 because it is so terse that it leaves important operational context to be supplied elsewhere.
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 state-changing tool with no annotations, four required parameters, a nested object, and a sibling retrieval tool, the description is too sparse. It omits the meaning of token, the shape of metadata, and any indication of side effects or the candidate-memory lifecycle.
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 description coverage is 0%, and the description does not explain any of the four required parameters. Token, user_input, and assistant_output are reasonably inferable from their names, but metadata's structure and purpose are left completely opaque.
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 ('store') and a concrete resource ('one interaction as candidate durable memory'), and the contrast with the sibling get_context makes the write-vs-read split apparent. It stops short of a full 5 because it does not explicitly differentiate itself from get_context or clarify whether 'interaction' maps exactly to a 'turn'.
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?
There is no statement about when to use this tool versus get_context, no prerequisites, and no mention that this is the right choice for persisting conversation data. The intended usage must be inferred from the tool name and the verb 'store,' which is not enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have completely distinct purposes: one stores a turn for potential durable memory, the other retrieves context. There is no ambiguity between writing and reading operations.
Both tool names follow the consistent verb_noun pattern: ingest_turn and get_context. The naming is clear and predictable.
With only 2 tools, the server is on the thin side for a full memory system, but it covers the basic store/retrieve workflow. It feels borderline for its stated purpose.
The memory domain typically requires update, delete, and list operations in addition to ingest and retrieve. The absence of these leaves significant gaps that could hinder agents needing to manage durable memory effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Persistent memory for AI agents. Search, store, and recall across sessions.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Oceankj/second_brain'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
