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., "@Yunaki Memory MCP remember that we use Prettier for formatting"
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.
A git-backed, per-repo memory layer exposed as an MCP server — the substrate for a self-evolving Claude skill. Drop the skill into any git repo and a dedicated, version-controlled memory store materializes on first write. Every memory is a commit, so the skill's growth is a readable, revertible history.
The server is stdio-based: each person runs their own copy locally, against their own repos. Pick whichever install fits — none requires editing an absolute path.
npx from GitHub (no npm publish needed):
claude mcp add yunaki-memory -- npx -y github:Nanda-Kiran/yunaki-memory-mcpnpx from npm (after npm publish):
claude mcp add yunaki-memory -- npx -y yunaki-memory-mcpClone & build (zero publishing):
git clone https://github.com/Nanda-Kiran/yunaki-memory-mcp.git
cd yunaki-memory-mcp && npm install && npm run build
claude mcp add yunaki-memory -- node "$(pwd)/dist/index.js"Equivalent .mcp.json (commit this in any repo to share the config with collaborators):
{
"mcpServers": {
"yunaki-memory": {
"command": "npx",
"args": ["-y", "github:Nanda-Kiran/yunaki-memory-mcp"]
}
}
}Memory is stored per-user under
~/.yunaki/memory/<repo-id>/(override withYUNAKI_MEMORY_ROOT). Installing the server does not share memories between people — see Roadmap formemory_sync.
Related MCP server: memory-mcp
When you first adopt a repo, run memory_ingest once to seed memory with the repo's overview,
file structure, and docs. After that the skill accumulates memories as it works.
Identity, not path. Memory is keyed to a repo's root-commit SHA (git rev-list --max-parents=0 HEAD), which survives clone / rename / remote-move. Commit-less repos fall
back to a UUID cached in .git/config. Path and remote URL are kept only as labels.
Repo discovery. The server resolves the active repo from its working directory (the Claude
Code CLI launches it inside your project), overridable per call via repoPath or pinned with the
YUNAKI_REPO env var.
Central sidecar. Stores live at ~/.yunaki/memory/<repo-id>/ — never pollutes the user's repo.
Ad hoc creation. ensureRepoMemory(cwd) runs at the top of every tool call: resolves
identity, and on first touch git inits the store, seeds repo.json + MEMORY.md, and commits.
One file per memory. Markdown + YAML frontmatter under <type>/<slug>.md — clean diffs,
trivial merges. MEMORY.md is the rebuilt index (the cheap working set).
Tool | Purpose |
| Scan the repo and seed |
| Persist a memory (fact/heuristic/failure/success/preference/reference) — commits it |
| Retrieve memories for the current repo, ranked by keyword × confidence |
| Show resolved identity + memory location for the current repo |
All accept an optional repoPath; otherwise they resolve against the server's cwd.
npm install
npm run build
npm run smoke # core write/search loop
node test/ingest-smoke.mjs # ingest against this repomemory_reinforce(id, outcome) — bump/decay confidence + usage_count instead of duplicating.
Dedup-before-write — semantic/slug match so reinforcement replaces near-duplicates.
memory_consolidate() — merge dupes, prune stale, and promote high-confidence memories into
the skill's SKILL.md. That promotion (a git diff of the skill rewriting itself) is the payoff.
Embedding rerank (Voyage) cached in the gitignored .index/.
memory_sync() — push/pull each repo-memory git store to a remote for shared team memory.
MIT
Scan the current git repo (tracked + non-ignored files) and write reference memories: a repo overview (stack, npm scripts, file types), the file-structure tree, and the contents of docs (README, CONTRIBUTING, docs/*). Idempotent — re-running updates the same entries in a single commit. Run this once when adopting a repo to seed memory.
| Name | Required | Description | Default |
|---|---|---|---|
| maxDocs | No | Max doc files to capture (default 20). | |
| maxDepth | No | File-tree depth before collapsing (default 3). | |
| repoPath | No | A path inside the target repo. Defaults to the server's cwd. | |
| maxDocBytes | No | Max bytes per doc (default 4000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotency, single-commit behavior, and scope (tracked+non-ignored files, docs). No annotations exist, so description fully compensates.
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 with no fluff. Front-loaded with action, then consequences and usage advice.
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?
Complete for a side-effect tool: covers input, operation, idempotency, and use case. No output schema needed as write is the primary action.
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 covers 100% of parameters with good descriptions. Description adds context about how parameters relate to tool behavior (e.g., depth to tree), but doesn't detail each param.
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?
States specific verb 'scan' and resource 'git repo', enumerates outputs (overview, tree, docs). Distinguishes from siblings like memory_repo_info and 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?
Explicitly advises 'Run this once when adopting a repo to seed memory', clearly indicating when to use. Sibling tool names provide alternative contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the resolved identity and memory location for the current git repo.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description is minimal. Does not disclose what 'resolved identity' or 'memory location' entails, or any potential 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?
Single short sentence, no waste. But under-specified; conciseness without completeness reduces usefulness.
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?
Very incomplete: missing parameter explanation, return value, and usage context for a tool with no output schema or annotations.
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 has one parameter repoPath (optional, undocumented) and 0% schema description coverage. Description does not explain repoPath at all, leaving agents clueless.
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 uses specific verb 'Show' and resource 'resolved identity and memory location for the current git repo'. Clearly distinguishes from writing/ingesting/searching 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?
No guidance on when to use this tool vs alternatives. Lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve relevant memories for the current git repo, ranked by keyword match blended with confidence. Empty query returns the highest-confidence memories.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| type | No | ||
| limit | No | ||
| query | Yes | What to look for. Pass an empty string for top memories. | |
| repoPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions ranking and empty query behavior, but lacks details on side effects, auth, or performance.
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 sentences, front-loaded with action, no wasted 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?
Incomplete for a tool with 5 parameters and no output schema; lacks explanation of filters, limit, and repoPath usage.
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?
Only 20% schema coverage; description clarifies query parameter behavior but does not add meaning for tags, type, limit, or repoPath.
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 'retrieve' and specific resource 'memories for the current git repo'. Distinguishes from siblings by search behavior and ranking details.
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?
Implied usage for retrieving memories, but no explicit statement of when to use versus siblings like memory_ingest or memory_write.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a memory for the current git repo. Auto-creates the repo's git-backed memory store on first use and commits the write.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| type | No | fact | heuristic | failure | success | preference | reference | |
| title | No | Short title used for the filename/slug. | |
| source | No | Provenance, e.g. a run id. | |
| content | Yes | The memory body (markdown). | |
| repoPath | No | A path inside the target repo. Defaults to the server's cwd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool auto-creates the store and commits writes, but does not mention potential side effects like overwriting existing memories, git conflict handling, or permission requirements. The behavioral information is useful but incomplete.
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 long, front-loading the main purpose with no redundant or irrelevant information. Every word contributes to understanding, making it highly efficient.
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 moderate complexity (6 parameters, 1 required) and high schema coverage, the description is fairly complete. It adds context about the git-backed store and auto-creation. However, it lacks details on idempotency or behavior when a memory with the same title exists, which would improve 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 input schema covers 83% of parameters with descriptions, so the baseline is 3. The tool description adds no extra param-specific semantics beyond the schema, such as formatting or constraints on the 'content' or 'tags' parameters. It merely reiterates the overall behavior.
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 ('Persist a memory') and the resource ('for the current git repo'), and distinguishes the tool from siblings by highlighting auto-creation and git-backed store. It explains the side effect of committing the write, making the tool's function 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 implies this tool is for persisting a single memory, but it does not explicitly mention when to use it versus alternatives like memory_ingest (possible bulk ingestion) or when not to use it. No guidance on prerequisites or exclusion criteria is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: ingest scans and writes repo memories, repo_info shows identity, search retrieves memories, and write persists new ones. No overlap or ambiguity.
All tools start with 'memory_' prefix, but three use verbs (ingest, search, write) while one uses a noun phrase (repo_info). This slight inconsistency is minor but noticeable.
4 tools is appropriate for a focused memory MCP server. It covers the essential operations without being too few or too many.
Covers core operations (ingest, write, search, info) but lacks explicit update or delete functionality. The ingest tool is idempotent and can overwrite, but direct memory removal is missing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent, governed institutional memory for Claude Code — specs, decisions, learnings.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
Persistent, outcome-grounded episodic memory for Claude. 14ms CPU retrieval, no GPU, no vector DB.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Nanda-Kiran/yunaki-memory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
