Stores conversations, events, or documents in long-term memory, automatically extracting facts, deduplicating entries, and resolving conflicts for reliable recall.
把一段对话、事件或文档写入长期记忆；系统会自动抽取事实、去重与处理冲突。
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | 记忆作用域；多租户/多用户隔离。 | |
| messages | Yes | 字符串或 [{role, content}] 消息列表 | |
| metadata | No | ||
| event_time | No | 事件发生时间（ISO8601），省略则为当前时间 |
Changes observed during successful MCP inspections.
v0.4.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does disclose genuinely non-obvious behavior – automatic fact extraction, deduplication, and conflict handling – which is valuable for a write tool, but it omits scope/isolation requirements, idempotency, whether the call is synchronous, and how conflicts are surfaced to the caller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the write action and its automatic side effects front-loaded, and no filler. Nothing in it is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested scope object and no output schema, the description covers what goes in and what the system does with it. The gap is that with no output schema and no annotations, nothing is said about what the caller gets back or how to recover the extracted/conflicting facts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%: scope (with its isolation meaning), messages, and event_time are documented in the schema, but metadata is undocumented in both places. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (写入) and resource (长期记忆), and lists the input types (对话、事件、文档), so an agent immediately knows it is a write/ingest tool. It does not differentiate from the near-sibling agent_remember or memory_consolidate, which are also write-ish operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the accepted content types (conversation, event, document); there is no explicit statement of when to choose memory_add over agent_remember or memory_consolidate, and no prerequisites or exclusions are given. An agent can guess the context but is not routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.