open-context open-context
September 9, 2026 · 7 min read

Team-Shared MCP Context Store: Tradeoffs and Setup

Yes, a team can share one MCP context store — point every teammate's Claude Code or Claude Desktop at the same database connection string, and every save_context and recall_context call reads and writes the same pool. What you don't get for free is access control: open-context's store has no per-user permissions, so a shared store behaves like a shared wiki, not a permissioned database.

Key takeaways

  • Sharing works by pointing every client's OPENCONTEXT_DB_URL at the same remote backend — no separate "team mode" exists or is needed.
  • Any of open-context's remote BYODB backends can be shared; Postgres is the best-supported, since every search predicate runs in the database.
  • There is no per-user access control: every client with the connection string can read, edit, and delete every context in the store.
  • Bubbles group contexts into project workspaces, but they organize a shared store — they don't restrict who can see or change what's inside it.
  • The MCP protocol's own authorization hardening covers client-to-server authentication, not per-user data isolation inside a shared backend — that's left entirely to the application.

What "sharing" an MCP context store actually means

open-context's context store is a pluggable adapter behind a single connection string, not a service tied to one machine. By default it's a JSON file at ~/.opencontext/contexts.json, private to whoever's machine it lives on. Set OPENCONTEXT_DB_URL to a remote backend instead — Postgres, MySQL, MongoDB, and ten others are supported — and the store becomes reachable from anywhere that connection string can reach. There's no separate multi-tenant mode to turn on: "sharing" a store is just multiple people's MCP clients resolving to the same database.

Setting it up: one connection string, every client

Stand up a shared backend once — a managed Postgres instance (Neon, Supabase, RDS) is the simplest starting point — then give every teammate's MCP config the same URL: 

{
  "mcpServers": {
    "open-context": {
      "command": "node",
      "args": ["/path/to/opencontext/dist/mcp/index.js"],
      "env": {
        "OPENCONTEXT_DB_URL": "postgres://team:[email protected]:5432/opencontext"
      }
    }
  }
}

From that point on, when anyone's Claude says "remember this," the entry lands in the shared table immediately — a teammate on a different machine can recall_context it in their very next conversation. The db migrate CLI command moves an existing local store into the shared one first, so nobody has to start from zero: 

opencontext db migrate --to "postgres://team:[email protected]:5432/opencontext"

Every backend passes the same conformance suite, including a read-your-writes guarantee — a save from one client is visible to the very next read from another, which is what makes real-time sharing work rather than sharing-with-a-delay.

What you actually gain

The upside is straightforward: a fact one teammate's Claude learns — a deployment quirk, a decision from a meeting, a project convention — becomes something every teammate's Claude can recall, without anyone copying and pasting it around. Bubbles make this practical at scale: create one per project, and list_bubbles or get_bubble lets anyone (or Claude, unprompted) pull up everything the team has saved about that project so far, instead of a flat pool of unrelated notes.

What you don't get for free

Before treating a shared store as a team knowledge base, it's worth being precise about what open-context does not provide, because none of it is hidden behind a setting you forgot to enable — it simply isn't there:

When a shared store makes sense — and when it doesn't

A shared store fits a small team that already trusts each other with the same repo, the same infrastructure secrets, and the same Slack channel. If everyone on the team could already see everything a teammate would plausibly save — architecture notes, project decisions, non-sensitive preferences — a shared Postgres-backed context store just removes the friction of repeating it out loud in a meeting.

It's the wrong fit the moment you need real isolation: a consulting team with multiple clients whose context must never mix, a shared store that would end up holding credentials or personal data some teammates shouldn't see, or any setting where you'd want an audit trail of who saved or deleted what. In those cases, run separate stores — one per team, one per client engagement — rather than relying on bubbles or tags to simulate a boundary the store doesn't actually enforce. Nothing stops you from giving each sub-team its own OPENCONTEXT_DB_URL and its own database; that's the real isolation boundary, not anything inside a single shared one.

Point your team at a shared context store in one config change.

Get started with open-context →

FAQ

Can multiple people share one open-context MCP store?

Yes. Point every teammate's OPENCONTEXT_DB_URL at the same remote backend, such as a shared Postgres database, and each person's Claude Code or Claude Desktop reads and writes into that same context pool automatically.

Does open-context support per-user permissions on a shared store?

No. The context store has no built-in access control or user field — any client holding the connection string has full read, write, and delete access to every context in it, so sharing is all-or-nothing.

How do I keep a shared store organized by project?

Use bubbles. MCP tools like create_bubble and list_bubbles group related contexts into project workspaces that any connected client can browse, but bubbles are an organizational layer, not an access boundary.

Which backend should a team use for a shared store?

Any remote backend open-context's BYODB layer supports works, but Postgres is the best-supported option — every search predicate runs inside the database rather than being filtered in memory.

Does the MCP protocol itself handle multi-user data isolation?

No. The Model Context Protocol's 2026-07-28 authorization update hardens client-to-server authentication — issuer validation, credential binding — but it does not define per-user isolation inside whatever backend a server happens to use.