AI Agents on dotnetuniversity

MCP Context Mode: Session Memory and Context Management for GitHub Copilot

Fri, 21 Aug 2026 00:00:00 +0000

Every Copilot session has a limited context window. As a coding task grows, the conversation fills with file contents, terminal output, tool calls, errors, and decisions. When the context is compacted, Copilot can lose the details that explain what has already been investigated and what still needs to be done.

Context Mode is an MCP server and context-management tool designed for this problem. It keeps large tool output outside the model’s context, indexes useful project and session data locally, and retrieves relevant information when it is needed. Its documentation lists VSCode Copilot as a supported platform.

Context Mode focuses on the history of coding work and on controlling how much raw data reaches the model.

%%{init: {'theme': 'base'}}%% flowchart LR A[VS Code Copilot
Agent mode] -->|prompts + tool events| B[Context Mode
MCP tools + hooks] B -->|store and index| C[(Local SQLite + FTS5
session history + project index)] C -->|search relevant data| D[Focused context
snippets + next steps] D -->|restore context| A E[Large inputs
logs · files · APIs] -->|process outside chat| B B -->|return only useful data| F[Compact output
less context pressure] F --> A classDef copilot fill:#dbeafe,stroke:#2563eb,stroke-width:3px,color:#172b4d classDef mode fill:#fce7f3,stroke:#db2777,stroke-width:3px,color:#5e163d classDef storage fill:#dcfce7,stroke:#16a34a,stroke-width:3px,color:#24592b classDef result fill:#fef3c7,stroke:#d97706,stroke-width:3px,color:#604e12 classDef input fill:#f3f4f6,stroke:#6b7280,stroke-width:3px,color:#344054 classDef output fill:#fee2e2,stroke:#dc2626,stroke-width:3px,color:#7a2825 class A copilot class B mode class C storage class D result class E input class F output linkStyle 0 stroke:#2563eb,stroke-width:3px linkStyle 1 stroke:#db2777,stroke-width:3px linkStyle 2 stroke:#16a34a,stroke-width:3px linkStyle 3 stroke:#d97706,stroke-width:3px linkStyle 4 stroke:#6b7280,stroke-width:3px linkStyle 5 stroke:#dc2626,stroke-width:3px linkStyle 6 stroke:#dc2626,stroke-width:3px

The diagram shows the central idea: Copilot sends prompts and tool events to Context Mode, Context Mode stores or indexes the useful data locally, and only relevant snippets or summaries return to Copilot.

What You Will Build

You will investigate one small API exception to see how Context Mode stores useful project context and retrieves it in a later Copilot session:

Session 1: Investigate the GET /api/todos exception and fix its cause.

Session 2: What caused the exception, which file changed, and what test is missing?

In Session 1, Context Mode indexes the API log and records useful work. In Session 2, it retrieves the relevant result instead of making you repeat the investigation.

Use Context Mode in VSCode

There are two parts to a VSCode Copilot setup:

Add Context Mode as an MCP server so Copilot can call ctx_* tools.
Enable the Context Mode Copilot integration if you want automatic session capture and context restoration.

The MCP server alone gives Copilot context-processing tools. It does not automatically turn every existing Copilot conversation into searchable history.

Prerequisites

VSCode with GitHub Copilot Chat and agent mode enabled.
Node.js 20 or later and npx available in the integrated terminal.
A project folder where you can test the integration without exposing secrets.

Add the MCP Server

Open the Command Palette, run MCP: Open Workspace Folder MCP Configuration, and create or edit .vscode/mcp.json:

{
    "servers": {
        "context-mode": {
            "command": "npx",
            "args": [
                "-y",
                "context-mode"
            ]
        }
    }
}

The package and configuration options can change, so check the Context Mode repository when installing a newer version. After saving the file, use the MCP server controls in VSCode to start or restart context-mode.

Verify the Connection

Open Copilot Chat in agent mode and send this prompt:

Use Context Mode to run ctx doctor and report whether the MCP server,
runtime, SQLite/FTS5 search, and Copilot integration are ready.

