Kumbuka

What Kumbuka MCP server does

Kumbuka MCP server gives AI assistants access to a curated memory service for team decisions, conventions, constraints, definitions, open questions, and status information. Entries are individually addressable, typed, and assigned to scopes. A scope can be private to the member using it or shared with the team, subject to the caller's permissions.

The service is intended for knowledge that people explicitly record and maintain. It is not a document repository, a source-code watcher, or a RAG index. Documents and source material remain in their existing systems, while Kumbuka holds the selected rules and facts that should guide assistant work.

Tools and capabilities

The Kumbuka MCP server exposes five memory tools:

• memory_remember writes or appends an entry and upserts by key. The caller supplies a scope and type, with an optional key.
• memory_recall reads entries filtered by scope, type, and a substring query. Callers may optionally include global entries.
• memory_forget deletes an entry using its ID or a scope-and-key pair.
• memory_scopes lists the scopes available to the caller, including their private scope and permitted shared scopes.
• memory_load_context returns a typed digest of relevant rules grouped by type, suitable for injecting into an assistant's working context.

These operations support both ongoing curation and session startup. An assistant can load applicable context before work, record a newly settled convention, and retrieve a narrower set of entries when needed.

How it works

The service is reached by assistants through the platform's MCP entry point rather than through a standalone Memory MCP adapter. The platform exposes service tools using names such as memory_<verb> and forwards requests to the owning service. The MCP transport is Streamable HTTP, and requests use an authenticated session.

Kumbuka MCP server enforces the private-memory boundary at the data-access layer. A member's private entries are available only through that member's authenticated MCP session; administrative paths, console screens, and team-facing APIs cannot read them. Tenant separation uses PostgreSQL row-level security, with each service maintaining its own schema and database role.

Authentication is handled through cimd-proxy, an OAuth 2.1 authorization server that federates sign-in to Keycloak. The external flow uses Client ID Metadata Documents, so the MCP client identifies itself with a URL rather than copied client credentials. A token issued for the platform is accepted by the services behind the entry point.

Setup and configuration

Hosted use requires adding Kumbuka as a custom MCP connector. In claude.ai, the documented flow is Settings → Connectors: add the connector and complete the OAuth sign-in. After authentication, the assistant can call the available services, including the user's private memory scope.

There is no self-host package for the services at present. The project repositories document how to build and configure the services with a database and identity provider. Test suites require Docker and use Testcontainers to start PostgreSQL; Dispatch and Worklist also start Keycloak for their tests. Community installations address services directly, while the router and unified interface are enterprise-only.

Limitations and notes

Kumbuka MCP server is marked pre-beta and remains under active development, so breaking changes and rough edges are expected. The supplied material describes the Memory service and its MCP access; Dispatch and Worklist are separate services with their own capabilities. Documents are not publicly available yet.

The platform does not automatically capture assistant activity or turn existing documents into memory. Teams must curate the entries that assistants should rely on. The private-memory guarantee protects access to private rows, but it does not make those entries visible to other team members.