Is your feature request related to a problem? Please describe.
The Memory MCP server's read_graph tool returns ALL entities with ALL observations in a single response. Over time, as observations accumulate (weeks/months of usage), this creates critical scalability issues:
- Context Explosion: A single memory_read_graph call can consume 50k-80k+ tokens, overwhelming the model's working context. After 6 weeks of daily usage, my graph has 150 entities with 800+ observations.
- No Progressive Loading: There's no way to fetch entity names first, then selectively load observations. Even simple status checks like "what applications are queued?" require loading the entire graph.
- Observation Bloat: No built-in mechanism exists to split, archive, or reorganize oversized observations into new entities. Users must manually edit memory.jsonl files or lose historical data.
- Forced All-or-Nothing Reads: Current tools (read_graph, open_nodes, search_nodes) all return full observations with no pagination, filtering, or metadata-only modes.
This is a scalability blocker for long-running MCP memory server deployments. Without these features, users must either:
- Manually prune memory.jsonl files (losing historical data)
- Reset graphs frequently (losing context continuity)
- Accept degraded model performance as graphs grow
Describe the solution you'd like
A clear and concise description of what you want to happen.
- Lightweight Read Modes (Enhance Existing Tools)
Add optional parameters to existing tools:
// ENHANCED: read_graph with options
read_graph(options?: {
includeObservations?: boolean, // default: true
observationLimit?: number, // max observations per entity
entityTypes?: string[], // filter by entity types
metadataOnly?: boolean // return only name + entityType + observationCount
})
// ENHANCED: open_nodes with options
open_nodes(names: string[], options?: {
includeObservations?: boolean, // default: true
observationLimit?: number, // paginate observations
observationOffset?: number // for pagination
})
// ENHANCED: search_nodes with options
search_nodes(query: string, options?: {
includeObservations?: boolean, // default: true
limit?: number, // max entities to return
observationLimit?: number // max observations per entity
})
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
The Memory MCP server's read_graph tool returns ALL entities with ALL observations in a single response. Over time, as observations accumulate (weeks/months of usage), this creates critical scalability issues:
This is a scalability blocker for long-running MCP memory server deployments. Without these features, users must either:
Describe the solution you'd like
A clear and concise description of what you want to happen.
Add optional parameters to existing tools:
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.