You should see a context-mode tool call and a diagnostic result. If Copilot does not offer the tool, restart the MCP server and reload the VSCode window.

A Simple Scenario: Fix an API Exception

Assume a small ASP.NET Core Todo API returns HTTP 500 from GET /api/todos. The application writes this exception to app.log:

System.NullReferenceException: Object reference not set to an instance of an object.
    at TodoService.GetAll() in TodoService.cs:line 42

You want Copilot to find the exception in Session 1 and remember the fix in Session 2.

Session 1: Index the API Log

Send this prompt to Copilot:

Use Context Mode to index app.log.
Do not print the full file.

Context Mode chunks app.log and stores searchable content locally. The useful result is a small confirmation, not the complete log.

Session 1: Find the Exception

Now ask Copilot to search the indexed log:

Search the indexed app.log for the exception from GET /api/todos.
Explain the likely cause and identify the file to fix.

Context Mode searches the index and returns only the matching exception. Copilot can reason about the failure without loading the entire log.

Session 2: Retrieve the Previous Work

Close the first chat, start a new Copilot session, and send:

Continue the Todo API investigation from the previous session.
What caused the exception, which file changed, and what test is missing?

When the Copilot integration and hooks are active, Context Mode restores the relevant session context instead of replaying the complete conversation. Copilot can answer with the exception cause, changed file, and missing test.

Check Context Savings

Finish with this prompt:

Use Context Mode to show ctx stats for this session.
How much output was processed, and how much context was saved?

The exact numbers depend on file size, tool output, query shape, and the active adapter. Treat benchmark values from the repository as examples, not as a guarantee for every project.

The Context Window Problem

A coding agent receives more than your written prompt. It also receives tool input and tool output:

File contents
Directory listings
Git history
Build and test output
API responses
Logs
Browser or Playwright snapshots
Results from other MCP servers

Large responses consume context quickly. Reading fifty files directly may leave less room for reasoning about the implementation. Context Mode moves data processing closer to the tool call and returns a smaller result to the model.

For example, instead of placing a large log file into the conversation, an agent can process it and return only matching errors, counts, or summaries. Instead of loading an entire document, it can index the document and retrieve relevant sections later.

Core Capabilities

1. Session Continuity

Context Mode records useful events from a coding session, including prompts, decisions, tool activity, errors, and task progress. When a session is resumed or the context is compacted, it can restore relevant working state instead of forcing Copilot to start from an empty context.

The restored context can answer questions such as:

What caused the Todo API exception?
Which file did we change?
What test is still missing?

Session continuity is project-oriented. It is intended to help an agent continue development work, not to reproduce every message exactly as a chat export.

2. Local Session Storage

Context Mode stores session and indexed-content data locally in SQLite. Its search layer uses SQLite FTS5 and BM25 ranking to find relevant text. This gives the agent searchable history without requiring a separate database server.

The repository documents storage under a Context Mode data directory, with project-scoped content and session data. The exact location can vary by adapter and configuration, so inspect the installed version before backing up or changing retention behavior.

3. Context Reduction

Context Mode can run code, process files, batch operations, and inspect large outputs while returning only standard output or relevant matches. This reduces the amount of raw data added to the model context.

Its MCP tools include capabilities for:

Running code in a sandboxed subprocess
Processing a file without returning its full contents
Running multiple commands or searches in one operation
Indexing local files and directories
Fetching and indexing web pages
Searching indexed content
Fetching only selected observations or snippets

This is useful for repositories, logs, CSV files, API responses, and documentation that are too large to paste into a chat.

4. Full-Text Retrieval

The ctx_index tool chunks content while preserving useful structure such as headings and code blocks. The ctx_search tool then searches indexed content and returns focused snippets rather than an entire document.

Search supports relevance ranking, stemming, substring matching, proximity ranking, fuzzy correction, and smart snippets. These features make it possible to ask for a concept without knowing the exact wording used in the original file.

5. Web and Document Retrieval

Context Mode can fetch a URL, convert it to searchable content, and index it. A later query can retrieve relevant sections without placing the entire web page in the conversation.

