DEV Community: Abhi A

How to Give Your Dev Team Shared AI Memory with MCP (Step-by-Step)

Abhi A — Fri, 29 May 2026 02:07:26 +0000

Your Claude Code session knows your project inside out. Your teammate's Claude Code session knows nothing. Every morning, one of you re-explains the architecture, the conventions, the decisions you already made — to an AI that was there for all of it yesterday, just in someone else's session.

This is the setup guide for fixing that. By the end, your entire team's AI sessions — Claude, Cursor, Codex, whatever — will read and write to the same knowledge store. When your teammate commits a decision at 2am, your morning session already knows about it.

We're using Context Cloud, which is the only MCP memory server with shared team workspaces. The whole setup takes about 10 minutes.

Step 1: Create your account

Go to contextcloud.pro and sign up. You'll land on the onboarding flow, which walks you through connecting your first AI tool.

When you sign up, Context Cloud automatically creates a "Getting Started" knowledge base with 20 pre-embedded chunks that explain how the system works. Your AI can query this immediately to understand the tools it has access to.

Step 2: Create a workspace for your project

Workspaces are how you scope knowledge. Think of them like repos — one workspace per project or service.

Click "New Workspace" from the home screen. Give it a name that matches your project ("Backend API", "Mobile App", whatever your team calls it). Each workspace gets its own set of knowledge bases, its own team members, and its own access controls.

Inside a workspace, you'll create knowledge bases. A knowledge base is a scoped collection of knowledge — you might have one for "Backend API" and another for "Infrastructure" within the same workspace. The AI handles routing between KBs based on what you're talking about.

Step 3: Invite your teammates

Go to the Team tab in your workspace. Add teammates by email. They'll get an invite link via email, click it, create their account, and land directly in the shared workspace.

Roles matter here:

Owner: full access, can invite/remove members, delete workspace
Editor: can read and write knowledge, manage KBs
Viewer: can read knowledge but not commit new chunks

For most dev teams, everyone should be an Editor. The Owner is whoever created the workspace.

Step 4: Connect your AI tool

Context Cloud works with Claude (web, desktop, and Code), Cursor, Codex, and Windsurf. Here's the setup for each:

Claude (web & desktop)

The simplest path. Go to Settings → Connectors → Add custom connector. Paste this URL:

https://api.contextcloud.pro/mcp/protocol

Claude Code (CLI)

