Description
Quick disclosure so this is not mistaken for astroturf: I maintain Vestige, a local-first memory MCP server, so I am an interested party. I am not asking the collective to build or endorse anything. This is a small docs-recipe proposal, and I am happy to write the PR myself if you want it.
Nanocoder already treats MCP as a first-class extension surface (.mcp.example.json, project-level .mcp.json from #268, and the http/stdio entries like filesystem, github, and context7). The one gap I could not find covered by an existing issue is cross-session memory: each run starts cold, so decisions, corrections, and context from earlier sessions do not carry forward. I searched open and closed issues for "persistent memory" and "remember across sessions" and found none. #279 covered in-conversation token compaction and is closed, which is a different problem from durable memory between runs.
Use Case
Long or recurring work on a repo loses context every time the agent restarts: the same files get re-explained, past decisions get re-litigated, and corrections do not stick. A memory MCP server lets the agent recall and write durable notes across sessions without sending anything off the machine, which lines up with nanocoder staying local-first and telemetry-free.
Proposed Solution
Document an optional MCP entry in the existing .mcp.json schema. Vestige is a single Rust binary on npm, so it slots into the same npx -y stdio pattern your other examples use:
{
"mcpServers": {
"vestige": {
"transport": "stdio",
"command": "npx",
"args": ["-y", "vestige-mcp-server"],
"description": "Local-first cross-session memory for the agent"
}
}
}Install once with npm install -g vestige-mcp-server and storage stays local by default. Nothing changes in nanocoder core, this is purely a config recipe a user opts into.
For context on what it is: Vestige - Local-first cognitive memory MCP server for AI coding agents. FSRS-6 retention, prediction-error gating, active forgetting, spreading activation, 3D dashboard. Single Rust binary.
Alternatives Considered
A user can already add any MCP server by hand, so the only thing missing is a documented memory example, which is why this is a docs request rather than a code change. Other memory servers exist too. I am biased toward Vestige since I maintain it, but the recipe shape is the same for any of them, and I am totally fine if you prefer to document the category generically and link options.
Additional Context
Implementation Notes (optional)
Smallest version is a short subsection under the MCP servers config docs with the snippet above. If you want it, I will open the PR against the docs, keep it provider-neutral in tone, and you can cut anything that reads as promotion. Happy to drop into Discord first if that is the preferred way to scope it.
Description
Quick disclosure so this is not mistaken for astroturf: I maintain Vestige, a local-first memory MCP server, so I am an interested party. I am not asking the collective to build or endorse anything. This is a small docs-recipe proposal, and I am happy to write the PR myself if you want it.
Nanocoder already treats MCP as a first-class extension surface (
.mcp.example.json, project-level.mcp.jsonfrom #268, and the http/stdio entries like filesystem, github, and context7). The one gap I could not find covered by an existing issue is cross-session memory: each run starts cold, so decisions, corrections, and context from earlier sessions do not carry forward. I searched open and closed issues for "persistent memory" and "remember across sessions" and found none. #279 covered in-conversation token compaction and is closed, which is a different problem from durable memory between runs.Use Case
Long or recurring work on a repo loses context every time the agent restarts: the same files get re-explained, past decisions get re-litigated, and corrections do not stick. A memory MCP server lets the agent recall and write durable notes across sessions without sending anything off the machine, which lines up with nanocoder staying local-first and telemetry-free.
Proposed Solution
Document an optional MCP entry in the existing
.mcp.jsonschema. Vestige is a single Rust binary on npm, so it slots into the samenpx -ystdio pattern your other examples use:{ "mcpServers": { "vestige": { "transport": "stdio", "command": "npx", "args": ["-y", "vestige-mcp-server"], "description": "Local-first cross-session memory for the agent" } } }Install once with
npm install -g vestige-mcp-serverand storage stays local by default. Nothing changes in nanocoder core, this is purely a config recipe a user opts into.For context on what it is: Vestige - Local-first cognitive memory MCP server for AI coding agents. FSRS-6 retention, prediction-error gating, active forgetting, spreading activation, 3D dashboard. Single Rust binary.
Alternatives Considered
A user can already add any MCP server by hand, so the only thing missing is a documented memory example, which is why this is a docs request rather than a code change. Other memory servers exist too. I am biased toward Vestige since I maintain it, but the recipe shape is the same for any of them, and I am totally fine if you prefer to document the category generically and link options.
Additional Context
Implementation Notes (optional)
Smallest version is a short subsection under the MCP servers config docs with the snippet above. If you want it, I will open the PR against the docs, keep it provider-neutral in tone, and you can cut anything that reads as promotion. Happy to drop into Discord first if that is the preferred way to scope it.