Integrations
Humans, AI assistants and automations reach the same memory through whichever interface fits — all on one rule: only the REST adapter embeds the kernel; the UI, the MCP server and every other consumer speak REST and run on their own server.
REST API
A versioned HTTP API at /api/v1: workspaces, lists, items (including timeline and review-diff), knowledge-commits, relations, artifacts, change-sets and whoami.
Java client
jMemoria-client with its own DTOs — no kernel types leak across the wire. Talk to a jMemoria server from any JVM application.
MCP server
A Model Context Protocol server over stdio and Streamable HTTP, exposing nine tools. Any MCP-capable assistant connects — Claude Code, Gemini CLI, MCP-capable GPT clients and others.
Vaadin web UI
A standalone deployable: workspaces, lists, items, and the review page with its value-level diff — with per-user sign-in.
The nine MCP tools
Enough for an assistant to read a workspace and propose changes — which stay proposals until a human confirms them.
| Read | Write |
|---|---|
jmemoria_list_workspaces | jmemoria_create_item |
jmemoria_list_lists | jmemoria_update_item_attributes |
jmemoria_list_items | jmemoria_add_tag |
jmemoria_get_item | jmemoria_submit_change_set |
jmemoria_get_change_set |
One architecture rule
Only the REST adapter embeds the kernel. The web UI, the MCP server and any further consumer are REST clients and can run on separate servers — enforced by build rules and source-level boundary tests, not by good intentions.