Power your agent
The publisher's own URL. Not a PlugMCP endpoint.
Host a copy with our keys and logs.
https://mcp.kumbuka.ai/mcpThe Claude button above opens Claude with the name and URL filled in. You still confirm it there.
claude mcp add --transport http ai.kumbuka-kumbuka-server https://mcp.kumbuka.ai/mcpRun in a terminal.
{ "mcpServers": { "ai.kumbuka-kumbuka-server": { "command": "npx", "args": [ "-y", "mcp-remote", "https://mcp.kumbuka.ai/mcp" ] } }}claude_desktop_config.json
Remote URL or a command on your machine? How the two installs differ
Run on PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
LaunchFrom the publisher
Services for teams that work with AI assistants and agents — curated rules, commissioned work, and the inventory of what is to be done, each held as individually addressable objects, each in a service of its own.
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.
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
kumbuka is Swahili — the imperative "remember!". The project lives at kumbuka.ai.
AI assistants are stateless between sessions, and the work they do leaves a result but rarely a record. A team using them pays twice.
It pays the context tax: the same rules are explained again in every new session — "we use Postgres as the system of record", "money is integer minor units, never floats" — because the decisions, conventions and constraints that should shape the work live in people's heads and in scattered chat history.
And it loses the trail of the work itself. Once an assistant or an agent has done something, the questions that matter later are hard to answer: who asked for it, under which rule, what came back, and who accepted it. A session transcript ends with the session; a finished file does not say which request produced it.
kumbuka is a set of services that hold exactly those things — what a team has settled, the work it commissions and gets back, and what it still intends to do — as objects that are addressed one by one, read by assistants over the Model Context Protocol (MCP), and curated by the team.
Each service is built as a product of its own and published in its own repository. Every service has a complete REST interface. Dispatch and Worklist each also carry their own MCP endpoint; Memory has no MCP adapter of its own and is reached by assistants through the platform's MCP entry point (see Architecture).
kumbuka is deliberately not a document store or a RAG index, and it does not watch what people do. It holds curated content that someone wrote down and the team stands behind, not a copy of your docs or source, which stay in their own systems.
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.
Each service keeps its own schema and its own database role in PostgreSQL. Tenants are separated by row-level security on the tenant axis: the policy fails closed, so a request that is not bound to a tenant sees no rows rather than all of them. The runtime role of a service owns nothing and holds only the privileges its migrations enumerate, so it cannot switch the policy off.
Sign-in runs through cimd-proxy,
the OAuth 2.1 authorization server in front of the identity provider. Outward
it speaks Client ID Metadata Documents: an MCP client identifies itself by
a URL it controls, so the endpoint URL is all a client needs — no client id and
no client secret to copy around. Inward it federates the sign-in to
Keycloak, which issues the token.
From outside, the platform is one resource with one audience. One sign-in yields one token, and that token is valid for every service behind the entry point. Each service validates the unchanged token itself; none relies on a predecessor having checked it.
kumbuka is reached by AI clients as a custom MCP connector. In claude.ai you add it under Settings → Connectors, sign in once through the OAuth flow, and your assistant can then call the services' tools on your behalf, including your own private memory scope.
Through the platform's entry point the tools are named <service>_<verb> —
memory_query, dispatch_claim, worklist_create and so on — so one
connector carries the tools of every service.
The diagram shows the hosted deployment as it runs today. Caddy is the edge and validates no token. cimd-proxy is the authorization server, and Keycloak is the identity provider behind it. The platform is the entry point: a router that reads the service named in an address and forwards the call over REST to the service that owns it, together with the management core for scopes, teams and settings. Memory, Dispatch and Worklist each validate the token themselves and keep their own schema in one PostgreSQL instance. The ops console is the operator's own interface, reachable only from an IP allow-list.
flowchart TD
C["AI assistant or agent<br/>(any MCP client)"]
O["Operator browser"]
E["Caddy edge<br/>(validates no token)"]
X["cimd-proxy<br/>OAuth 2.1 authorization server<br/>(Client ID Metadata Documents)"]
K["Keycloak<br/>(identity provider, issues the token)"]
R["platform<br/>router + management core"]
subgraph services["Domain services (each validates the token itself)"]
M["Memory"]
D["Dispatch"]
W["Worklist"]
end
OC["ops console<br/>(operator, IP allow-list)"]
P[("PostgreSQL<br/>one schema and one role per service")]
C -- "1 · sign-in" --> E
E -- "auth host" --> X
X -- "federates sign-in" --> K
C -- "2 · MCP or REST + bearer token" --> E
E -- "/mcp, /api" --> R
R -- "REST, token forwarded unchanged" --> M
R -- "REST, token forwarded unchanged" --> D
R -- "REST, token forwarded unchanged" --> W
O --> E
E -- "ops host" --> OC
R --> P
M --> P
D --> P
W --> P
K --> P
OC --> P
The router and the unified interface exist only in the enterprise edition. In a community installation there is no router, and the services are addressed directly.
There is no self-host package for the services today, and this README does not pretend otherwise. Each service repository documents how to build the service, run its full test suite, and configure it for your own database and identity provider. The suites need Docker; they start their own PostgreSQL (and, for Dispatch and Worklist, their own Keycloak) through Testcontainers.
kumbuka-memory — configuration and buildkumbuka-dispatch — configuration, build and testkumbuka-worklist — configuration, build and testcimd-proxy — quick start and configuration of the authorization serverThe Docker Compose stack in
kumbuka-server starts the
management core with PostgreSQL, Keycloak and Caddy. The memory engine has
left that repository, so the stack no longer serves memory on its own.
The router and the enterprise modules live in private repositories.
The documentation site lives at docs.kumbuka.ai (English and German). It still describes the earlier memory-only stack in places; where it and this README disagree on which services exist, this README is current.
kumbuka is open core, and the line between the editions is a repository line: the repository boundary is the licence boundary.
kumbuka-memory,
kumbuka-dispatch, kumbuka-worklist, together with kumbuka-server and
kumbuka-console) are open source under the GNU Affero General Public License v3.0
(AGPL-3.0), and each service is built as a complete product on
its own.
cimd-proxy is a standalone tool and is published under Apache-2.0.Because kumbuka is typically deployed as a network-accessible service, AGPL §13 applies: if you run a modified version and let users interact with it over a network, you must offer those users the corresponding source of your modified version.
Contributions are welcome. Start with CONTRIBUTING.md for how to contribute and where the per-repo dev setup lives. To report a security issue, see SECURITY.md — please do not open a public issue for vulnerabilities.
© 2026 MCP Directory.
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
{ "mcpServers": { "ai.kumbuka-kumbuka-server": { "url": "https://mcp.kumbuka.ai/mcp", "headers": {} } }}Tools
No tool list yet. Remote servers get one after the first health check.
FAQ
Copy the http config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.
No required environment variable is listed on this record.
Kumbuka is reached over HTTP.
Last checked 2026-11-07. Governed, auditable knowledge your team curates for its AI assistants, self-hostable