You ask one agent to research a vendor. It reads the docs, extracts the pricing model, writes a summary — and that knowledge dies with the session. Two days later, a different agent, working on the same project for the same team, has to rediscover it from scratch, because there was never a shared place to put it.
This isn’t a “context window” problem. It’s a coordination problem. Every agent, every tool, every session tends to keep what it learns to itself. Multiply that across a team running several agents on the same project — a research agent, a coding agent, a support agent — and you get the same facts rediscovered independently, sometimes inconsistently, because nothing connects what one agent knows to what another needs.
What’s missing isn’t a bigger prompt. It’s a shared layer of memory that any authorized agent — or person — can read from and write to, so knowledge accumulates once and stays available to everyone who’s supposed to see it.
That’s what Memory-MCP is: a remote MCP (Model Context Protocol) server for storing, searching, and forgetting memories, organized into multi-tenant spaces and protected by API keys — designed so multiple agents and teammates can genuinely share what they know, without stepping on each other or leaking into contexts they shouldn’t.
Memory-MCP exposes a small set of MCP tools — search_memory, add_memory, listMemories, listDocuments, getDocument, listSpaces, whoAmI — plus resources, a context prompt, and interactive widgets. Any MCP-capable client can connect over HTTP with an API key: Claude Desktop, an agent built on the Claude Agent SDK, a CI pipeline, MCP Inspector — anything speaking the protocol.
The unit that makes sharing possible is the space: a logical container for a project, a client, or a domain. What makes it a genuine collaboration mechanism rather than just a namespace is how access is granted. An API key isn’t tied to one agent — it’s tied to one identity (a person, a service, an automation), with Read or ReadWrite permission on each space it's allowed to touch, and one space marked as its default. Give three different agents three different keys, all granted ReadWrite on the same acme-project space, and every fact one of them saves is immediately visible to the other two on their very next search_memory call — no export, no sync job, no copy-pasting a summary between chat windows.
A few design choices only make sense once you stop thinking of memory as “one agent’s private cache” and start thinking of it as a surface multiple agents read and write concurrently.
Atomic facts instead of whoever-wrote-it-last text blobs. When content is saved through add_memory, an IFactExtractor doesn't just store the raw paragraph — it decomposes it into atomic, self-contained facts ("Alex left Stripe in March"), each becoming its own memory. That matters a lot more once several contributors are writing into the same space over time: atomic facts are unambiguous to combine, re-rank, and search, in a way that competing free-text paragraphs from different agents are not.
Relations that reconcile contributions instead of just concatenating them. If a new fact updates, extends, or derives from an existing one — regardless of which agent originally wrote that existing one — a typed graph edge (Updates / Extends / Derives) is created at save time, and an Updates relation automatically deactivates the memory it supersedes. This is the piece that makes multi-agent writing safe: agent B correcting something agent A wrote yesterday doesn't produce two contradictory memories sitting side by side — it produces a coherent, superseding chain that search_memory's relatedMemories surfaces automatically.
Spaces as a hard boundary, not a soft convention. Because access is enforced per space at the API key level — not by an agent politely deciding what’s relevant — a support agent scoped to customer-x structurally cannot see or pollute customer-y's memory, even if both are backed by the same Memory-MCP instance. Sharing within a space is deliberate and total; leakage across spaces isn't possible by construction.
**category and **keyword as shared vocabulary. When several contributors write into the same space, category becomes a lightweight shared taxonomy ("pricing", "incidents", "decisions") that any agent can filter on, and keyword/fuzzy search (more on that below) means a teammate searching by hand doesn't need to remember the exact phrasing another agent used when it saved the fact.
A context prompt that hands off state cleanly. The context MCP prompt returns a ready-to-attach message — the active space's recent profile, plus other recently active spaces — which is as useful for onboarding a new agent into an ongoing shared space as it is for resuming a session: whoever picks up the work next starts from what the group already knows, not from an empty conversation.
Memory-MCP is a .NET 10 / ASP.NET Core project, built as Clean Architecture with dependencies flowing one way — Api → Infrastructure/Application → Domain:
Memory-MCP/├── Domain/ # Pure entities: Space, ApiKey, Document, Memory — zero framework dependencies├── Application/ # Use cases: IMemoryService, IEmbeddingProvider, repository interfaces├── Infrastructure/ # EF Core, Postgres, the embedding provider, the fact extractor└── Api/ # ASP.NET Core host: MCP tools/resources/prompts as thin adapters
Every tool in Api/Tools does exactly three things: resolve the access context, call an application service, format the output. That separation is what lets the same IMemoryService back search_memory, the MCP resources, the context prompt, and every interactive widget identically — whichever surface an agent or a human happens to be using, the sharing and access-control rules behind it are enforced in exactly one place.
Persistence is plain PostgreSQL via EF Core. Embeddings are stored as native Postgres real[] arrays, and IEmbeddingProvider is pluggable across OpenAI, Azure OpenAI, or Gemini.
When add_memory saves content, an LLM-backed IFactExtractor splits it into atomic facts and classifies each fact's relationship to a handful of similar existing memories — regardless of who or what originally wrote them. Each fact becomes its own row; each relation becomes a typed, directed MemoryEdge.
Traversing that graph — “what’s connected to this memory, up to two hops away” — doesn’t need a dedicated graph database: it’s a WITH RECURSIVE CTE over a plain memory_edges table, bounded by a hop count and a visited-node array to guarantee termination. search_memory attaches each top match's related memories to the result, so whoever — or whichever agent — searches next gets the reconciled picture, not just the most recent write.
If no extraction model is configured, none of this breaks: add_memory falls back to saving the whole content as a single flat memory. Graph memory is additive on top of shared storage, not a hard dependency of it.
Not every feature came from a grand design session. search_memory's keyword parameter started as a plain case-insensitive ILIKE '%keyword%' match — fine until a teammate searches for something a different agent phrased slightly differently, or just mistypes it.
The fix is PostgreSQL’s pg_trgm extension, exposed through EF Core as TrigramsAreWordSimilar / TrigramsWordSimilarity, backed by a GIN trigram index. The interesting part was resisting the instinct to lower the similarity threshold below Postgres's default of 0.6 to catch more typos. Testing that instinct against real data:
word_similarity('migraiton', 'migration') = 0.5 -- a real typo, useful to catchword_similarity('recieve', 'receive') = 0.375 -- also a real typoword_similarity('plan', 'plant') = 0.8 -- NOT a typo, false positiveword_similarity('sky', 'skip') = 0.5 -- NOT a typo, false positive
Short keywords are inherently noisy under trigram similarity: a 4-letter word only has two or three trigrams, so any partial overlap scores deceptively high. Lowering the threshold to catch recieve/receive would also start matching plan/plant as if they were typos of each other — actively worse for a shared space where multiple people search by hand with their own habits and typos. The default threshold stayed, documented explicitly in the codebase, because in a shared search surface, precision matters as much as recall.
For MCP clients that support MCP Apps, Memory-MCP ships four widgets that render inside the conversation: a searchable space picker, a guided save form, a file upload flow (text, Markdown, CSV, and PDF via PdfPig), and a force-directed graph of a space's memories and relations. These matter specifically because the memory isn't private to one agent's session — a teammate can open the graph widget and see what the team's agents have collectively learned, correct a fact through the same guided-save form an agent would use, or switch which shared space they're currently working in. The widgets are thin: each is a small postMessage-based bridge to the same tools and resources any agent calls, so a human and an agent editing the same space go through identical rules.
Worth saying plainly: this was built where Docker Desktop is blocked by company policy and the available Postgres has neither pgvector nor admin rights to install it. The original spec called for pgvector with an HNSW index and a dedicated graph database. Neither was available, so both became deliberate trade-offs instead of blockers: cosine similarity computed in-app over a plain real[] column, a recursive CTE instead of a graph engine, pg_trgm — a contrib extension needing no elevated privileges — instead of anything requiring installation. Every one of these is documented in the codebase as a conscious choice, with a note on what migrating to the "ideal" version would take if the constraint ever lifts.
Memory-MCP runs anywhere .NET 10 and Postgres run — locally via dotnet run, in Docker via the provided docker-compose.yml, or deployed to Fly.io (coming soon). Give each agent (or each teammate) its own API key scoped to the spaces it should share, point Claude Desktop or your agent framework at the /mcp endpoint, and the same shared memory shows up identically across every one of them.
Full setup instructions and the reasoning behind every trade-off mentioned here live in the repo: https://github.com/alex1976/Memory-MCP.
The roadmap is explicit about what’s deferred: a real graph database (Neo4j) if a space’s graph outgrows recursive CTEs, a native vector index (Qdrant or pgvector, if it becomes available) as more agents share more history in the same space, and richer document ingestion — Word, image OCR, audio transcription — for the upload widget.
None of it changes the core bet: the more agents and people work on the same problem, the more valuable it is that what one of them learns doesn’t stay locked in a single conversation.
Memory-MCP: A shared memory layer for AI Agents that work as a team was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.