memory: write side has no size caps, and every mutation rewrites the whole graph file — measured linear cost (hardening note) #5525

Which server?

memory (@modelcontextprotocol/server-memory)

Protocol era

Modern (2026-07-28)

MCP client

No response

The problem

Summary
This is a scalability/hardening observation, not a security report and not a bug claim. In the memory server (src/memory/index.ts, checked at monorepo commit 6cfff62):

• There is no cap on the write side: no length limit on entity/relation/observation strings, and no count limit on the per-call input arrays or on the total graph. The only .max( in the file is the 2048-character cap on the search query string (index.ts:905, 909); the schemas at index.ts:889-903 carry no limits.
• Every mutation loads and validates the entire file and writes the entire graph back (temp file + rename), under the cross-process file lock: load at index.ts:442, save at index.ts:532, 610, locking at index.ts:419.
  The read side already gained opt-in limits (Add lightweight read modes #3953: observationLimit, limit, …), so the write side is the remaining uncapped direction.

Measured cost (real KnowledgeGraphManager, synthetic dummy graph)
Median of 3 runs, single process, one minimal mutation ("add one entity") per measurement; synthetic entities ≈240 bytes/line with 3 observations each:
| Entities | File size | Time to add 1 entity |
| 1,000 | 0.23 MB | 7 ms |
| 5,000 | 1.18 MB | 25 ms |
| 20,000 | 4.78 MB | 93 ms |
| 50,000 | 12.0 MB | 223 ms |
| 100,000 | 24.1 MB | 411 ms |
The cost is linear at ≈4.1 µs/entity, and the write volume is the whole file every time: at 100,000 entities, adding a single ~300-byte entity rewrote 24.06 MB. (Measurement harness and raw numbers are preserved on the reporter's side and can be shared verbatim.)

What this note does not claim
No availability or timeout claim is made. At the measured rate, a single mutation costs well under a second even at 100,000 entities; nothing here demonstrates a client being starved or a write timing out. The point is only the combination of (a) no operator-set ceiling on how large the store can grow through the write tools, and (b) a per-mutation cost and lock-holding time that grow linearly with that unbounded size, in the shared-file multi-client configuration the README supports.

Reporter: Tomoki Murota, CISSP

Solution you have in mind (optional)

Consider parity with the read side: opt-in caps for write payloads and/or total graph size (entities, relations, observation bytes), and/or a short README note documenting the linear per-mutation cost so operators sharing one file can size it deliberately.

Which MCP feature does it demonstrate? (optional)

No response

Alternatives or workarounds you have tried

No response

Already built it locally?

Not built. No diff is attached, per this repository's contribution model. The measurement harness and raw numbers are preserved on the reporter's side and can be shared verbatim.

Before you submit

• I searched existing issues and this is not a duplicate.
• This is a request for this repository or one of its servers, not a new server, the MCP specification or an SDK.