It also supports cache behavior for previously indexed URLs. This can avoid repeated downloads and reduce repeated context usage for stable documentation.

6. Tool Routing

On supported platforms, hooks can guide or enforce routing of large operations through Context Mode. The purpose is to prevent a large file, log, or external MCP response from consuming the context window unnecessarily.

This is stronger than a system prompt alone. A prompt can tell the model to use a context tool, while a hook can intercept tool activity and redirect or block selected operations, depending on the platform integration.

7. Statistics and Diagnostics

Context Mode provides utility commands for inspecting its operation:

ctx stats    -> context savings and session statistics
ctx doctor   -> runtime, hook, SQLite, and installation diagnostics
ctx index    -> index a file or directory
ctx search   -> search indexed content
ctx purge    -> remove indexed content

These commands help verify that the integration is active and show how much context has been saved.

How Session Continuity Works

A simplified flow looks like this:

%%{init: {'theme': 'base'}}%% graph LR A[Copilot prompt] --> B[Context Mode hooks] B --> C[Session and tool events] C --> D[(Local SQLite and FTS5)] D --> E[Relevant context retrieval] E --> F[Copilot continues task] classDef copilot fill:#dbeafe,stroke:#2563eb,stroke-width:3px,color:#1e3a8a classDef mode fill:#fce7f3,stroke:#db2777,stroke-width:3px,color:#5e163d classDef events fill:#fef3c7,stroke:#d97706,stroke-width:3px,color:#78350f classDef storage fill:#dcfce7,stroke:#16a34a,stroke-width:3px,color:#14532d class A,F copilot class B mode class C events class D storage class E copilot linkStyle 0 stroke:#2563eb,stroke-width:3px linkStyle 1 stroke:#db2777,stroke-width:3px linkStyle 2 stroke:#d97706,stroke-width:3px linkStyle 3 stroke:#16a34a,stroke-width:3px linkStyle 4 stroke:#2563eb,stroke-width:3px

During a long task, Context Mode captures useful session events. Before compaction, it can create a resumable snapshot. When the agent starts or resumes again, the integration retrieves relevant project and session context and makes it available to the model.

The important detail is selective retrieval. The entire previous conversation does not need to be inserted into the new context window. The agent searches for the current task and receives the most relevant observations.

What Context Mode Does Not Do

Context Mode is not a complete archive of every Copilot chat stored by GitHub. It cannot recover sessions that happened before it was installed or before its integration was enabled.

It also does not guarantee that every Copilot event is captured on every platform. Hook support, session-start behavior, compaction handling, and context injection depend on the client adapter and the installed version. Verify the integration with its diagnostic command before relying on it for important work.

Automatic history capture also requires privacy discipline. Prompts, file paths, tool inputs, command output, and source code can contain secrets or personal information. Configure exclusions, avoid indexing sensitive files, and inspect the local data directory before sharing or committing it.

When to Use Context Mode

Context Mode is a strong fit when:

A coding task spans many Copilot interactions.
Context compaction causes repeated explanations.
Tool output is larger than the useful answer.
You need to search project history or indexed documentation.
You want local session storage and FTS5 search.
You use VSCode Copilot or another supported coding-agent client.

Conclusion

Context Mode gives coding agents a second layer of memory: searchable working history and context management. It can preserve prompts, decisions, tool activity, errors, and next steps while keeping large raw outputs outside the model’s context.

For VSCode Copilot, Context Mode is most useful when Copilot needs to continue a complicated coding task, search previous project activity, or work with large files and tool responses without filling the context window.

Reference

Server Memory for MCP: Knowledge Graph Memory in Copilot

Mon, 20 Jul 2026 00:00:00 +0000

Every time you open a new Copilot chat, the model starts fresh. It does not remember that you chose PostgreSQL, prefer Minimal APIs, or work on a project called MemorySample. Large language models are stateless — they only see what fits in the current context window, and a new session starts with an empty one.

