Memory MCP Server: Persistent Agent Memory Stored as a Knowledge Graph

Most memory MCP servers store notes: files the model writes and reads back. The InfraNodus MCP server stores agent memory as a knowledge graph, so the memory is persistent across sessions, shared by every client you connect (Claude Desktop, Claude Code, Cursor, n8n), readable by you as a structure rather than a pile of notes, and able to report what it is missing. Claude.ai can carry context between its own chats and Claude Code reads CLAUDE.md at the start of a session; this is the layer for everything those two do not cover. Different kinds of memory behave differently, so the server serves them through different groups of MCP tools, which the model invokes depending on the layer a task touches.

The layers follow the AI memory stack methodology: content graphs for what your files contain, insight memory for what you realized in conversations, and agent learnings for what the model learned operating in your project. This page maps each layer to the MCP tools that write it, update it, and read it back — and to the skills that orchestrate those calls.

Install the Memory Server

https://mcp.infranodus.com

https://mcp.infranodus.com

claude mcp add infranodus -s user --transport http https://mcp.infranodus.com/mcp

{
  "mcpServers": {
    "infranodus": {
      "url": "https://mcp.infranodus.com"
    }
  }
}

codex mcp add infranodus --url https://mcp.infranodus.com
codex mcp login infranodus

{
  "mcpServers": {
    "infranodus": {
      "command": "npx",
      "args": ["-y", "infranodus-mcp-server"],
      "env": {
        "INFRANODUS_API_KEY": "your-api-key"
      }
    }
  }
}

/plugin marketplace add infranodus/skills
/plugin install infranodus@infranodus-skills

npx skills add infranodus/skills --skill infranodus -g -a claude-code -y

$skill-installer install the infranodus skill from https://github.com/infranodus/skills

npx skills add infranodus/skills --skill infranodus -g -a codex -y

npx skills add infranodus/skills --skill infranodus -g

Save what we concluded in this session to memory with memory_add_relations, then read back what the memory graph already holds about this project with memory_get_relations and tell me where it is thin.

Four Ways to Give an Agent Persistent Memory, Compared

If you work in Claude, you are probably choosing between these. They are not exclusive; most people end up with the first two plus one of the last two.

The Claude Code memory guide walks through the first two in detail and shows where the graph layer fits; the Graph Memory plugin fills the learnings graph from your sessions automatically, through hooks. For ten memory tools placed side by side by storage model, price and readability, see agent memory tools compared; for an Obsidian vault, start with Obsidian MCP. To analyze the memory you already have in the Claude app or Mem0, see Claude memory analysis.

Why Graph Memory Instead of a Memory Bank

Most MCP memory servers store notes — files the model can re-read later. That preserves content but not structure. Graph memory stores the relations: every remembered statement links the concepts it mentions, so the memory can be traversed (GraphRAG follows connections outward from your query instead of ranking similar chunks) and measured (which topics has the memory formed, which concepts hold them together, which areas never connect).

That last capability is the one a pile of memory files cannot have: the memory knows what it is missing. Gap detection works on remembered knowledge the same way it works on any knowledge base — and the gaps in what you and your agent have accumulated are where the next question comes from.

Layer 1 — Content Graphs: Memory of What Your Files Contain

The base layer of persistent memory is generated from your material — a vault, a repository, a folder of documents. The InfraNodus skill extracts it into saved knowledge graphs, records them in a manifest, and adds routing rules to CLAUDE.md so the model knows which graph answers which kind of question.

Tools the model invokes to write and maintain this layer:

• create_knowledge_graph — save extracted content (or an agent-written digest) as a named graph; repeated calls to the same graph append.
• delete_statements — remove one source file's statements by category before re-uploading its new version, so edits replace rather than duplicate.
• update_statements — relabel or correct statements in place (a renamed file, a fixed line) without touching their ids or dates.

Tools it invokes to read the layer back:

