memory MCP server

The memory server is how Vonzio gives agents continuity. Read/write rows in the memories table, scoped to the calling (user, profile). See Memory concept for the model.

Tools

`memory_search`

Search memory by free-text query against name, description, body. Returns up to 10 matches with previews.

// Arguments
{ "query": "favorite coffee", "type": "user", "limit": 5 }

type (optional): filter by user / feedback / project / reference.

`memory_list`

List all memory rows for the current profile. Returns name, description, type, last_accessed_at — but NOT body (use memory_read to fetch).

`memory_read`

Fetch the full body of a single memory row by name or id.

{ "name": "user_profile" }

`memory_write`

Insert a new memory row.

{
  "type": "feedback",
  "name": "no_db_mocking",
  "description": "Integration tests hit a real DB, not mocks.",
  "body": "User said in 2026-03 that mocked tests masked a broken migration in Q4. Always use real DB for integration tests."
}

Both type and name are required. name is unique per (user, profile, type) — duplicate writes upsert.

`memory_update`

Update an existing row by name or id.

{
  "name": "user_profile",
  "body": "Updated bio text…"
}

`memory_delete`

Remove a row.

{ "name": "outdated_memory" }

Memory types (convention)

The platform doesn’t enforce semantics beyond the enum, but a consistent convention helps agents:

Type	Use
`user`	About the human — bio, preferences, identity.
`feedback`	Behavior corrections the user gave the agent.
`project`	Current state of work — what’s in flight, what’s stuck, what was decided.
`reference`	External pointers — repos, dashboards, runbook URLs.

Scope

Per	Behavior
`user_id`	All memory rows belong to a user.
`profile_id`	Default: each profile has its own memory. Set `profile_id=null` on a row for “global” memory shared across all the user’s profiles.

The getDecryptedForProfile accessor (used by orchestrator) filters by (user_id, profile_id OR profile_id IS NULL).

Authentication

Authorization: Bearer mem_<token> — minted by the orchestrator per task. The bearer resolves to { userId, profileId }; the agent can’t forge access to another profile’s memory.

Memory section in the system prompt

At session start, the orchestrator pre-builds a markdown table of all memory rows for the running profile (name, description, type) and prepends it to the agent’s system prompt. The agent decides which to memory_read in full.