Skip to main content
Glama

memory_store

Write lessons, decisions, and playbooks to persistent local memory in one unified call, with automatic routing by knowledge type so callers avoid knowing internal categories.

Instructions

统一知识写入入口 — 根据 kind 自动路由到 add_lesson / add_decision / add_playbook。 Unified knowledge write endpoint — routes to add_lesson / add_decision / add_playbook based on kind.

**Lifecycle: writeback** — 对话中产生值得长期保留的知识时调用。
Lifecycle: writeback — call when the conversation produces knowledge worth persisting.

这是 Provider 兼容的统一写入接口。如果你已经明确知道要写 lesson/decision/playbook,
也可以直接调用对应的专用工具。本工具的优势在于:调用方不需要知道 Engram 内部的分类体系。
This is a provider-compatible unified write interface. You may also call the specialized
tools directly. The advantage here: callers don't need to know Engram's internal taxonomy.

Args:
    kind: 知识类型 — 'lesson' | 'decision' | 'playbook'。批量模式下作为各条目的类型(playbook 不支持批量)。 / Knowledge type; in batch mode, the item type for every item (playbook not supported in batch).
    content_json: 知识内容 JSON 字符串(单条模式必填)。格式因 kind 而异:
        - lesson: {"summary": "...", "detail": "...", "domain": "..."}
        - decision: {"question": "...", "choice": "...", "reasoning": "..."}
        - playbook: {"title": "...", "triggers": "...", "steps_json": "[...]"}
        Content JSON string (required in single mode). Schema varies by kind (see above).
    source_tool: 调用来源工具(可选),如 'claude_code', 'cursor'。 / Source tool (optional).
    items_json: 条目 JSON 数组;给了就走批量写入(一次导入多条 lesson/decision)。 / JSON array of items; when provided, batch-writes multiple lessons/decisions in one call.
    allow_similar_new: 单条 lesson/playbook:内容相似但不相同、确属新条目时设为 true(可选,默认 false);不能绕过完全相同内容的拒绝。 / Single lesson/playbook: set true when similar but not identical content is genuinely new (optional, default false); it cannot bypass the refusal of identical content.

取代提案:内容(或批量中的某一条)带 supersedes=<已有条目 ID> 时,必须同时带 supersedes_expected_version=<该条目当前版本>;缺失 → version_required,不匹配 → version_conflict,整次调用零写入。
Supersede proposals: content (or a batch item) carrying supersedes=<existing id> must also carry supersedes_expected_version=<that entry's current version>; missing -> version_required, mismatch -> version_conflict, and the whole call writes nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>"
    },
    "name": "memory_store"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYes
items_jsonNo
source_toolNo
content_jsonNo
project_folderNo
user_confirmedNo
allow_similar_newNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.19.1
    • addedInput schema / properties / allow_similar_new
      Added value: +{
      +  "default": false,
      +  "title": "Allow Similar New",
      +  "type": "boolean"
      +}
  2. Changed2 schema fields changedv4.13.0
    • addedInput schema / properties / project_folder
      Added value: +{
      +  "default": "",
      +  "title": "Project Folder",
      +  "type": "string"
      +}
    • addedInput schema / properties / user_confirmed
      Added value: +{
      +  "default": false,
      +  "title": "User Confirmed",
      +  "type": "boolean"
      +}
  3. Changed3 schema fields changedv4.1.0
    • addedInput schema / properties / content_json / default
      Added value: +""
    • addedInput schema / properties / items_json
      Added value: +{
      +  "default": "",
      +  "title": "Items Json",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "kind",
      -  "content_json"
      -]New value: +[
      +  "kind"
      +]
  4. Addedv3.29.1

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations it discloses important non-obvious behavior: identical-content refusal, allow_similar_new limits, and the supersede protocol with version_required/version_conflict errors plus all-or-nothing atomicity. Strong disclosure; deductions only because the two undocumented params (project_folder, user_confirmed) leave some behavioral surface unexplained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is front-loaded and well-sectioned, but it is presented twice in Chinese and English, roughly doubling length without adding information. Effective but not tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with annotations and an output schema, so return values and safety profile are covered elsewhere; the description adds the routing contract, payload shapes, and error semantics. The undocumented project_folder/user_confirmed params are the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage the description must carry parameter meaning, and it documents kind, content_json's per-kind payload shapes, source_tool, items_json batch semantics, and allow_similar_new. However, project_folder and user_confirmed receive no explanation anywhere, leaving 2 of 7 params opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Unified knowledge write endpoint') and explicitly names the three specialized targets it routes to (add_lesson / add_decision / add_playbook) based on kind. This lets an agent distinguish it from the sibling add_* tools without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('call when the conversation produces knowledge worth persisting'), names the alternative ('you may also call the specialized tools directly'), and states the selection advantage (callers needn't know Engram's taxonomy). This is a full when/when-else/why rubric.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.