• retrieve_from_knowledge_base — GraphRAG retrieval: content questions answered from the statements, with graph traversal building the context.
• analyze_existing_graph_by_name — structure questions: topics, clusters, influential concepts.
• generate_contextual_hint — a lightweight structural overview injected as context before answering broad questions.
• generate_content_gaps — direction questions: what the remembered content is missing.
• generate_responses_from_graph — advice generated from the graph in its own voice.

Layer 2 — Insight Memory: What You Realized in Conversations

Realizations you reach while working with the model — a new connection between your concepts, a contradiction a structural analysis surfaced — evaporate when the session ends unless something records them. The insight layer uses the server's dedicated memory tools:

• memory_add_relations — save short relational statements, each linking at least two [[wikilinked]] concepts, with an ISO timestamp per statement. The timestamps turn the memory graph into a timeline of your thinking.
• memory_get_relations — recall everything previously concluded about a concept, from any connected client.

The convention that drives it is a marker-managed block in CLAUDE.md, installed by the InfraNodus skill when you opt in at its register step (--register-project --with-memory): at the end of a substantive session, the model distills the insights you arrived at, shows them, and calls memory_add_relations only on your approval. Nothing is written silently.

Layer 3 — Agent Learnings: What the Model Learned Operating in Your Project

An agent working in the same project keeps rediscovering the same traps — which folder is excluded, which call fails right after a graph is created, what chunk size an upload tolerates. The Project Learnings skill persists these through three dedicated tools:

• enable_project_learnings — creates the per-project learnings graph, only on your explicit request; nothing can be written before this.
• add_project_learnings — proposes typed learnings (trap, convention, workflow, decision, question, approach) as a dry run; writes only after you approve the batch.
• get_project_learnings — read at the start of a substantive task: the most relevant learnings for the task at hand, the areas that have accumulated knowledge, and the gaps.

This is the one layer the model reads automatically — which is safe precisely because it holds operational facts about the project, never ideas and never anything about you.

Which Tool for Which Memory

How the model routes a task to a layer and its tools:

The separation is what lets one MCP server hold all three kinds of memory without them contaminating each other: the same model, in the same session, reads learnings silently, queries content graphs on demand, and asks before it writes an insight.

Install It: the Skill, or a CLAUDE.md Block

The easiest path is the InfraNodus skill: when it builds your content graphs it offers to install the memory conventions into your project's CLAUDE.md too.

The installer at the top of this page adds the skill to Claude Code, Claude Desktop or Codex and runs it in your project.

If you are not using the skill, add the instructions to CLAUDE.md yourself. A template that covers all three memory graphs — adapt the project name and drop the layers you don't use:

## Project Memory (InfraNodus MCP)

Graphs in the user's InfraNodus account hold this project's accumulated
knowledge — keep them updated:

- **`learn-<project>`** (agent learnings): at the start of a substantive
  task, call `get_project_learnings` (project `<project>`) with the task
  as prompt; at the end, propose new traps / decisions / workflows via
  `add_project_learnings` — show the batch in chat for approval (the
  dry-run dialog may time out in some clients; keep statements under
  400 chars).

- **`<project>-insights`** (insight memory): at the end of a substantive
  session, distill the USER's new realizations — not agent mechanics,
  not file content — into short relational statements, each with at
  least two `[[wikilinked]]` entities and an ISO 8601 timestamp; show
  them and save on the user's OK via `memory_add_relations`. Recall
  earlier conclusions with `memory_get_relations`. Zero insights is a
  normal outcome — do not pad.

- **`<project>-memory`** (concept map, optional): the project's core
  concepts and architecture as relations. Query with
  `memory_get_relations`; when the architecture or concepts change,
  append updated statements via `memory_add_relations` with explicit
  `[[wikilinks]]` and a category per statement (e.g. concept / source /
  pipeline / platform).

The block does the routing for the model: which graph to read at the start of a task, which to write at the end of a session, and the approval gate on every write. Everything else — the tools themselves — comes from connecting the MCP server.

