memory: write side has no size caps, and every mutation rewrites the whole graph file — measured linear cost (hardening note)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
Start with src/memory/index.ts, especially the write schemas at lines 889–903 and the load, save, and locking paths at lines 419, 442, and 532/610. Compare the existing read-side limits from issue #3953 and decide which write limits or README guidance fit this server. Done means the chosen limits or cost documentation address the uncapped growth and whole-file rewrite behavior described here.
由索引模型根据 Issue 内容生成。
描述
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 6cfff622fb8eb41e2504340d5a6105d34094143c):
- 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 (#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.
- 主要语言
- TypeScript
- 星标
- 91.9k
- 派生
- 11.9k
- 平均合并
- 3 小时 10 分钟
- 30 天内合并 PR
- 178
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
modelcontextprotocol/servers 的其他 Issue
-
bug server-sequentialthinking v2
难度 2/5 1-3 小时 新手友好度 72/100
modelcontextprotocol/servers#5526 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
modelcontextprotocol/servers#5521 · 1 条评论 ·
维护者通常 1 天内回复
-
fix(docker): correct stale --db-path comments in fetch/git Dockerfiles and clarify git README可能已有人在做 @cliffhall 今天认领。 未关闭documentation server-fetch server-git v2
难度 1/5 1 小时以内 新手友好度 88/100
modelcontextprotocol/servers#5483 · 4 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
chore v2
难度 3/5 1-2 天 新手友好度 35/100
modelcontextprotocol/servers#5527 ·
维护者通常 1 天内回复
-
everything: README description of `get-env` masking omits the whole-segment rule — `APIKEY` / `MYKEY` are not masked可能已有人在做 @cliffhall 今天认领。 未关闭documentation server-everything v2
modelcontextprotocol/servers#5524 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
查看 modelcontextprotocol/servers 的全部 Issue
相似的 Issue
-
maintenance
难度 2/5 1-3 小时 新手友好度 73/100
assistant-ui/assistant-ui#10499 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
app-server bug CLI
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
better-auth/better-auth#12458 · 1 个 reaction ·
维护者通常 1 天内回复
-
Codex使用可 コード
难度 2/5 1-3 小时 新手友好度 72/100
ryuki-moro/Nicomaru#218 ·
维护者通常 3 天内回复