The MCP Memory Server changes this. It is the official reference implementation of persistent memory for MCP clients. It stores facts as a local knowledge graph of entities, relations, and observations in a plain-text memory.jsonl file, and exposes tools that Copilot can call to save and retrieve those facts.

In this post, we will walk through a real VSCode workflow: we teach Copilot a few facts about ourselves and our project in one session, close the chat, open a brand-new session, and ask a question that only makes sense if Copilot still remembers the previous context. Then we will inspect the underlying file and look at what makes memory actually work well.

What You Will Build

You will teach Copilot a few facts about yourself and your project in Session 1, close the chat, open a Session 2, and ask a question that only makes sense if Copilot still remembers the previous context. Then you will inspect the underlying memory.jsonl file to see how the data is stored.

Session 1: "I work on a .NET microservice called MemorySample. I use .NET 10, EF Core with PostgreSQL, and I prefer WolverineFx over MassTransit." Session 2: “Suggest an architecture for the next feature in MemorySample.”

Copilot answers using .NET 10, EF Core, PostgreSQL, WolverineFx, and Minimal APIs.

Everything in this post was verified against the real server — the tool calls, the JSON responses, and the memory.jsonl content below come from running @modelcontextprotocol/server-memory and driving it over MCP.

How the Memory Server Works

Before the step-by-step walkthrough, it helps to understand what the server actually does under the hood. The MCP Memory Server is a small Node.js process that speaks the MCP protocol over standard input/output. Copilot launches it through the mcp.json configuration and then calls its tools like any other MCP tool. The same server works with any MCP client — Claude Desktop, VSCode Copilot, Cursor — because they all speak the same protocol.

The Knowledge Graph Model

Memory is stored as a knowledge graph with three building blocks:

Entity — a node. It has a unique name, an entityType (for example person, project, technology_stack), and a list of observations.
Relation — a directed edge between two entities. It has from, to, and a relationType written in active voice (for example works_on).
Observation — an atomic fact attached to an entity (one fact per observation).

This is why the memory server can answer questions like “what tech stack do I prefer?” — the facts live on the John_Doe entity, and the relations tell Copilot how that entity connects to your projects and tools.

