The knowledge-graph layer actually works now. memory_explore returned nothing on any store, no matter how much you had in it, because three separate faults kept the entity graph empty: maintain's batch extraction passed a memory's metadata into the entity extractor while the extractor looks for metadata["tags"] — but tags is a top-level attribute of Memory and metadata is empty on a normally-stored memory, so every tag entity was silently discarded before it ever reached the graph. Since the extractor is pattern-based (@mentions, #hashtags, URLs, file paths, not semantic NER), tags are nearly the only signal on a heavily-tagged store, so the graph stayed empty. Separately, memory_graph action=extract_entities and memory_search's entity filter were both gated on storage.graph, an attribute no storage class actually assigns, so the first errored out on every hash and the second silently never applied. All three now resolve graph storage the way the rest of the module does. On three tagged memories, maintain goes from 4 entities found to 10. (#218, #219)
memory_search's entity filter also no longer returns unfiltered results when it can't apply the filter — it reports the problem and returns empty when the entity has no linked memories. (#219)
Special thanks to timkjr for two more merged fixes this cycle, his fourth and fifth: the memory CLI's launch/stop/restart/info/health commands now verify TLS certificates by default, completing the self-signed-cert opt-in from v11.7.0 (#216), and .env's MCP_HTTPS_ENABLED no longer reaches the CLI at all — it reads the setting from the environment only, the same discipline the certificate opt-in already followed, so a stray .env in whatever directory happens to be current can no longer decide which scheme a security-relevant health probe uses (#224).
And thanks to @ghulands for the precise Milvus report behind #214: the Milvus backend now implements the storage methods the web API was calling unguarded, fixing 501s on /api/tags and friends.
Last, memory_explore and memory_detail get their first user-facing documentation since they shipped — they'd been covered only by an internal handoff note, which is why a user with 11k memories filed #215 asking for a feature that's most of what they already do. New guide: docs/guides/token-efficient-retrieval.md (also wiki page 20-Token-Efficient-Retrieval). It covers bounding a search response (works everywhere, no setup) and the two-phase entity map separately, leading with the entity-graph prerequisite since memory_explore returns count=0 for every query without one, plus two traps worth knowing about MCP_MAINTAIN_SCAN_LIMIT's default scan order. (#215, #217, #220, #222)
Full changelog: https://codeberg.org/doobidoo/mcp-memory-service/src/branch/main/CHANGELOG.md