Most agent memory is retrieved by similarity, which is fine for "what did we say about X" and useless for "what was total revenue last month". Typed records plus SQL make aggregate questions answerable, and because the files are Parquet on disk the same data opens in DuckDB or pandas without going through this server at all. The dead letter queue deserves a mention on its own: a record that fails schema validation is stored with its reason rather than dropped, so a schema mistake is recoverable instead of invisible.
A memory layer with a schema. Instead of dumping notes into a vector store, you declare a named memory with typed fields, write records into it, and query with DuckDB SQL. The data lands as Parquet files under a local directory, readable by DuckDB, Python or anything else that speaks Parquet — the MCP server is one way in, not the only way.
- Nine tools over the stack — schema definition, writes, SQL, documents and maintenance
- Memory definition and inspection: create a memory as a name plus typed fields, list what exists, read one schema back — `create_memory`, `list_memories`, `describe_memory`
- Buffered writes that auto-flush to Parquet, with an explicit flush when you want the data on disk now — `write_memory`, `flush_memory`
- SQL against the stored data, where the memory name works as the table name and DuckDB resolves it to the underlying Parquet files — `query_memory`
- A document side for the things that do not fit a schema: store a JSON blob and fetch it back by id — `store_document`, `get_document`
- Removal of a memory you no longer want — `delete_memory`
- A dead letter queue rather than silent loss: records rejected by strict or evolving schema modes are written to a `_dlq_` table with the reason, the payload and the rejection time, so you can query what was thrown away and why
- A web dashboard alongside the MCP server, and a REST API covering the same operations for scripts and app ingestion
Docker — the documented setup is a single compose command that brings up the dashboard, the API and the MCP server together. Two credentials go in the compose file and they do different jobs: `API_KEY` is machine auth for MCP clients and scripts, and `DASHBOARD_PASSWORD` is human auth for the web UI, which can be left unset to disable login for local-only use. The client entry runs the MCP process inside the container over stdio. There are no native dependencies — SQLite, DuckDB and Parquet all run in WASM. The API key can be rotated from the dashboard without a restart, and the old one is invalidated immediately. The MCP package is `structured-memory-mcp` (0.1.0).
One command — docker compose up