%%{init: {'theme': 'base'}}%% graph LR A["Session 1
You share facts"] -->|"create_entities
create_relations"| B["memory.jsonl
entities + relations"] B -->|"read_graph
search_nodes
open_nodes"| C["Session 2
New chat"] C --> D["Contextual answer
without repeating facts"] classDef session fill:#dbeafe,stroke:#2563eb,stroke-width:3px,color:#1e3a8a classDef storage fill:#fce7f3,stroke:#db2777,stroke-width:3px,color:#5e163d classDef answer fill:#dcfce7,stroke:#16a34a,stroke-width:3px,color:#14532d class A session class C session class B storage class D answer

Storage: A File, Not a Database

The most common question is: does the memory server use a database? No. There is no database server, no connection string, and no schema migration. You cannot plug in PostgreSQL, SQLite, or MongoDB — the official server is deliberately file-based. Storage is a single plain-text JSONL file — one JSON object per line. By default the server writes memory.jsonl next to its own package files, which is why you must set MEMORY_FILE_PATH to point at a stable location inside your project.

The file has two advantages:

Portable — copy the file and the memory moves with it. You can commit it to your repository or back it up like any text file.
Human-readable — you can open it in any editor and see exactly what the model knows about you.

Every time Copilot calls a tool, the server reads the file, applies the change in memory, and writes the whole file back. The file is the database.

Alternatives and Complementary Tools

The official MCP Memory Server is intentionally small and explicit. Other tools focus on automatic session capture, semantic memory, or reducing the amount of data sent to the model:

Context Mode — A local context-management and session-continuity tool for coding agents. It indexes project content and session events in SQLite with FTS5, restores relevant context after compaction, and reduces large tool outputs before they reach the context window. It specifically documents VSCode Copilot support.
Claude-Mem — Captures coding-session observations, prompts, tool activity, and summaries, then stores them in SQLite and makes relevant history searchable. It is strongest in Claude Code, so verify the current adapter before relying on automatic capture in VSCode Copilot.
Mem0 — A memory layer for AI applications and agents. It extracts user, session, and agent memories and supports semantic, keyword, and entity-based retrieval. It is a better fit for building a production memory backend than for simple Copilot configuration.
Supermemory — An automatic memory and context engine that builds user profiles, tracks project context, and provides semantic search through MCP. It supports VSCode and can run through its hosted service or local self-hosted mode.

Choose the official server for transparent, file-based facts; Context Mode or Claude-Mem for coding-session history; Mem0 for building an application memory layer; and Supermemory for automatic long-term user and project profiles.

The official MCP Memory Server keeps storage simple: it uses a plain JSONL file, not a database.

Why Memory Survives Across Sessions

A chat session is ephemeral — it is a window into a conversation and disappears when you close it. The memory file is not. This is the key to the whole system:

All sessions share one file. Every Copilot chat starts the server with the same MEMORY_FILE_PATH, so every session reads and writes the same memory.jsonl.
The file outlives the chat. When you close Session 1, the chat history is gone, but the file stays on disk with everything the model saved.
Nothing is lost between sessions. Each tool call performs a read-modify-write: the server reads the whole file, applies your change, and writes the file back. Facts added in Session 1 are still there when Session 3 or Session 10 starts.
Retrieval is on demand. In a new session the model does not automatically know the old facts. It pulls them back with read_graph, search_nodes, or open_nodes — that is how a new session “remembers” what an old session learned.

So the model is still stateless — but the memory is not. The file is the bridge between sessions, and the tools are how Copilot crosses it.

Prerequisites

VSCode with the GitHub Copilot extension.
Node.js installed so npx works.
The MCP Memory Server package: @modelcontextprotocol/server-memory.

Step 1: Configure the Memory Server in VSCode

Open the Command Palette with Ctrl + Shift + P and run MCP: Open User Configuration (or add a .vscode/mcp.json file to your project). Add the memory server — the same config works on Windows, macOS, and Linux, because npx runs the server directly on every OS with no cmd /c wrapper:

{
  "servers": {
    "memory": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-memory"
      ],
      "env": {
        "MEMORY_FILE_PATH": "/home/yourname/projects/my-project/memory.jsonl"
      }
    }
  }
}

Here is what each part of the configuration means:

command and args — how VSCode launches the server process. npx runs the npm package directly on any OS, so one config works everywhere.
env.MEMORY_FILE_PATH — the absolute path of the memory.jsonl file where all memory is stored. This is the most important line in the whole file.

Most important detail #1: Always set MEMORY_FILE_PATH to a stable, absolute path. If you skip this, the server writes memory.jsonl next to the package cache and your memory can disappear on the next npx install.

After saving, open the Copilot Chat side panel. You should see the memory server listed as an available tool. If it is missing, reload VSCode with Developer: Reload Window.

flowchart LR A[.vscode/mcp.json] --> B[Memory server] B --> C[Copilot Chat] C --> D[Memory tools available] classDef config fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef server fill:#fce7f3,stroke:#db2777,stroke-width:2px,color:#5e163d classDef copilot fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d class A config class B server class C,D copilot

Step 2: Seed Memory in Session 1

Start a new Copilot Chat and tell it about your project. Be explicit so the model extracts the right entities.

You:

Remember these facts for later:
- My name is John Doe.
- I work on a .NET microservice project called MemorySample.
- MemorySample uses a Vertical Slice Architecture with feature folders.
- My preferred stack is .NET 10, EF Core with PostgreSQL, Minimal APIs, and WolverineFx for messaging.
- I prefer xunit.v3 for tests.

Copilot will call create_entities and create_relations on your behalf. The resulting knowledge graph looks like this:

flowchart LR A[Your facts] --> B[create_entities] A --> C[create_relations] B --> D[(memory.jsonl)] C --> D D --> E[Knowledge graph] classDef input fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef tool fill:#fce7f3,stroke:#db2777,stroke-width:2px,color:#5e163d classDef store fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d class A input class B,C tool class D,E store

