MCP mem_save tool silently drops observation body — content column always empty

[AshrafAKRahman]

Bug Summary

The MCP mem_save tool handler returns success (with a valid observation ID) but does not write the observation parameter body to the SQLite content column. Every save via MCP results in an empty content field. The CLI engram save command writes content correctly — the bug is isolated to the MCP JSON-RPC code path.

Version

engram 1.15.11 (Homebrew, macOS arm64)

Previously reproduced on 1.15.8 as well. Upgrading to 1.15.11 did not fix it.

Steps to Reproduce

1. Start an MCP session: engram mcp --tools=agent
2. Send a mem_save tool call with an observation parameter containing text
3. Tool returns success: {"id": 103, "result": "Memory saved: \"Title\" (manual)"}
4. Check SQLite: sqlite3 ~/.engram/engram.db "SELECT id, length(content) FROM observations WHERE id = 103;"
5. Result: 103|0 — content is empty

Expected Behavior

The observation parameter value should be written to the content column in the observations table.

Actual Behavior

• content column is empty (length 0)
• title column IS written correctly
• type, project, scope, sync_id — all written correctly
• Only content is silently dropped

Impact

• Data loss: All observations saved via MCP have empty bodies
• Cloud sync blocked: sync_mutations reference observations with missing content field, causing engram doctor to report sync_mutation_required_fields as blocked
• Search degraded: FTS index has no content to match against, so mem_search can't find observations by body text

In our case, this caused 65+ broken sync mutations and 10 irrecoverably lost observations before we noticed (the tool was returning success, so there was no indication of failure).

CLI vs MCP Comparison

Path	Title written?	Content written?
engram save "text" --project X	Yes	Yes
MCP mem_save tool	Yes	No

Workaround

We built a Claude Code PostToolUse hook that fires after every mem_save call, reads back the observation from SQLite, and if content is empty, auto-repairs by writing the original observation text from the MCP tool_input directly into the database and fixing the corresponding sync_mutation payload.

Environment

• macOS 15 (Darwin 25.3.0, arm64)
• engram 1.15.11 installed via brew install gentleman-programming/tap/engram
• MCP server started as: engram mcp --tools=agent
• Claude Code (Anthropic CLI) as the MCP client

[jlsevillano]

Confirming this on macOS Apple Silicon, Engram v1.15.10. The downstream impact is significant — cloud sync gets blocked with upgrade_blocked_legacy_mutation_manual when the empty-content rows reach the autosync push, requiring manual SQL cleanup to recover.

On my Mac local DB I found 4 observations with empty content across 4 different projects and 3 different observation types, dating from Feb to May, so the issue is not specific to session_summary or to a single client version:

project	type	created_at	title
(empty)	manual	2026-03-26 21:33:19	(empty title)
partner-portal	decision	2026-02-17 12:39:20	Untitled observation
portaldx	session_summary	2026-05-01 12:48:30	Session summary: portaldx
dx_portal	session_summary	2026-05-02 19:49:49	Session summary: dx_portal

Even title is missing in some rows. The acceptance criteria for mem_save seem to allow empty content, empty title, and even empty project to land in the local store, and from there into sync_mutations where the cloud server later rejects them with observation payload content is required for upsert.

This is exactly the failure mode that breaks engram sync --cloud --project <X> until the offending rows are deleted by hand. Confirming the input-side guard proposed in #363 is the right level to fix this — once it lands at mem_save, downstream sync and repair paths don't need to deal with it.

[carlosorojas]

Confirming on v1.15.11. Same root cause also hits sessions: any session queued with directory="" (omitempty hides the key in JSON, local sessions.directory is empty) produces an identical upgrade_blocked_legacy_mutation_manual for
entity=session op=upsert.

Once these mutations exist, engram cloud upgrade repair --apply returns applied:false on BLOCKED class with no --skip/--drop flag — manual SQL against sync_mutations.acked_at is the only recovery (overlap with #299)