One Memory, Every Client

Because the memory lives in your InfraNodus account behind the MCP protocol rather than inside one application, it is client-independent: a graph written from Claude Code is readable from Claude Desktop, ChatGPT, Cursor, an n8n automation, or a local agent. Your agent's memory is not locked to the tool you happened to use that day — and you can inspect, edit, or delete any graph directly in the InfraNodus interface, because agent memory you cannot see is agent memory you cannot trust.

Set It Up

• The AI Memory Stack methodology
• Claude Code memory: CLAUDE.md, auto memory, and the graph layer
• Graph Memory plugin: learnings saved by hooks
• MCP Tools Catalog
• InfraNodus skill (content graphs)
• Project Learnings skill (agent learnings)
• LLM Wiki skill (curated pages)

FAQ

Can an MCP server give my AI agent persistent memory?

Yes. The InfraNodus MCP server stores memory as knowledge graphs in your account: content graphs generated from your files, a timestamped insight memory the model writes with your approval, and an append-only learnings graph agents read at the start of a task. Any client connected through MCP reads and writes the same memory.

Which MCP tools handle which kind of memory?

Content graphs: create_knowledge_graph to write, delete_statements / update_statements to maintain, retrieve_from_knowledge_base and the analysis tools to read. Insight memory: memory_add_relations / memory_get_relations. Agent learnings: enable_project_learnings / add_project_learnings / get_project_learnings. The model picks the group based on which layer the task touches.

How is this different from a memory bank or file-based memory server?

File-based memory stores notes the model can re-read. Graph memory also stores the relations between concepts, which makes it traversable (GraphRAG) and measurable — the memory can report its own topics, hubs, and gaps, which a pile of files cannot.

Does the model decide on its own what to remember?

No. Insight memory and agent learnings are proposed and saved only after you approve the batch; the learnings graph must be explicitly enabled per project first. Content graphs are generated from your files deterministically. Operational knowledge may be loaded automatically; intellectual knowledge stays reviewable.

What counts as long-term memory for an LLM here?

Anything that survives the session and is reachable through a tool call: the structure of your knowledge base, the approved insights with their timestamps, and the accumulated agent learnings. Each session starts by reading the relevant layer instead of re-deriving it — long-term memory rather than a longer context window.

Does Claude have memory?

Yes, two kinds, and both stop at the client. Claude.ai remembers facts and preferences across chats inside its own app, with settings to review and clear them. Claude Code reads CLAUDE.md and its auto-memory files when a session starts. Neither is shared with Cursor, n8n or another agent, neither can be queried by structure, and neither can tell you what it is missing. A memory MCP server fills that gap, and the table above compares the four options side by side.

How do I give an agent persistent memory across sessions?

Connect the InfraNodus MCP server to Claude Desktop, Claude Code or Cursor and install the InfraNodus skill. From then on the model can write what it learns to a graph in your account (memory_add_relations, add_project_learnings) and read it back at the start of the next session (memory_get_relations, get_project_learnings, retrieve_from_knowledge_base). The memory lives outside the client, so a new chat, a new machine or a different client sees the same thing.

Does Claude Code have memory, and how is MCP memory different from CLAUDE.md?

Claude Code reads CLAUDE.md and its auto-memory files when a session starts. That is memory you or the agent typed into files, read in full every time, and tied to one folder. MCP graph memory is queried instead of reread, is shared by every client you connect, and stores relations rather than paragraphs, so it can report which topics it holds and which it lacks. Keep both: CLAUDE.md for the rules, the graph for what the project and the agent have learned. See Claude Code memory.

Can I see and edit what Claude remembers?

Yes. Every memory layer is a graph in your InfraNodus account. Open it in the web app to see the clusters and the central concepts, filter by date, delete or rewrite statements, and the model reads the corrected version on its next call. Nothing is written to insight memory or agent learnings without your approval of the batch.