Skip to main content
Glama

add_lesson

Records a single explicit lesson, pitfall, or technical finding from a conversation into persistent memory so it can be reused across tools; use it when you already know what to save.

Instructions

记录单条经验教训(你已经知道要记什么)。 / Record one lesson learned when you already know what to save.

**Lifecycle: writeback** — 对话中学到可复用的经验时调用。
Lifecycle: writeback — call when reusable experience is learned during conversation.

用途:用户明确说出一条踩坑经验或技术发现时调用。
Purpose: Call when the user explicitly states a lesson, pitfall, or technical finding.

注意:如果用户给了一段会话摘要让你自动提取,请用 extract_session_insights 而不是本工具。
Note: If the user gives a session summary for automatic extraction, use extract_session_insights instead.

Args:
    summary: 教训的一行摘要。 / One-line lesson summary.
    detail: 详细说明(可选)。 / Detailed explanation (optional).
    domain: 技术领域(可选),可填多个,逗号分隔,如 'python,testing'。 / Technical domain (optional); may contain multiple comma-separated labels such as 'python,testing'.
    source_tool: 记录来源工具,如 'claude_code', 'codex'(可选,建议填写)。 / Source tool, such as 'claude_code' or 'codex' (optional but recommended).
    source_url: 如果教训来自外部内容,填写来源 URL(可选)。 / Source URL when the lesson comes from external content (optional).
    source_agent: 产生/校验此条目的 agent 身份(可选,如 'claude_code',比 source_tool 更细)。 / Agent identity that produced or validated this entry (optional; finer-grained than source_tool).
    run_id: 产生此条目的工作流/会话运行 ID(可选)。 / Workflow/session id that produced this entry (optional).
    last_validated_at: 人/agent 最近确认此条目仍然成立的 ISO-8601 时间(可选)。 / ISO-8601 time this entry was last confirmed to still hold (optional).
    allow_similar_new: 摘要相似但不相同、确属新条目时设为 true:按相关条目写入并互链,而不是作为重复候选进入待审(可选,默认 false)。不能绕过完全相同(规范化后)内容的拒绝;该拒绝会指向已有条目并给出修订方式。 / Set true when a similar but not identical summary is genuinely a NEW fact: it is stored linked as related instead of queued for review as a duplicate candidate (optional, default false). It cannot bypass the refusal of identical content (after normalization); that refusal names the existing entry and how to revise it.
    supersedes: 本条修订的已有 lesson ID(可选)。修订提案总是进入待审,主人批准后旧条目才被取代;被主人钉住的条目只能这样修订。 / ID of the existing lesson this one revises (optional). A revision is always a proposal that waits for the Owner; the old lesson is superseded only on approval. An Owner-pinned lesson can only be revised this way.
    supersedes_expected_version: 填写 supersedes 时必填:旧条目的当前版本号。缺失 → version_required,不匹配 → version_conflict,均零写入。 / Required with supersedes: the old lesson's current version. Missing -> version_required; mismatch -> version_conflict; both write 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": {
      "summary": "<summary>"
    },
    "name": "add_lesson"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNo
domainNo
run_idNo
summaryYes
source_urlNo
supersedesNo
source_toolNo
source_agentNo
project_folderNo
user_confirmedNo
allow_similar_newNo
last_validated_atNo
supersedes_expected_versionNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.26.0
    • addedInput schema / properties / supersedes
      Added value: +{
      +  "default": "",
      +  "title": "Supersedes",
      +  "type": "string"
      +}
    • addedInput schema / properties / supersedes_expected_version
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Supersedes Expected Version"
      +}
  2. Changed1 schema field changedv4.19.1
    • addedInput schema / properties / allow_similar_new
      Added value: +{
      +  "default": false,
      +  "title": "Allow Similar New",
      +  "type": "boolean"
      +}
  3. 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"
      +}
  4. Changed3 schema fields changedv3.48.0
    • addedInput schema / properties / last_validated_at
      Added value: +{
      +  "default": "",
      +  "title": "Last Validated At",
      +  "type": "string"
      +}
    • addedInput schema / properties / run_id
      Added value: +{
      +  "default": "",
      +  "title": "Run Id",
      +  "type": "string"
      +}
    • addedInput schema / properties / source_agent
      Added value: +{
      +  "default": "",
      +  "title": "Source Agent",
      +  "type": "string"
      +}
  5. Addedv3.29.1

TDQS

A4.3/5.0
Behavior5/5

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

Goes far beyond the annotations by disclosing the write pipeline's consequences: similar summaries are linked as related rather than rejected, normalized-identical content is refused with a pointer to the existing entry, supersedes always creates a pending proposal requiring Owner approval, owner-pinned lessons can only be revised via supersedes, and version mismatch produces version_conflict with zero writes. These are exactly the non-obvious mutation semantics an agent must know before calling.

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?

Front-loaded and well sectioned (lifecycle, purpose, note, args), and each individual sentence earns its place. However, every sentence is duplicated verbatim in Chinese and English, roughly doubling the token cost with zero added information for a given reader. The arg list is also long relative to what a caller needs at invocation time.

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 13-parameter mutation tool with an output schema and non-trivial dedup/versioning semantics, and the description covers the routing, dedup policy, revision protocol, and failure modes. Only the two undocumented parameters (project_folder, user_confirmed) leave a gap in what an agent needs to call it correctly.

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 carry the load, and it does: 11 of 13 parameters get meaning, format hints (comma-separated domains, ISO-8601 timestamps, tool names like 'claude_code'), defaults, and even failure modes (version_required, version_conflict). Two parameters are never mentioned — project_folder and user_confirmed — leaving an agent to guess their effect on write behavior.

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

Purpose4/5

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

States a specific verb and resource (record a single lesson learned) and qualifies the input state ('when you already know what to save'), which distinguishes it from the extraction sibling. It also enumerates the trigger kinds (lesson, pitfall, technical finding). It does not distinguish itself from other writing siblings such as add_decision, add_playbook, or memory_store, which share the same 'write a knowledge artifact' space.

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?

Explicit positive condition ('call when the user explicitly states a lesson, pitfall, or technical finding') plus an explicit exclusion naming the alternative tool and the scenario that selects it (session summary → extract_session_insights). That is exactly the when/when-not/alternative routing an agent needs.

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