Kumbuka MCP server

kumbuka

Shared, persistent memory for AI assistants working with a team — served over MCP, curated through an admin console, with a private space that stays private.

Status: pre-beta. kumbuka is in active development. The architecture and

data model are settled and the private-memory guarantee is a hard design

constraint, but the project is not yet a hardened, shipped product. Expect

rough edges and breaking changes.

kumbuka is Swahili — the imperative "remember!". The project lives at kumbuka.ai.

The problem: the context tax

AI assistants are stateless between sessions. A team using them pays the same toll over and over — re-explaining the things that should simply be known:

• "We use Postgres as the system of record."
• "Money is integer minor units, never floats."
• "Service names are kebab-case."

That steering knowledge — the decisions, conventions, and constraints that shape how an assistant should work — is exactly what an assistant ought to remember and apply without being told again. Today it lives in people's heads and in scattered chat history, so every new session starts from zero.

What kumbuka is

kumbuka makes that knowledge a first-class, team-owned asset. It gives a team a durable, shared place for the rules an assistant should carry across conversations, and serves them to any MCP-capable assistant (Claude and others) over a remote MCP server. A web admin console lets the team curate the shared memory.

It is deliberately not a document store or a RAG index. kumbuka holds work-steering knowledge — a small, typed set of decisions, conventions, constraints, definitions, open questions, and status — not a copy of your docs or source, which stay in their own systems.

on, instead of each person accumulating an opaque, divergent context.

• Shared and curatable — the team sees and edits what the assistant relies

endpoint.

• Portable — any MCP-capable assistant reads and writes it through one

rather than letting it sprawl.

• Bounded — a fixed taxonomy and explicit scopes keep the memory legible

The private-memory guarantee

A member's private memory is theirs alone. It is reachable only by them,

only over their own authenticated MCP session. **No admin, no console screen,

and no team-facing API can read it.**

This is the backbone of the product, not a feature flag. It is enforced at the data-access layer — the privileged (admin/console) code paths have no route that can return private rows — not by a configuration toggle that could be flipped. Disabling a member suspends their account but leaves their private memory untouched and theirs.

See the Security & privacy guide for how this is structurally enforced.

Quickstart (self-host the Community Edition)

Shortened. The full README is on GitHub.