Perenna
Perenna is an MCP server that provides AI agents with a shared, Git-backed permanent memory in Markdown, exposed through read, write, and delete tools.
memory_read: list all memories and projects, search for bounded ranked passages, or get one complete committed memory by ID with its revision.
memory_write: create new memories, patch exact all-or-nothing edits, or replace the full summary/body; each change commits to Git and reports index/sync status.
memory_delete: delete exactly one committed memory by ID, expected title, and base revision; the deletion is recoverable from Git history.
Supports local agents and ChatGPT sharing durable memories via stdio, local HTTP, or OAuth-protected remote HTTP.
Uses a Vexor retrieval index that can be rebuilt from Git and supports optional Git remote synchronization.
Uses Git repositories as a durable memory store, enabling AI agents to persist, read, edit, and synchronize memories, with optional sync to a private Git remote.
Perenna
A lightweight, Git-backed permanent memory for AI agents. Claude Code, Codex, ChatGPT, Cursor, and other MCP clients can share durable memories without sharing a vendor account or conversation history.
Separate MCP tools for reading, writing, and deleting memories
Local stdio, loopback-only Streamable HTTP, and OAuth-protected remote HTTP
Human-readable Markdown stored in an independent Git repository
Local Vexor retrieval index that can always be rebuilt from Git
Cross-process locking for multiple local agent processes
Why Perenna?
Your memory should follow you, not the agent you happen to be using.
Claude Code, Codex, Cursor, and ChatGPT keep memory in separate silos. Switch agents and your memory disappears. Switch machines and local memory stays behind.
Perenna gives them one shared, Git-backed memory. Local agents and ChatGPT can connect to the same self-hosted Perenna service, while every durable memory stays ordinary Markdown you can inspect, edit, version, and back up yourself.
Perenna stays focused on permanent memory: no required account, proprietary memory cloud, or automatic conversation extraction.
Related MCP server: phren
Quickstart
Install with your AI agent
Paste this into Claude Code, Codex, ChatGPT Desktop, Cursor, or another coding agent with terminal and local MCP configuration access:
Open the following URL, read the complete instructions, and follow them to
install and connect Perenna:
https://raw.githubusercontent.com/scarletkc/Perenna/main/docs/guides/agent-installation.mdInstall a published release
Perenna requires Python 3.12+, Git, and uv.
Install Perenna
uv tool install perennaConfigure retrieval
Perenna needs a working Vexor embedding provider. For interactive provider selection and configuration, run:
uvx vexor initPerenna automatically reuses ~/.vexor/config.json. When using process-level
configuration, make sure the MCP server receives VEXOR_CONFIG_JSON plus
VEXOR_API_KEY or the selected provider's key from its host environment.
Remote providers receive memory text and search queries.
If you choose local embeddings, also install Perenna's local extra:
uv tool install "perenna[local]"Vexor provider configuration covers remote and local setup. From the environment that starts the MCP client, verify the selected provider with:
uvx vexor doctorConnect a client
For the standalone setup, configure the MCP client to start:
perenna mcpFollow the Client setup guide for the exact client command or configuration file.
Codex and Claude Code can also install the optional memory behavior Skill:
perenna skill install --agent codex
# or
perenna skill install --agent claude-codeRepeat --agent in one command when both clients should receive the skill.
The configuration reference
documents user and project scope, destinations, and replacement safeguards.
Codex and Claude Code can instead install the combined Skill and MCP connection from Perenna's repository Marketplace. Follow the Plugin setup guide and choose one setup path per client.
Perenna creates its local data under ~/.perenna/ unless another home is
configured.
Add optional Git synchronization
To import, publish, or fast-forward compatible history through a private Git repository, run:
perenna sync setup <repository-url>Successful setup saves the selected remote in the Perenna home. Use
perenna sync disable to return to saved local-only mode without removing the
Git remote.
The configuration reference owns remote selection, credentials, conflict handling, and recovery details.
Install from source
git clone https://github.com/scarletkc/Perenna.git
cd Perenna
uv tool install .Source contributors should use the locked environment in the development guide.
Documentation
Start with the documentation index, then follow the path for your task:
License
Available Tools
3 toolsmemory_deleteADestructive
Delete exactly one committed memory by ID, expected title, and revision. The deletion removes it from current recall but remains recoverable from Git history.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | ||
| base_revision | Yes | ||
| expected_title | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| commit | Yes | |
| memory | Yes | |
| changed | Yes | |
| sync_status | Yes | |
| index_status | Yes | |
| recoverable_via_git | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false. The description adds valuable non-obvious context: the deletion removes from recall but remains recoverable via Git history, and it deletes 'exactly one' memory. This goes beyond the annotations without contradicting them. It does not mention side effects like concurrency checks, but the added recoverability and scoping are meaningful.
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 one compact sentence that leads with the action and core constraints, then adds the recoverability detail. There is no fluff or repetition; every word 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?
For a destructive operation with three required parameters and an output schema, the description is thin. It omits behavior on mismatch (e.g., if expected_title or base_revision does not match), error semantics, or any guidance on when this tool should be chosen over siblings. The recoverability note is helpful (something the output schema won't reveal), but other important context is missing.
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. However, it only mentions parameters as 'ID, expected title, and revision' without explaining their purpose, format, or how they are used (e.g., what an expected title is for, what a base revision means, or how they act as safety checks). No examples or constraints are provided, leaving agents to infer semantics from names alone.
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 ('Delete'), resource ('one committed memory'), and identifies the parameters by role (ID, expected title, revision). It clearly distinguishes from siblings memory_read and memory_write by the action it performs.
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 does not provide explicit guidance on when to use this tool versus alternatives. It only implies deletion use case without mentioning conditions, prerequisites, or exclusions (e.g., 'use memory_read to view' or 'use memory_write to create'). No context is given for when a deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_readARead-onlyIdempotent
Read permanent memory. List returns stable memory IDs and titles, search returns bounded ranked candidate passages, and get returns one complete committed memory with its revision.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive, idempotent, and open-world behavior. The description adds useful context beyond annotations: search results are 'bounded ranked candidate passages,' list returns only IDs/titles, and get returns a 'complete committed memory with its revision.' No contradiction with annotations.
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 that front-loads the core purpose and uses parallel clauses to describe each action without redundancy or filler. It is compact yet informative.
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's three modes and the existence of an output schema, the description is complete: it explains the behavior of each action and what kind of result to expect. Annotations cover safety and side-effect concerns, and sibling names make the read/write/delete division clear.
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 fully documents the action variants, required fields, and limit bounds through its oneOf structure and const values. The description does not add parameter-level detail such as query format or memory_id semantics, but with schema coverage effectively complete, the baseline 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 states a specific verb and resource ('Read permanent memory') and enumerates three distinct modes—list, search, get—with their concrete outcomes. This distinguishes the tool from memory_write and memory_delete without relying on the name alone.
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 tells an agent what each mode returns, which is clear guidance for choosing list vs search vs get. It does not explicitly say 'use this instead of memory_write or memory_delete,' but 'Read' and the sibling names make the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_writeADestructive
Create or modify permanent memory. Summary is a stable one-line description of what a memory covers. Patch applies exact all-or-nothing edits; replace overwrites the complete summary and body. Existing memories require a current base revision.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| commit | Yes | |
| memory | Yes | |
| changed | Yes | |
| sync_status | Yes | |
| index_status | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses valuable behavioral details: patch is all-or-nothing, replace overwrites the complete summary/body, and existing memories require a current base revision, implying optimistic concurrency. This does not contradict any annotation.
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 three dense sentences with no filler. The purpose is front-loaded, and each sentence addresses a distinct aspect: overall behavior, summary semantics, and modifications semantics.
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?
The description covers the key operational facts an agent needs: the three modes, the summary convention, patch atomicity, and the base-revision requirement. Since an output schema exists, return-value details are not needed here. A minor gap is not pointing agents to memory_read to retrieve the current base revision.
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 meaning beyond the schema by defining summary as a 'stable one-line description', explaining the exact semantics of patch and replace, and mentioning the base revision requirement. This is useful context that the bare schema types do not convey, though title and project are left to 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 states a specific action ('Create or modify') on a clear resource ('permanent memory') and further differentiates the three operational modes: create, patch, and replace. This makes the tool unmistakably the write counterpart to memory_read 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 provides internal guidance on when to use patch vs replace and notes the base-revision prerequisite for modifying existing memories. However, it does not explicitly mention memory_read or memory_delete or state when to prefer this tool over those siblings.
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.1- Changed
memory_read5 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / oneOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "action": { + "const": "list" + }, + "project": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "search" + }, + "limit": { + "maximum": 5, + "minimum": 1, + "type": "integer" + }, + "project": { + "type": "string" + }, + "query": { + "type": "string" + } + }, + "required": [ + "action", + "query" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "get" + }, + "memory_id": { + "type": "string" + } + }, + "required": [ + "action", + "memory_id" + ], + "type": "object" + } +] - removed
Input schema / propertiesRemoved value: -{ - "action": { - "enum": [ - "list", - "search", - "get" - ], - "type": "string" - }, - "limit": { - "maximum": 5, - "minimum": 1, - "type": "integer" - }, - "memory_id": { - "type": "string" - }, - "project": { - "type": "string" - }, - "query": { - "type": "string" - } -} - removed
Input schema / requiredRemoved value: -[ - "action" -] - changed
Output schema / oneOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "action": { - "const": "list" - }, - "memories": { - "items": { - "additionalProperties": false, - "properties": { - "memory_id": { - "type": "string" - }, - "scope": { - "type": "string" - }, - "summary": { - "type": "string" - }, - "title": { - "type": "string" - } - }, - "required": [ - "memory_id", - "title", - "scope", - "summary" - ], - "type": "object" - }, - "type": "array" - }, - "project": { - "type": [ - "string", - "null" - ] - }, - "projects": { - "items": { - "type": "string" - }, - "type": "array" - } - }, - "required": [ - "action", - "project", - "memories", - "projects" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "search" - }, - "limit": { - "maximum": 5, - "minimum": 1, - "type": "integer" - }, - "matches": { - "items": { - "additionalProperties": false, - "properties": { - "memory_id": { - "type": "string" - }, - "passages": { - "items": { - "additionalProperties": false, - "properties": { - "end_char": { - "minimum": 1, - "type": "integer" - }, - "start_char": { - "minimum": 0, - "type": "integer" - }, - "text": { - "type": "string" - } - }, - "required": [ - "text", - "start_char", - "end_char" - ], - "type": "object" - }, - "minItems": 1, - "type": "array" - }, - "rank": { - "minimum": 1, - "type": "integer" - }, - "revision": { - "type": "string" - }, - "scope": { - "type": "string" - }, - "summary": { - "type": "string" - }, - "title": { - "type": "string" - } - }, - "required": [ - "memory_id", - "title", - "scope", - "summary", - "revision", - "rank", - "passages" - ], - "type": "object" - }, - "type": "array" - }, - "project": { - "type": [ - "string", - "null" - ] - }, - "truncated": { - "type": "boolean" - } - }, - "required": [ - "action", - "project", - "limit", - "matches", - "truncated" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "action": { - "const": "get" - }, - "memory": { - "additionalProperties": false, - "properties": { - "body": { - "type": "string" - }, - "created_at": { - "type": "string" - }, - "memory_id": { - "type": "string" - }, - "revision": { - "type": "string" - }, - "scope": { - "type": "string" - }, - "source": { - "type": "string" - }, - "summary": { - "type": "string" - }, - "title": { - "type": "string" - }, - "updated_at": { - "type": "string" - } - }, - "required": [ - "memory_id", - "title", - "scope", - "summary", - "source", - "created_at", - "updated_at", - "revision", - "body" - ], - "type": "object" - } - }, - "required": [ - "action", - "memory" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "action": { + "const": "list" + }, + "memories": { + "items": { + "additionalProperties": false, + "properties": { + "memory_id": { + "type": "string" + }, + "scope": { + "type": "string" + }, + "summary": { + "type": "string" + }, + "title": { + "type": "string" + } + }, + "required": [ + "memory_id", + "title", + "scope", + "summary" + ], + "type": "object" + }, + "type": "array" + }, + "project": { + "type": [ + "string", + "null" + ] + }, + "projects": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "action", + "project", + "memories", + "projects" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "search" + }, + "limit": { + "maximum": 5, + "minimum": 1, + "type": "integer" + }, + "matches": { + "items": { + "additionalProperties": false, + "properties": { + "memory_id": { + "type": "string" + }, + "passages": { + "items": { + "additionalProperties": false, + "properties": { + "end_char": { + "minimum": 1, + "type": "integer" + }, + "start_char": { + "minimum": 0, + "type": "integer" + }, + "text": { + "type": "string" + } + }, + "required": [ + "text", + "start_char", + "end_char" + ], + "type": "object" + }, + "minItems": 1, + "type": "array" + }, + "rank": { + "minimum": 1, + "type": "integer" + }, + "revision": { + "type": "string" + }, + "scope": { + "type": "string" + }, + "summary": { + "type": "string" + }, + "title": { + "type": "string" + } + }, + "required": [ + "memory_id", + "title", + "scope", + "summary", + "revision", + "rank", + "passages" + ], + "type": "object" + }, + "type": "array" + }, + "project": { + "type": [ + "string", + "null" + ] + }, + "truncated": { + "type": "boolean" + } + }, + "required": [ + "action", + "project", + "limit", + "matches", + "truncated" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "get" + }, + "memory": { + "additionalProperties": false, + "properties": { + "body": { + "type": "string" + }, + "created_at": { + "type": "string" + }, + "memory_id": { + "type": "string" + }, + "revision": { + "type": "string" + }, + "scope": { + "type": "string" + }, + "summary": { + "type": "string" + }, + "title": { + "type": "string" + }, + "updated_at": { + "type": "string" + } + }, + "required": [ + "memory_id", + "title", + "scope", + "summary", + "created_at", + "updated_at", + "revision", + "body" + ], + "type": "object" + } + }, + "required": [ + "action", + "memory" + ], + "type": "object" + } +]
- Changed
memory_write4 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - added
Input schema / oneOfAdded value: +[ + { + "additionalProperties": false, + "properties": { + "action": { + "const": "create" + }, + "body": { + "type": "string" + }, + "project": { + "type": "string" + }, + "summary": { + "type": "string" + }, + "title": { + "type": "string" + } + }, + "required": [ + "action", + "title", + "summary", + "body" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "patch" + }, + "base_revision": { + "type": "string" + }, + "edits": { + "items": { + "additionalProperties": false, + "properties": { + "new_text": { + "type": "string" + }, + "old_text": { + "type": "string" + } + }, + "required": [ + "old_text", + "new_text" + ], + "type": "object" + }, + "minItems": 1, + "type": "array" + }, + "memory_id": { + "type": "string" + }, + "summary": { + "type": "string" + } + }, + "required": [ + "action", + "memory_id", + "base_revision", + "edits" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "action": { + "const": "replace" + }, + "base_revision": { + "type": "string" + }, + "body": { + "type": "string" + }, + "memory_id": { + "type": "string" + }, + "summary": { + "type": "string" + } + }, + "required": [ + "action", + "memory_id", + "base_revision", + "summary", + "body" + ], + "type": "object" + } +] - removed
Input schema / propertiesRemoved value: -{ - "action": { - "enum": [ - "create", - "patch", - "replace" - ], - "type": "string" - }, - "base_revision": { - "type": "string" - }, - "body": { - "type": "string" - }, - "edits": { - "items": { - "additionalProperties": false, - "properties": { - "new_text": { - "type": "string" - }, - "old_text": { - "type": "string" - } - }, - "required": [ - "old_text", - "new_text" - ], - "type": "object" - }, - "minItems": 1, - "type": "array" - }, - "memory_id": { - "type": "string" - }, - "project": { - "type": "string" - }, - "summary": { - "type": "string" - }, - "title": { - "type": "string" - } -} - removed
Input schema / requiredRemoved value: -[ - "action" -]
3 tool updates
v0.1.0- First observed
memory_delete - First observed
memory_read - First observed
memory_write
TDQS
Each tool handles a distinct lifecycle operation: reading/querying, writing/updating, and deleting memories. There is no overlap between the primary actions, and the sub-modes within memory_read are explicitly separated (list, search, get).
All tool names follow the same memory_verb pattern using clear, lowercase snake_case verbs. The naming makes the operation type immediately obvious and perfectly consistent across the set.
Three tools is a compact but complete surface for a permanent memory store. Each tool earns its place, and no redundant or extraneous operations exist.
The set covers the full lifecycle: create/modify via memory_write, read via memory_read (including list/search/get), and delete via memory_delete. Revision-handling and Git-history recovery details further round out the functionality, leaving no critical gaps.
Maintenance
Related MCP Connectors
Git-backed platform for skills, tools, and context for AI agents
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides a memory layer for AI coding agents with Git-powered version control, enabling automatic tracking of prompts, context, and code diffs.192MIT
- AlicenseNot gradedqualityAmaintenanceA persistent memory server for AI agents that stores findings, tasks, and patterns in Markdown files within a git repository, enabling context injection across multiple AI tools.4MIT
- AlicenseAqualityAmaintenanceGit-native long-term memory for AI agents: your markdown files are the source of truth, the search index is a disposable projection rebuilt from git, and every memory the agent writes is a reviewable git commit. Served over one OAuth-secured MCP endpoint with hybrid lexical+semantic recall and a gated, git-first commit_note write tool.78AGPL 3.0
- AlicenseNot gradedqualityAmaintenanceOpen-source persistent memory infrastructure for AI agents.150321Apache 2.0
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/scarletkc/Perenna'
If you have feedback or need assistance with the MCP directory API, please join our Discord server