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., "@project-memory-mcp Remember: we decided to use SQLite for storage because it needs no extra services."
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.
Coding agents forget everything between sessions. You explain a decision on Monday, and on Wednesday the agent re-derives it, differently. This is a small MCP server that gives agents a place to write things down and find them again — per project, across sessions, across tools.
It does three things and nothing else:
memory_record — save a note, decision, requirement, or learning.
memory_search — full-text search over what was saved for a project.
project_status — see whether a project has any memory yet, counts by kind, and the last few entries.
Everything lives in one SQLite file on your machine. No cloud, no accounts, no native dependencies — it uses the node:sqlite module that ships with Node, so pnpm install pulls in only the MCP SDK and zod.
Each tool call takes an absolute project_root. That path is the project's identity: the first time a memory is recorded for a root, a project row is created; after that every search and status call is scoped to it. Two projects can contain the same words and never see each other's memories.
Memory is append-only. Recording the same kind, title, and body twice stores it once and tells you created: false. There is no update or delete — to change a decision, record a new one with supersedes pointing at the old id; the old memory keeps its history but drops out of search results. That keeps the history honest and the tool surface tiny.
Search is deliberately boring: every word in your query must appear in a hit (title, body, or tags), ranked by SQLite's FTS5 with titles weighted highest, and the last word is a prefix match so sqlite finds sqlite3. Hits come back with a short excerpt, not the full body — pass include_body: true when you need the whole text. No query syntax to learn, no way to break it with punctuation.
Related MCP server: LumenCore
Requires Node 26 and pnpm.
pnpm install
pnpm test
pnpm buildThen point your agent harness at the built server. For Claude Code, Codex, or anything else that reads an MCP config:
{
"mcpServers": {
"project-memory": {
"command": "node",
"args": ["/absolute/path/to/project-memory-mcp/dist/server.js"]
}
}
}The database is created on first use at ~/.local/share/project-memory/store.sqlite (or under $XDG_DATA_HOME if set). To put it somewhere else, set PROJECT_MEMORY_DB=/path/to/file.sqlite in the server's environment.
Exposing tools is not the same as an agent knowing when to use them. skills/project-memory/SKILL.md is a short, harness-agnostic skill that tells the agent to resolve the project root once, check project_status before starting, search before re-deriving old decisions, and record requirements and decisions as they happen. Copy that folder into your harness's skills directory (for example ~/.claude/skills/ or ~/.codex/skills/) and adjust the server path in its setup section.
kind | use it for |
| a constraint the work must satisfy |
| a choice that was made, and why |
| a non-obvious fact about the code or environment |
| anything else worth keeping |
src/server.ts stdio entry point
src/mcp.ts the three tool definitions
src/store.ts record / search / status against SQLite
src/db.ts schema, pragmas, database location
src/project-root.ts validates and canonicalizes project_root
test/ vitest: store behavior and MCP round-trips
skills/project-memory/SKILL.mdMIT
Record a durable memory (note, decision, requirement, or learning) for a project. Identical kind+title+body is stored once; the response reports created=false when it already existed. Pass supersedes= to mark an earlier memory as replaced by this one; superseded memories are hidden from search by default.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| kind | Yes | ||
| tags | No | ||
| title | Yes | ||
| supersedes | No | ||
| project_root | Yes | Absolute path to the project root directory. Resolve once (git toplevel or workspace root) and reuse verbatim. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond idempotentHint=true, the description reveals the exact idempotency key ('Identical kind+title+body is stored once') and the response signal ('the response reports created=false when it already existed'). It also discloses the full supersede contract — 'superseded memories are hidden from search by default' — which qualifies destructiveHint=false by explaining that replacement hides rather than deletes. 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?
Three sentences, each earning its place: purpose first, then dedup/idempotency behavior, then supersede semantics. Information is front-loaded with the core purpose and no word is wasted.
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 tool with six parameters including the relationship parameter supersedes, the description covers all non-obvious behaviors: deduplication, the created flag in the response, and the visibility effect on search. Since there is no output schema, this partial return-value disclosure is valuable; the remaining gap is that it never states what else the response contains (e.g., the new memory's id needed to chain supersedes).
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 only 17% schema description coverage, the description compensates for most undocumented parameters: it gives kind semantic framing (note/decision/requirement/learning), makes title and body part of the dedup identity, and fully explains supersedes including its search-hiding consequence. Only tags receives no added meaning, but its purpose is evident from its name and schema constraints.
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 opens with 'Record a durable memory' — a specific verb acting on a clearly named resource — and enumerates the four kinds (note, decision, requirement, learning) that map directly to the kind enum. The verb contrast with sibling memory_search makes the read/write distinction obvious, and project_status is clearly out of scope. The meaning is unambiguous.
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 never explicitly states when to use this tool versus its siblings (e.g., no 'use memory_search to find memories' routing). Usage context is implied by 'Record a durable memory ... for a project' and by the disclosed dedup and supersede behaviors, which signal this is the safe write-tool to call repeatedly, but no explicit alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over a project's memories. Query words are matched literally (all words must appear) and the last word is a prefix match, so sqlite also finds sqlite3. Each hit carries a short excerpt over the body, not the full text. Returns newest-first among equal relevance. Empty results for unknown projects.
| Name | Required | Description | Default |
|---|---|---|---|
| kinds | No | ||
| limit | No | ||
| query | Yes | ||
| include_body | No | Return full bodies. Default false: only a short excerpt per hit. | |
| project_root | Yes | Absolute path to the project root directory. Resolve once (git toplevel or workspace root) and reuse verbatim. | |
| include_superseded | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, and the description adds substantial behavioral detail: literal word matching, prefix matching on the last word, excerpt-only hits by default, newest-first ordering among equal relevance, and empty results for unknown projects. None of this contradicts the 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?
Four sentences, each carrying distinct operational value: purpose, matching rules, excerpt behavior, and ordering/empty-result behavior. The purpose is front-loaded and no sentence is wasted.
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 scope, query behavior, result excerpt shape, ordering, and empty-result handling, which is solid for a read-only search tool with no output schema. It falls just short of a 5 because exact hit structure and defaults for optional parameters like limit and include_superseded are not described.
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 only 33%, so the description must compensate. It does explain query matching semantics and the excerpt-versus-body behavior tied to include_body, but it leaves kinds and include_superseded semantics undocumented, and limit's default is not stated. Partial compensation, not complete.
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 opens with a specific verb and resource: 'Full-text search over a project's memories.' This clearly distinguishes the tool from siblings memory_record (creating memory) and project_status (reading status), so an agent can select it without ambiguity.
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 establishes a clear usage context: searching project memories with full-text semantics. However, it does not explicitly name alternatives or state when to prefer memory_record or project_status, so it misses the 'when-not-to-use' guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether a project has recorded memory, counts by kind, and the 5 latest entries. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| project_root | Yes | Absolute path to the project root directory. Resolve once (git toplevel or workspace root) and reuse verbatim. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'Read-only'. It adds what the response covers (memory presence, counts by kind, latest 5 entries), which matters because there is no output schema. It stops short of defining exact formats, but that is a minor gap.
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?
One sentence communicates scope, output content, and safety in under 20 words. Every phrase adds information and the core behavior is front-loaded.
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 single-parameter, read-only status tool with no output schema, the description covers the key return components sufficiently. It lacks details like ordering of latest entries or error behavior, but those are not necessary for deciding to call it.
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% and the project_root description is thorough, so the schema carries the full parameter burden. The tool description adds nothing about parameters, which is acceptable under the high-coverage baseline.
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?
Description opens with a concrete verb ('Report') and identifies the exact output: whether memory exists, counts by kind, and the latest 5 entries. It is clearly a read-only status snapshot, which separates it from the memory_record and memory_search siblings.
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 read-only label and summary-style output make the intended use obvious: check a project's memory state before deciding to record or search. It does not explicitly name alternatives, but the context is clear enough for an agent to infer when to call it.
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.0memory_recordmemory_searchproject_statusEach tool has a clearly distinct purpose: recording, searching, and summarizing project memory. There is no overlap or ambiguity between them.
Names follow a predictable resource-prefixed pattern: memory_record, memory_search, project_status. The pattern is readable and consistent enough, though project_status is more of a noun phrase than an action-oriented name.
Three tools is well-scoped for a focused project-memory server. Each tool earns its place and the surface is small but not underwhelming.
Core memory workflows are covered: recording, searching, and checking status. A minor gap is the lack of a get-by-id or full-text retrieval tool, since search only returns excerpts; deletion is handled indirectly via supersede.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Cross-session, cross-device memory for your agent: remember and recall notes. No key to start.
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/extrei/project-memory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