Entity	Type	Observations
`John_Doe`	person	Prefers vertical slice architecture; likes WolverineFx over MassTransit; uses PostgreSQL; favorite IDE is VSCode
`MemorySample_Project`	project	.NET 10 microservice; Vertical Slice Architecture with feature folders; tested with xunit.v3
`DotNet_TechStack`	technology_stack	.NET 10; EF Core + PostgreSQL; Minimal APIs; xunit.v3

Relations:

John_Doe → works_on → MemorySample_Project
John_Doe → prefers → DotNet_TechStack

Under the hood, Copilot sends a tools/call request to the memory server. This is the real request and response from memory-server v0.6.3:

{
  "name": "create_entities",
  "arguments": {
    "entities": [
      { "name": "John_Doe", "entityType": "person", "observations": [
        "Prefers vertical slice architecture in .NET",
        "Likes WolverineFx over MassTransit for transactional messaging",
        "Uses PostgreSQL as default database",
        "Favorite IDE is VSCode with Copilot"
      ]},
      { "name": "MemorySample_Project", "entityType": "project", "observations": [
        "Is a .NET 10 microservice",
        "Uses Vertical Slice Architecture with feature folders",
        "Is tested with xunit.v3"
      ]},
      { "name": "DotNet_TechStack", "entityType": "technology_stack", "observations": [
        "Primary framework is .NET 10",
        "Uses Entity Framework Core with PostgreSQL",
        "Prefers Minimal APIs over controllers",
        "Uses xunit.v3 for testing"
      ]}
    ]
  }
}

After the chat, close the panel. The data is already on disk.

Step 3: Inspect the Memory File

Open the file at MEMORY_FILE_PATH. Each line is a JSON object. Entities are stored with a type field of entity, relations with type of relation — this is the JSONL format used by the current version of the server:

{"type":"entity","name":"John_Doe","entityType":"person","observations":["Prefers vertical slice architecture in .NET","Likes WolverineFx over MassTransit for transactional messaging","Uses PostgreSQL as default database","Favorite IDE is VSCode with Copilot"]}
{"type":"entity","name":"MemorySample_Project","entityType":"project","observations":["Is a .NET 10 microservice","Uses Vertical Slice Architecture with feature folders","Is tested with xunit.v3"]}
{"type":"entity","name":"DotNet_TechStack","entityType":"technology_stack","observations":["Primary framework is .NET 10","Uses Entity Framework Core with PostgreSQL","Prefers Minimal APIs over controllers","Uses xunit.v3 for testing"]}
{"type":"relation","from":"John_Doe","to":"MemorySample_Project","relationType":"works_on"}
{"type":"relation","from":"John_Doe","to":"DotNet_TechStack","relationType":"prefers"}

This file is the entire secret. It is plain text, local, and portable. You can back it up, version it, or move it to another machine — the memory comes with it.

Most important detail #2: Memory is only as good as the file path. Treat memory.jsonl like a small database. Back it up.

Step 4: Use Memory in Session 2

Open a new Copilot Chat. Do not repeat the project facts. Ask something that depends on them.

You:

I want to add a new feature to MemorySample. Suggest the architecture and tech stack.

Copilot starts by calling read_graph or search_nodes. Here is the real search_nodes call and response when we searched for WolverineFx — notice how the server returns the matching entity together with its relations:

{
  "name": "search_nodes",
  "arguments": { "query": "WolverineFx" }
}

{
  "entities": [
    {
      "name": "John_Doe",
      "entityType": "person",
      "observations": [
        "Prefers vertical slice architecture in .NET",
        "Likes WolverineFx over MassTransit for transactional messaging",
        "Uses PostgreSQL as default database",
        "Favorite IDE is VSCode with Copilot"
      ]
    }
  ],
  "relations": [
    { "from": "John_Doe", "to": "MemorySample_Project", "relationType": "works_on" },
    { "from": "John_Doe", "to": "DotNet_TechStack", "relationType": "prefers" }
  ]
}

It finds John_Doe, MemorySample_Project, and DotNet_TechStack. The answer is now contextual instead of generic.