Add to your MCP config (usually ~/.claude/settings.json or your project's .mcp.json):

{
  "mcpServers": {
    "context-cloud": {
      "url": "https://api.contextcloud.pro/mcp/protocol"
    }
  }
}

Cursor / VS Code / Windsurf

Add to your MCP settings:

{
  "mcpServers": {
    "context-cloud": {
      "command": "npx",
      "args": ["@contextcloud/mcp-client"],
      "env": {
        "CNTXT_API_KEY": "your-api-key-here"
      }
    }
  }
}

Get your API key from the workspace Settings tab in the dashboard.

Codex

Go to Settings → MCP → Add Streamable HTTP server. Paste the URL:

https://api.contextcloud.pro/mcp/protocol

Authorize when prompted.

Step 5: Commit your first knowledge

This is where it gets real. Open your AI tool and start working normally. When something important comes up — an architecture decision, a convention, a finding — tell your AI to save it.

Here's what that looks like in practice:

You: "We decided to use Postgres over MySQL because the client's DBA only supports Postgres. This is a hard constraint and won't change. Save this as a decision to our Backend API knowledge base."

Context Cloud extracts this as a typed decision chunk with the rationale, timestamps it, attributes it to you, and stores it in the shared knowledge base. Your AI handles the extraction — you just talk normally and say "save this."

A few more examples of things worth committing:

Decision: "We're using JWT in httpOnly cookies for auth — security team requirement, non-negotiable."
Convention: "All API routes use camelCase. Database columns use snake_case. No exceptions."
Finding: "The Stripe webhook fires twice on subscription changes — always check the idempotency key before processing."
State: "Auth module refactor is 70% done. Token validation extracted, middleware updated, tests pending."

The key thing to understand: you don't save everything. CLAUDE.md is for static instructions (linting rules, project structure). Context Cloud is for knowledge that emerges from work — decisions, findings, conventions that your team discovers along the way.

Step 6: Recall from your teammate's session

This is the moment that matters. Your teammate opens their AI tool — could be a completely different tool on a completely different machine. They ask about the project:

Teammate: "Check my memory — what do we know about the database setup?"

Context Cloud returns your decision with full attribution:

Decision (committed by you, yesterday at 11:34pm)
We decided to use Postgres over MySQL because the client's DBA only supports Postgres. This is a hard constraint and won't change.

Your teammate's AI session never saw your session. They might be using Cursor while you used Claude Code. But the knowledge transferred — with the original reasoning, the attribution, and the semantic type so the AI knows this is a settled decision, not a suggestion.

That's the core loop: commit structured knowledge from any tool, recall it from any tool, across the whole team.

Step 7: Browse the dashboard

Go to contextcloud.pro and open your workspace. The dashboard gives you visibility into everything your team's AI sessions have committed:

Knowledge Graph: A visual map of your knowledge bases and how chunks relate to each other. Nodes are sized by chunk count, colored by KB type (software, research, business). Click any node to see its contents.

List View: Every chunk in your workspace, filterable by KB, type, author, and date. You can edit, archive, or move chunks between KBs.

History: A timeline of every commit — who committed what, when, from which tool. This is your team's knowledge activity feed.

Documents: Upload files (PDFs, docs, markdown) that get chunked and embedded for recall alongside session-committed knowledge.

The dashboard is for curation, not for daily work. You work in your AI tool. You come to the dashboard when you want to see the big picture, clean up stale knowledge, or browse what your team has been learning.

What to commit vs. what not to

This comes up a lot, so here's the mental model:

Commit to Context Cloud:

Architecture decisions with rationale
Coding conventions the team agreed on
Findings — things you discovered that others should know
Project state — what's done, what's in progress, what's blocked
Domain knowledge — gotchas, edge cases, tribal knowledge about your codebase

Keep in CLAUDE.md:

Static project-level instructions (linting config, folder structure, tech stack)
Personal coding preferences
Tool-specific instructions

Don't commit:

Temporary debugging notes
One-off questions you asked the AI
Code snippets (that's what git is for)
Sensitive credentials (obviously)

The rule of thumb: if your teammate's AI should know this tomorrow, commit it. If it's only useful for the next five minutes, don't.

Advanced: organizing knowledge bases

As your team's knowledge grows, you'll want multiple KBs within a workspace. Some patterns that work:

By service: "Backend API", "Mobile App", "Infrastructure", "Auth Service". Each maps to a part of your codebase. When someone asks about auth, the AI routes to the Auth Service KB.

By concern: "Architecture Decisions", "Conventions", "Sprint Context". Separates durable knowledge from temporal state.

By team scope: Start with a personal KB in your General workspace for things only relevant to you. When something should be shared, create or move it to a team workspace. Context Cloud supports promoting KBs from personal to team scope.

The AI handles routing between KBs automatically based on what you're talking about. You don't need to specify which KB to query — just ask your question and the retrieval system selects the right KBs using a two-layer approach: first the AI selects relevant KBs from the table of contents, then hybrid search (vector + BM25) finds the best chunks within those KBs.

What you should see after a week

If your team is using this daily, after a week you should have:

20-50 committed chunks across your knowledge bases
A visible knowledge graph showing how your project's context is organized
The experience of opening a session and having the AI already know what happened yesterday
At least one moment where a teammate's session recalled something you committed — that's the multiplayer magic moment

The thing that makes people stick is the first time they open a fresh session and don't have to re-explain their project. Once you feel that, going back to stateless sessions feels broken.

Context Cloud is an MCP memory server with shared team workspaces, typed knowledge chunks, role-based access, and cross-tool support for Claude, Cursor, and Codex. Free to use.

Website: contextcloud.pro
npm: @contextcloud/mcp-client
MCP endpoint: https://api.contextcloud.pro/mcp/protocol
GitHub: github.com/abhinavala/cntxtv2

The AI Memory Problem Is a Team Problem (And Nobody's Talking About It)

Abhi A — Fri, 29 May 2026 02:06:22 +0000

The individual AI memory problem is solved.

claude-mem has 1,840 commits and 109 contributors. MemPalace stores every conversation verbatim with semantic search. mem0 gives you cloud-hosted semantic memory with a clean API. Basic Memory keeps things in human-readable markdown. There are now dozens of options — pick any of them and your AI coding sessions will remember what happened last time.

Congratulations. Your AI remembers your context. Your teammate's AI still doesn't.

The real bottleneck

Two engineers on the same project. Both using Claude Code (or Cursor, or Codex — doesn't matter). Each one has their own memory server storing their own context. Each one's AI has a deep understanding of the project — but only from their own perspective, their own sessions, their own decisions.

Engineer A spends an hour debugging the payment service and discovers that the Stripe webhook fires twice on subscription changes. Critical finding. Their AI knows about it now. Engineer B starts working on the payment service the next day. Their AI knows nothing about it. B hits the same bug, spends the same hour, makes the same discovery.

This isn't a hypothetical. An engineering manager running two teams with 14 engineers described this exact scenario on the Claude Code GitHub repo. The issue is titled "Feature Request: Shared Team Memory for Claude Code" and it has one of the clearest articulations of the problem I've seen:

"Claude Code's memory system is individual-only. In real engineering teams, knowledge flows constantly between people — through handoffs, consultations, reviews, and investigations. Today, none of that context transfers at the agent level."

The scenarios that happen every day

Sprint handoffs. Engineer A builds deep context with Claude on a feature, then hits a blocker and pauses. Engineer B picks it up. Today, B either rebuilds the entire context from scratch, asks A for a verbal summary that loses nuance, or reads through A's code commits and tries to piece together the thinking behind them. What should happen: B's AI already knows what A's AI knew.

Architecture decisions made inside AI sessions. An engineer evaluates tradeoffs, rejects alternatives, and chooses an approach through conversation with Claude. That reasoning lives only in their session. Three months later, someone asks "why is it built this way?" and the context is gone. The code exists but the reasoning doesn't.

Onboarding. A new hire joins the team. Their AI starts with a blank slate. The team has months of accumulated context, patterns, decisions, and findings in individual memories — none of it accessible to the new person's AI. Onboarding becomes "re-explaining the entire project to yet another AI session."

Incident response. Engineer A debugs a production issue at 2am, building deep context about the failure mode, what was ruled out, and what the likely cause is. Their shift ends. Engineer B picks up the incident the next morning and starts the investigation from scratch.

Cross-team dependencies. Team A needs to modify a service owned by Team B. Team B's engineers have AI memories full of gotchas, edge cases, and tribal knowledge about that service. Team A walks in blind. The gotchas get discovered the hard way.

Why existing solutions don't solve this

Every solution in the current MCP memory landscape is designed for a single user. This isn't a criticism — individual persistence was the first problem to solve and they solved it well. But the architecture decisions baked into these tools make team features fundamentally difficult to add.

Local storage models don't share. claude-mem uses local SQLite. MemPalace uses local SQLite + ChromaDB. Basic Memory uses local markdown files. Your teammate literally cannot access your memory store without physically accessing your machine.

CLAUDE.md is not memory. It's a config file. It doesn't grow from sessions. It has no attribution, no typing, no search. It works for static instructions ("use camelCase") but not for dynamic knowledge ("we tried Redis for caching and the latency was worse than Postgres for our query patterns").

Cloud doesn't mean shared. mem0 is cloud-hosted, but it's still single-user. Your teammate can't access your memory instance. Zep is cloud-hosted and enterprise-ready, but the team features are behind enterprise pricing.

The gap isn't persistence. The gap is that knowledge flows in teams, and none of these tools let knowledge flow between AI sessions.

What team memory actually requires

I've been building Context Cloud around this problem for months, and the design constraints are specific:

Cloud-hosted by necessity. If memory lives on your machine, your teammate can't access it. There's no getting around this. The storage layer has to be accessible from any machine, any tool, any session.

Typed knowledge. This matters more than you'd think. When your AI recalls a shared decision, it needs to know it's a settled decision with rationale — not a temporary observation that might be stale. Context Cloud structures knowledge into types: decision, finding, convention, state, question, reference. Each type carries different semantics that affect how the AI interprets and presents the recalled context.

Attribution. In a team knowledge store, you need to know who contributed what. "This convention was committed by Sarah last Tuesday" is fundamentally different from anonymous text that appeared in the knowledge store. Attribution enables trust, accountability, and the ability to follow up with the right person.

Scoping. Not everything should be shared with everyone. Some knowledge is project-scoped, some is team-scoped, some is personal. Workspaces with role-based access control handle this — an engineer sees the KBs they have access to, not everything in the organization.

Deduplication and conflict resolution. When two people on a team are both committing knowledge about the same area, you get conflicts. Engineer A commits "auth uses JWT in httpOnly cookies" and Engineer B commits "auth uses session tokens." The system needs to detect this and handle it — not stack contradictory context that confuses every future session.

This isn't documentation

The knee-jerk response to the team memory problem is "just write better documentation." But this is fundamentally different from documentation.

Documentation is written once and goes stale. Team memory grows continuously from actual work sessions.

Documentation requires someone to stop working and write. Team memory is extracted by the AI during normal work.

Documentation is a chore that developers avoid. Team memory is a byproduct of doing the work you were already doing.

Documentation is one-directional (human writes → other humans read). Team memory is bidirectional (human + AI write → other humans' AI sessions read).

The reason AI memory servers exist in the first place is that developers don't reliably maintain documentation. Asking them to maintain shared documentation as the solution to shared memory is circular.

Where this goes

The MCP memory space is going to consolidate around the team problem the same way the individual problem consolidated in 2025. Right now, every memory server is single-player. A year from now, the ones that survive will have team features, because that's where the actual value compounds.

Individual memory is useful but has a ceiling. One person's accumulated context helps one person. Team memory compounds — every engineer's contributions make every other engineer's AI more effective. The knowledge graph gets richer with every sprint, every incident, every decision. New hires onboard faster. Handoffs stop losing context. The team's collective AI brain gets smarter over time.

I'm building Context Cloud because I think this is the most important unsolved problem in AI-assisted development. Not individual persistence — that's done. Collective intelligence. The ability for a team's AI sessions to share a project brain.

Whether you use Context Cloud or something else, this is the problem the industry needs to focus on next.

Context Cloud is an MCP memory server with shared team workspaces, typed knowledge chunks, role-based access, and cross-tool support for Claude, Cursor, and Codex. Free to use.

Website: contextcloud.pro
npm: @contextcloud/mcp-client
MCP endpoint: https://api.contextcloud.pro/mcp/protocol
GitHub: github.com/abhinavala/cntxtv2

CLAUDE.md, Obsidian, Markdown Files, and Why Workarounds Don't Scale for Teams

Abhi A — Fri, 29 May 2026 02:05:39 +0000

Every team using AI coding tools has invented their own version of the same hack.

Some put everything in CLAUDE.md and commit it to the repo. Some maintain shared Obsidian vaults. Some have a context/ folder full of markdown files that someone updates when they remember to. Some paste a summary prompt at the start of every session. Some just re-explain everything every time and accept the tax.

These all work, kind of, for one person. They all break the moment you add a second person or a second tool.

I've used all of these workarounds and eventually built Context Cloud because none of them actually solved the problem. Here's what I learned about each one.

CLAUDE.md: instructions, not memory

CLAUDE.md is the closest thing Claude Code has to a built-in persistence layer. It gets loaded at the start of every session and gives Claude persistent context about your project. Anthropic recently added auto-memory, where Claude writes its own notes based on corrections and preferences.

What it does well:

CLAUDE.md is great for static instructions. "Use TypeScript strict mode." "Run tests with pnpm test." "The API is at localhost:3001." These are things that don't change session to session, and CLAUDE.md handles them perfectly. It lives in your repo, it's version-controlled, and every session reads it automatically.

Where it breaks:

CLAUDE.md is not memory. It's a config file. Here's the difference:

Memory is dynamic. It grows from sessions. "We tried Redis for caching but the latency was worse than Postgres for our query patterns — decision: stick with Postgres query cache." That came out of an hour-long debugging session. It's the kind of insight that should persist and be available to anyone who touches the caching layer. Putting it in CLAUDE.md means manually writing it up, committing it, and hoping your teammate pulls before their next session.

Memory has attribution. When your teammate reads a decision in CLAUDE.md, there's no way to know who put it there, when, or why — unless they wrote a detailed commit message (they didn't). Was this decision made last week or six months ago? Is it still valid? Who do I ask about it?

Memory has structure. In CLAUDE.md, everything is flat text. A critical architecture decision sits next to a linting preference. There's no way for the AI to know "this is a settled decision with specific rationale" versus "this is a temporary note about the current sprint state." It all gets treated the same.

Memory has search. CLAUDE.md is one file. As it grows, it becomes a wall of text that Claude reads in full at the start of every session, eating context window for things that aren't relevant to the current task. There's no semantic search, no way to query "what do we know about the payment service?" and get back just the relevant chunks.

And the real problem: CLAUDE.md doesn't work across tools. It's Claude Code only. If your teammate uses Cursor, they have .cursorrules, which is a completely separate file with separate syntax and separate limitations. If someone uses Codex, they have neither. There's no shared layer.

Obsidian + MCP: the power-user trap

Some teams connect Obsidian to their AI tools via MCP plugins. The idea is solid — Obsidian has great search, graph visualization, and a plugin ecosystem. Use it as the knowledge store, connect it to Claude or Cursor, and you have persistent memory with a nice UI.

What it does well:

Obsidian is a genuinely good personal knowledge tool. The graph view gives you visual structure. The search is fast. Plugins extend it in every direction. If you're already an Obsidian user, adding an MCP connector feels natural.

Where it breaks:

Obsidian is personal by design. Your vault lives on your machine. Making it "shared" means either:

Obsidian Sync — paid service ($4/mo per person), and syncing large vaults with multiple editors creates conflicts. Obsidian isn't built for real-time multi-user editing.
Git sync — fragile. Merge conflicts on markdown files are ugly. Someone always forgets to pull. The sync latency means your teammate's AI might be reading stale context.
Shared network drive — works in theory, breaks in practice. File locking issues, latency, and the assumption that everyone is on the same network.

Beyond the sharing problem, Obsidian has no knowledge typing. A note is a note. There's no semantic difference between a decision and a finding and a convention. No attribution per note. No deduplication. And the MCP plugins are community-maintained with varying quality — they're not designed for the team use case.

The power-user trap is real: you spend hours setting up Obsidian + plugins + sync + folder structure + tagging conventions, and at the end you have a system that works for you but that nobody else on the team wants to maintain.

Markdown files in git repos

The most common workaround I see: a docs/ or context/ folder in the repo with markdown files that describe the project's architecture, decisions, and conventions. Sometimes it's an ADR (Architecture Decision Record) folder. Sometimes it's a single ARCHITECTURE.md file.

What it does well:

It's version-controlled. It's visible to the whole team. It doesn't require any new tools. Every developer already knows how to read and write markdown.

Where it breaks:

The maintenance problem is brutal. Documentation written by humans goes stale the moment it's committed. The decision you documented in docs/decisions/003-database-choice.md three months ago might no longer reflect reality, but nobody updated it because nobody remembers it exists.

There's no search beyond grep. When your AI needs to know about the payment service, it can't semantically query your docs folder — it reads all of it or none of it. And reading all of it burns context window on irrelevant content.

There's no automatic extraction. Every piece of knowledge in those markdown files was manually written by a developer who stopped coding to write documentation. We all know how often that happens. The reason AI memory servers exist is precisely because developers don't maintain documentation reliably.

And there's no attribution, no typing, no deduplication, no temporal awareness. It's text files in a folder. Better than nothing, but not by as much as you'd hope.

.cursorrules and .windsurfrules

Same concept as CLAUDE.md, but for Cursor and Windsurf respectively. Same strengths (persistent project-level instructions, lives in the repo). Same weaknesses (static, unstructured, manual, no search, no attribution).

The additional problem: these are tool-specific. Your .cursorrules don't help your teammate who uses Claude Code. Your CLAUDE.md doesn't help the person on Cursor. If your team uses multiple AI tools — and most teams do — you're maintaining separate config files for each one with no shared layer.

Some teams try to solve this by maintaining all three files and keeping them in sync manually. This is exactly the kind of work that should be automated.

Notion / Confluence / Google Docs

"Just put it in Notion" is the suggestion that sounds reasonable until you try it.

The problem isn't that Notion is bad. It's that Notion is disconnected from your AI sessions. Your Claude Code session can't read your Notion workspace (without a separate MCP integration). Your team's AI doesn't know about the decisions documented in Confluence. The knowledge exists, but it's not in the loop.

Some MCP plugins connect Notion to AI tools, which helps. But Notion wasn't designed as an AI memory store. There's no typed knowledge structure, no session attribution, no deduplication, no semantic search tuned for the kind of short, decision-oriented chunks that AI sessions produce. You're fighting the tool's design instead of working with it.

What a real solution looks like

After trying all of these, here's what I think the solution actually needs:

Automatic extraction. The AI does the work, not you. When you make a decision, the AI extracts it as a typed chunk — you don't stop coding to write documentation.

Typed knowledge. Decisions are different from state which is different from conventions. The system should know the difference so it can treat a settled architecture decision differently from a temporary sprint status update.

Shared across teammates with attribution. Not "commit and push and pull." Just shared. Person A commits, Person B's next session has it. With clear tracking of who committed what and when.

Searchable. Not ctrl+F over a flat file. Semantic search (vector + keyword) that can handle natural language queries like "what do we know about the auth module?"

Cross-tool. Works in Claude Code AND Cursor AND Codex. One shared knowledge layer, accessible from any AI tool.

A dashboard. Someone needs to be able to see the full picture — what's been committed, what's stale, what's contradictory. A knowledge graph, not a folder of text files.

This is what I built Context Cloud to be. It's an MCP memory server with shared team workspaces, typed knowledge chunks (decision, finding, convention, state, question, reference), role-based access, and cross-tool support for Claude, Cursor, and Codex.

The honest take

CLAUDE.md and these workarounds aren't bad. They're fine for solo developers on small projects. If you're one person working on one project in one tool, CLAUDE.md plus maybe Basic Memory or claude-mem will get you 80% of the way there.

The moment you add a second person or a second tool, they collapse. That's not a criticism of these tools — they weren't designed for teams. They were designed for individual persistence, and they do that well.

The team problem is a different problem. It needs shared infrastructure, not shared files. That's the gap I'm building to fill.

Context Cloud is an MCP memory server with shared team workspaces, typed knowledge chunks, role-based access, and cross-tool support for Claude, Cursor, and Codex. Free to use.

Website: contextcloud.pro
npm: @contextcloud/mcp-client
MCP endpoint: https://api.contextcloud.pro/mcp/protocol
GitHub: github.com/abhinavala/cntxtv2

Best MCP Memory Servers for Teams in 2026: Context Cloud vs mem0 vs Basic Memory vs claude-mem vs MemPalace

Abhi A — Fri, 29 May 2026 02:04:58 +0000

There are now dozens of MCP memory servers. I've tried most of them. They almost all solve the same problem: your AI forgets everything between sessions, so you need something to make it remember.

That problem is basically solved. Pick any of the popular options — mem0, Basic Memory, claude-mem, MemPalace — and your Claude Code or Cursor session will remember what happened last time.

But there's a different problem that none of them solve, and it's the one that actually matters if you work on a team: your AI remembers your context, but your teammate's AI doesn't.

Two engineers on the same project. Two separate AI brains. Each one learning the codebase independently. Every architecture decision, every convention, every "we tried X and it didn't work because Y" — trapped in individual sessions that never talk to each other.

I've been building Context Cloud specifically around this problem. This is an honest comparison of where things stand.

What to actually evaluate

Most comparisons focus on setup ease and basic recall. That's table stakes now. The things that actually differentiate memory servers in 2026:

Single-player vs team. Can your teammate's AI session access what yours learned? Does the system track who contributed what? Can you scope access by role?

Knowledge structure. Is it flat text, markdown files, entity graphs, or typed chunks with semantic meaning? When your AI recalls context, does it know the difference between "this is a decision we made" and "this is the current state of things"?

Storage model. Local SQLite on your machine, or cloud-hosted so it works across machines and teammates? Local is simpler. Cloud is necessary for teams.

Tool support. Claude Code only, or does it work across Cursor, Codex, Windsurf? Most teams use more than one AI tool.

Retrieval quality. Keyword matching, vector search, or hybrid? How does it handle stale context?

The comparison

	Context Cloud	mem0	Basic Memory	claude-mem	MemPalace	Knowledge Graph	Zep/Graphiti
Team workspaces	✅ Shared with RBAC, invites, attribution	❌ Single-user	❌ Single-user	❌ Single-user	❌ Single-user	❌ Single-user	❌ Single-user
Knowledge structure	7 typed chunks (decision, finding, convention, state, question, reference, session_summary)	Flat semantic memories	Markdown files	Compressed observations	Verbatim + vector embeddings	Entity-relation graph	Temporal knowledge graph
Storage	Cloud (Supabase + pgvector)	Cloud or self-hosted	Local markdown files	Local SQLite	Local SQLite + ChromaDB	Local JSON file	Cloud or self-hosted
AI tools supported	Claude (web/desktop/Code), Cursor, Codex, Windsurf	Any MCP client	CLI-based	Claude Code, Gemini CLI	Claude Code	Any MCP client	Any MCP client
Dashboard	✅ Web UI with knowledge graph, chunk editing, team activity	✅ Cloud dashboard	❌ Read the markdown files	✅ Local web viewer (localhost:37777)	❌	❌	✅ Cloud dashboard
Retrieval	Hybrid RRF (vector + BM25), auto chunk-type intent detection	Semantic vector search	File-based lookup	Compressed context injection	Vector similarity via ChromaDB	Graph traversal	Temporal-aware graph queries
Attribution	✅ Per-chunk (who, when, which session, which tool)	❌	❌	❌	❌	❌	❌
Auto-capture	Explicit (AI extracts on commit)	Explicit	Manual file editing	✅ Automatic via lifecycle hooks	✅ Stores every conversation	Explicit	Explicit
Dedup / staleness	Session-aware dedup (0.95/0.97) + topic-key supersession + bi-temporal tracking	Basic dedup	None (manual)	Compression handles it	None	Manual	Temporal invalidation
Server-side LLM cost	$0 (extraction on client)	Varies by plan	$0	$0	$0	$0	Varies by plan
Price	Free tier (unlimited teammates)	Free / $25-$475/mo	Free (OSS)	Free (OSS)	Free (OSS)	Free (OSS)	Free / $99+/mo

Deep dive on each

Context Cloud

Full disclosure: I built this. Context Cloud is an MCP memory server with shared team workspaces, typed knowledge chunks, role-based access, and cross-tool support for Claude, Cursor, and Codex.

The core idea is that knowledge has types that matter. A decision ("we're using Postgres because the DBA only supports it") is fundamentally different from state ("auth flow is 70% done") or a convention ("all API routes use camelCase"). When your AI recalls context, it should know the difference, because decisions are durable and state is temporal.

The team layer is what's different from everything else. You create a workspace, invite teammates by email, and everyone's AI sessions read and write to the same knowledge store. Every chunk tracks who committed it, when, and from which tool. Your teammate makes an architecture decision at 2am, your morning session knows about it.

Retrieval uses hybrid RRF — vector similarity plus BM25 keyword search, fused with reciprocal rank fusion. Auto chunk-type detection reads the query shape ("what decisions did we make about auth?") and filters appropriately. Session-aware deduplication prevents the same knowledge from stacking up across commits, and topic-key supersession handles evolving facts (the current state of the deployment replaces the old state, not stack on top of it).

Benchmarks: 99.4% weighted product readiness on our eval suite. 94/100 on a realistic 20-session stress test with evolved facts, stale context, and adversarial phrasing. Detail capture at 95.7–97.1%. Zero ranking failures, zero embedding failures.

Best for: Teams of 2+ using AI coding tools. Multi-tool workflows (Claude + Cursor + Codex). Projects where decisions and conventions need to persist and be shared.

Honest limitation: No ambient auto-capture yet. You have to tell your AI to "save this." The AI handles the extraction and typing, but it's not zero-friction.

mem0

mem0 is probably the most mature cloud-hosted memory option. Good semantic search, clean API, supports multiple LLM providers. The cloud dashboard is solid for browsing stored memories.

Where it falls short for teams: memories are flat — no type system, no structure beyond raw text. No shared workspaces, no RBAC, no attribution. If you're a solo dev who wants semantic recall across sessions, mem0 is a strong choice. The moment you need a second person's sessions to access the same knowledge store, it doesn't have the infrastructure.

Pricing scales with usage — the free tier is limited, and paid plans go up to $475/mo for high-volume use.

Best for: Solo developers who want cloud-hosted semantic memory with a clean API.

Basic Memory

Basic Memory is the simplest option and that's its strength. It stores knowledge as markdown files that you can read, edit, and version control yourself. No database, no cloud, no dependencies beyond the CLI.

The tradeoff is obvious: no search (beyond ctrl+F), no team features, no dashboard, no deduplication. You're maintaining text files. If you're disciplined about it and working solo on a small project, it works. It falls apart at scale or with multiple people.

Best for: Solo developers who want full control, human-readable storage, and zero infrastructure.

claude-mem

claude-mem has the most active community in this space — 1,840 commits, 109 contributors, 259 releases. That's not an accident. The hook-based auto-capture is genuinely good: it hooks into Claude Code's session lifecycle events (SessionStart, PostToolUse, Stop, etc.) and records observations automatically. You don't think about it. It just captures.

A background worker compresses observations using Claude's agent-sdk, stores them in local SQLite, and injects relevant context when a new session starts. The local web viewer at localhost:37777 gives you visibility into what's stored.

The limitation is the same as everything else: local and single-player. Your teammate can't access your SQLite database. No shared workspaces, no attribution, no cross-tool support beyond Claude Code and Gemini CLI.

Best for: Solo Claude Code users who want zero-friction auto-capture with an active community.

MemPalace

MemPalace stores every conversation verbatim, generates vector embeddings for semantic search via ChromaDB, and retrieves relevant context automatically. Three commands to install, everything runs locally, no API keys needed.

The approach of storing everything verbatim means you never lose detail — but it also means no structure, no typing, no distinction between a critical architecture decision and a throwaway debugging comment. Everything gets the same weight.

Local-only, single-player, no dashboard, no team features.

Best for: Solo Claude Code users who want full verbatim storage with semantic search and zero setup.

Knowledge Graph Memory (Official Anthropic)

The official MCP memory server from Anthropic uses an entity-relation graph model. You store entities (people, projects, concepts) and the relationships between them.

The graph model is interesting — it captures structure that flat text doesn't. But it's stored as a local JSON file (not great for scale or reliability), has no team features, no dashboard, no cloud option, and requires you to explicitly define entities and relations rather than extracting them from natural conversation.

Best for: People who want structured entity-relationship memory and are comfortable with the graph model.

Zep / Graphiti

Zep and their Graphiti engine bring something unique: temporal awareness. The system understands not just what was stored but when it was relevant and how it connects to everything else over time. This is genuinely useful for long-running projects where facts evolve.

The tradeoff is enterprise pricing and complexity. Zep is a more serious infrastructure commitment than any of the other options. No self-serve team features — it's designed for organizations that need compliance, audit trails, and managed infrastructure.

Best for: Enterprise teams that need temporal knowledge graphs and are willing to pay for managed infrastructure.

When to use what

This is the honest breakdown:

Solo dev, one project, want simplicity → Basic Memory or MemPalace. Both are free, local, and work out of the box. Basic Memory if you want human-readable markdown files. MemPalace if you want auto-storage with semantic search.

Solo dev, want zero-friction auto-capture → claude-mem. The lifecycle hooks mean you genuinely don't have to think about it. Strongest community of any option here.

Solo dev, want cloud + semantic search → mem0. Most mature cloud option, clean API, good dashboard.

Team of 2+, need shared context → Context Cloud. It's currently the only MCP memory server with shared workspaces, RBAC, attribution, and cross-tool support. This isn't a marketing claim — check the comparison table. Nobody else has team features.

Enterprise, need temporal graphs + compliance → Zep/Graphiti. Different price bracket, different use case.

The team gap

Here's the thing nobody talks about in the memory MCP space: the individual problem is solved. Multiple good options exist. Pick any of them and your sessions will remember what happened last time.

The team problem is wide open. Your teammate's Claude session still starts from zero every time, even if yours remembers everything. Architecture decisions made in your session never reach theirs. Domain expertise stays trapped in individual memory stores. Onboarding means a new engineer's AI knows nothing about months of accumulated team knowledge.

CLAUDE.md helps with static instructions ("use camelCase," "we use Postgres"), but it's not memory — it's a config file. It doesn't grow from sessions, doesn't track who added what, and pollutes git history with non-code changes.

This is the gap I'm building Context Cloud to fill. Whether you use us or not, this is the problem the MCP memory space needs to solve next.

Context Cloud is an MCP memory server with shared team workspaces, typed knowledge chunks, role-based access, and cross-tool support for Claude, Cursor, and Codex. Free to use.

Website: contextcloud.pro
npm: @contextcloud/mcp-client
MCP endpoint: https://api.contextcloud.pro/mcp/protocol
GitHub: github.com/abhinavala/cntxtv2
MCP Registry: io.github.abhinavala/context-cloud

Hack 4 Humanity

Abhi A — Thu, 05 Feb 2026 04:51:17 +0000

Its that time of the year again. We have HUGE sponsors, NUMEROUS tracks, UNLIMITED Redbull, and AWESOME vibes. Join us from Feb 28th - Mar 1st to stay overnight at SCU and compete for **15K+ **in prizes and recruiting!

Visit our website to register and get more info. Spots are limited!!