Feature Request: Prefix-based query support in server-memory

[cf770413-dev]

Problem

When using the MCP memory server for cross-session context, a common pattern is to prefix observations with structured tags for classification and retrieval:

[CORRECTION] Library X requires v2+ for async support
[PATTERN] Use flock for concurrent file access
[PREFER] format: tables for comparisons
[DECISION] Chose FastAPI over Flask for the API layer
[2026-03-09] Sprint review: completed auth module

These prefixes enable decay management, recall priority ordering, and filtered retrieval. However, search_nodes only supports free-text substring search — there's no way to query by prefix efficiently.

Current Behaviour

To find all [CORRECTION] observations:

search_nodes({ query: "CORRECTION" })

This returns entities where "CORRECTION" appears anywhere in any observation, entity name, or entity type — producing false positives. There's no way to express "observations starting with [CORRECTION]" or "all observations with a specific prefix across all entities."

The implementation is a case-insensitive substring match across all three fields simultaneously:

const filteredEntities = graph.entities.filter(e =>
  e.name.toLowerCase().includes(query.toLowerCase()) ||
  e.entityType.toLowerCase().includes(query.toLowerCase()) ||
  e.observations.some(o => o.toLowerCase().includes(query.toLowerCase()))
);

Proposed Solution

Add optional prefix-aware query parameters to search_nodes:

{
  "query": "async",
  "observation_prefix": "CORRECTION"
}

This would filter to only observations where the text starts with [CORRECTION], then search within those for "async".

Additional useful operations

• search_nodes({ observation_prefix: "DECISION" }) — all recorded decisions across the graph
• search_nodes({ observation_prefix: "PREFER" }) — all user preferences
• search_nodes({ observation_before: "2025-12-01" }) — stale observation detection (assumes [YYYY-MM-DD] date prefix convention)
• A list_prefixes tool that returns distinct [PREFIX] tags and their counts — useful for graph introspection

Backwards compatibility

All new parameters are optional. Existing search_nodes calls with only query continue to work identically.

Why This Matters

As memory graphs grow beyond ~100 observations, structured querying becomes essential for efficient retrieval. The prefix convention is emerging organically across MCP memory users — tagging observations by type for decay management, quality tracking, and recall prioritisation. Native support would:

• Reduce false positives in search results (currently significant when prefix words appear in unrelated observations)
• Enable efficient filtered retrieval without client-side post-processing
• Support TTL/decay implementations that classify by prefix (see related feature request for TTL support)
• Make the structured prefix pattern more discoverable for new users