Copilot (example response):

For the new feature in MemorySample, I would suggest: - .NET 10 Minimal API as the host. - Vertical Slice Architecture with feature folders. - EF Core 10 with PostgreSQL for persistence. - WolverineFx for messaging if the feature needs durable handlers or outbox. - xunit.v3 with TestContainers for integration tests.

This matches your existing DotNet_TechStack and the style you already use in MemorySample_Project.

Notice that the model did not ask “What is your stack?” It answered directly because the memory server bridged the two sessions.

flowchart LR A[New Copilot chat] --> B[search_nodes] B --> C[Matching entities and relations] C --> D[Contextual answer] classDef chat fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef tool fill:#fce7f3,stroke:#db2777,stroke-width:2px,color:#5e163d classDef result fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d class A,D chat class B tool class C result

Step 5: Add More Facts Across Sessions

Memory gets more useful over time. In a third session, you add a new observation.

You:

Also remember: I am currently learning about agent memory systems and writing documentation about the MCP Memory Server.

Copilot calls add_observations on John_Doe. Again, the real request and response:

{
  "name": "add_observations",
  "arguments": {
    "observations": [
      {
        "entityName": "John_Doe",
        "contents": [
          "Currently learning about MCP memory systems",
          "Writing documentation about the MCP Memory Server"
        ]
      }
    ]
  }
}

[
  {
    "entityName": "John_Doe",
    "addedObservations": [
      "Currently learning about MCP memory systems",
      "Writing documentation about the MCP Memory Server"
    ]
  }
]

In a fourth session, you can ask:

What am I currently learning about?

Copilot searches the graph, finds the observation, and answers without you repeating the topic.

What Makes Memory Work Well

The memory server is simple, but a few patterns decide whether it helps or gets in the way. These are the most important parts of using memory.

1. Atomic Observations

One fact per observation. Good:

"Uses PostgreSQL as default database"
"Prefers Minimal APIs over controllers"

Bad:

"Uses PostgreSQL and Minimal APIs and likes WolverineFx"

Atomic facts make search precise and deletions safe.

2. Stable, Unique Entity Names

Use John_Doe instead of John. If a second John appears, the graph still works.

3. Active Voice Relations

Relations are directed. Use works_on, prefers, subscribed_to. Avoid passive forms like is_used_by where the direction is unclear.

4. A System Prompt That Triggers Memory

Without guidance, the model may not call read_graph at the start of a chat. Add custom instructions in VSCode:

Before answering, retrieve relevant facts from the memory knowledge graph.
When you learn new facts about the user, their projects, or their preferences,
create entities and relations, and store atomic observations.

Most important detail #3: Memory does nothing unless the model is reminded to use it. A system prompt or custom instruction is required.

flowchart LR A[Custom instruction] --> B[Retrieve relevant memory] B --> C[Copilot uses memory tools] C --> D[More contextual answers] classDef instruction fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef tool fill:#fce7f3,stroke:#db2777,stroke-width:2px,color:#5e163d classDef result fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d class A instruction class B,C tool class D result

Common Pitfalls

Problem	Cause	Fix
Memory is lost after restart	`MEMORY_FILE_PATH` not set or points to a temp directory	Use an absolute path in `mcp.json`
Copilot ignores memory	No custom instruction triggers retrieval	Add a system prompt
Graph grows with noise	Observations are too long or duplicated	Keep facts atomic, one per line
Search returns wrong nodes	Entity names are too generic or change between sessions	Use stable, unique names

Conclusion

The MCP Memory Server turns Copilot from a stateless chat into an assistant that remembers your project across days. The workflow is simple: configure the server with a stable MEMORY_FILE_PATH, seed facts in one session, and let read_graph, search_nodes, and open_nodes bring that context into every new session.

The three most important details to remember:

The file path is everything — point MEMORY_FILE_PATH at a stable absolute location and back it up like a database.
Atomic, well-named data — one fact per observation, stable entity names, active-voice relations.
A prompt that triggers memory — the model only uses the tools if you tell it to.