Skip to main content
Glama

memory_store

Persist lessons, decisions, and playbooks from conversations via a unified write endpoint. Routes each memory to the correct type automatically, so you don't need to know Engram's taxonomy.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
items_jsonNo
source_toolNo
content_jsonNo
project_folderNo
user_confirmedNo
allow_similar_newNo

Output Schema

TableJSON 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.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does dislose routing behavior, batch semantics ('playbook not supported in batch'), per-kind content formats, and the writeback lifecycle. However, it says nothing about the likely write-gating behaviors implied by the undocumented booleans — user_confirmed (confirmation?) and allow_similar_new (duplicate similarity check?) — nor what happens to existing knowledge on overwrite. For a write tool, these are material behavioral facts.

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

Conciseness4/5

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

The bilingual text doubles length, but each block earns its place: purpose line, lifecycle line, routing guidance, then a well-structured Args section with high-value per-kind format examples. The only real inefficiency is the intentional bilingual duplication; otherwise there is no filler.

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

Completeness3/5

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

Complexity is high — 7 params, single/batch dual modes, and 3 kinds with different content shapes — and the description handles routing, mode selection, and formats well, while the presence of an output schema relieves it of return-value duty. The three unaddressed params and the absence of explicit guidance on when to choose batch vs single mode (only the trigger 'items_json provided' is stated) leave real gaps for correct invocation.

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?

Schema description coverage is 0%, so the description must compensate — and it does richly for 4 of 7 params: kind's allowed values, content_json's per-kind JSON schemas (lesson / decision / playbook examples), items_json's batch trigger and playbook restriction, and source_tool examples. But project_folder, user_confirmed, and allow_similar_new appear in neither the schema nor the description, leaving critical control knobs completely unexplained.

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 with precision: 'Unified knowledge write endpoint — routes to add_lesson / add_decision / add_playbook based on kind.' The routing behavior differentiates it from the specialized add_* siblings and scopes the tool's exact job in the first line.

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?

Explicitly ties invocation to lifecycle: 'writeback — call when the conversation produces knowledge worth persisting.' It also names the alternates and the selection condition: call add_lesson / add_decision / add_playbook directly when the kind is already known, and use this unified entry when the caller wants to avoid Engram's internal taxonomy.

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