Skip to main content
Glama
CronusL-1141

AI Team OS

by CronusL-1141
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

memory_add

Store cross-task team preferences and constraints for automatic injection into future agent sessions. Use for rules affecting multiple tasks, not single-task memos.

Instructions

Add a direction-layer memory — the team's shared, cross-task standing preferences.

方向层 = 低频·高价值密度·跨任务长寿命的偏好/纠正/约束/设计意图。每个派出 的 agent 出生即注入方向层，"全中文""完成即汇报"这类偏好无需手抄进派工 prompt。

写入检验（软门槛）：这条能影响多少未来任务？只影响单个任务的 → 去 task_memo_add（情景层），不要写这里。

体量红线是单一轴：存储上限 = 注入预算。方向层按桶计字符配额—— global 1200 字 + 每个 project 1500 字 + user 300 字，一个会话实际继承 3000 字；单条仍 ≤ 400 字。存得下的一定传得到，写不进去的就是真的没位置： 超限时本工具返回该桶全部有效条目（id / kind / 字数 / 全文）+ 用量缺口， 要求当轮先用 memory_invalidate（可用 content_match 子串定位）腾出空间， 再重试本次写入（global/user 桶条目的失效或置换都须经用户过目并带 confirm_shared_scope=true）。

置换 global/user 条目要确认：supersedes 指向 global/user 条目时，旧文本会 从所有项目的会话里消失，与失效同一道闸。未带确认时不写新条、不失效旧条， 返回 requires_confirmation + 旧条全文（target）+ 新文本（replacement）：交用户 过目，确认后带 confirm_shared_scope=true 重试。project 桶的置换不需要确认。 超长内容改写成「触发条件 + 指向权威文件」的指针条目（如 "涉及生产/集群/DB 时遵守只读铁律，详见 ~/.claude/CLAUDE.md"），正文外置。

写入侧安全扫描：方向层条目会进每个派出 agent 的 system prompt，因此不可见 Unicode、提示注入句式（覆盖既有指令 / 套取系统提示 / 伪造对话角色）、凭据 形态一律拒绝入库。

kind 四类（决定注入截断优先级 constraint>design>directive>preference）：

  • constraint（禁令/护栏）：一句话、可机检、终身有效。 如 "所有输出使用中文"、"git 提交绝不自动加 agent 署名"。

  • design（价值排序/设计意图）：缺显式指令时的取舍依据。 如 "技术决策偏向质量/简洁/健壮/长期可维护，不看重开发成本"。

  • directive（方法论/工作方式）：回答"怎么干"。 如 "完成即按问题→根因→解法→验证汇报，不攒批次"。

  • preference（格式偏好）：可选，如 "每句一行便于 diff"。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoconstraint / design / directive / preferencepreference
scopeNoglobal（全局）/ project（当前项目）/ user（用户级）。 写 global 前自问：**这条对任意目录的任意会话都成立吗？** 提及具体 项目/仓库/书稿/某次任务的一律 scope=project——未注册目录会落入本目录 指纹临时桶（"dir:..."），只被本目录的会话继承，绝不广播成全局记忆。global
contentYes记忆内容（单条 ≤ 400 字，且须放得进本桶字符配额；超长改指针条目）
supersedesNo可选，被本条置换失效的旧 memory id（偏好被改 = 新条 supersede 旧条，Zep 失效语义不删除）；指向 global/user 条目时须同时带 confirm_shared_scope=true
source_refsNo可选，溯源 id 列表（回指 memo/report/meeting，蒸馏提升时用）
confirm_shared_scopeNosupersedes 置换 global/user 共享条目时须为 true，表示 用户已过目确认；默认 false，此时共享条目的置换一律拒绝不动

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.15.0
    • addedInput schema / properties / confirm_shared_scope
      Added value: +{
+  "default": false,
+  "description": "supersedes 置换 global/user 共享条目时须为 true，表示\n用户已过目确认；默认 false，此时共享条目的置换一律拒绝不动",
+  "type": "boolean"
+}
    • changedInput schema / properties / supersedes / description
      Previous value: -"可选，被本条置换失效的旧 memory id（偏好被改 = 新条 supersede\n旧条，Zep 失效语义不删除）"New value: +"可选，被本条置换失效的旧 memory id（偏好被改 = 新条 supersede\n旧条，Zep 失效语义不删除）；指向 global/user 条目时须同时带\nconfirm_shared_scope=true"
  2. Changed2 schema fields changedv1.11.2
    • changedInput schema / properties / content / description
      Previous value: -"记忆内容（≤ 400 字；超长请改指针条目）"New value: +"记忆内容（单条 ≤ 400 字，且须放得进本桶字符配额；超长改指针条目）"
    • changedInput schema / properties / scope / description
      Previous value: -"global（全局）/ project（当前项目）/ user（用户级）"New value: +"global（全局）/ project（当前项目）/ user（用户级）。\n写 global 前自问：**这条对任意目录的任意会话都成立吗？** 提及具体\n项目/仓库/书稿/某次任务的一律 scope=project——未注册目录会落入本目录\n指纹临时桶（\"dir:...\"），只被本目录的会话继承，绝不广播成全局记忆。"
  3. First observedv1.9.0

TDQS

A4.8/5.0
Behavior5/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 so: quota model (global 1200/project 1500/user 300 chars, 3000 inherited per session, 400 per entry), the over-quota behavior (write rejected, returns all valid entries plus deficit, requires memory_invalidate first), the confirmation gate for superseding global/user entries (returns requires_confirmation with target+replacement), and an input safety scan for invisible Unicode/prompt-injection/credential patterns. These are non-obvious failure modes an agent could not infer.

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 purpose is front-loaded and every block addresses a real constraint, but the definition is long and partially restates the kind taxonomy that already appears in the schema. It is dense rather than padded, so the length is mostly justified.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, yet the description still covers the key non-happy-path responses (over-quota entry dump, requires_confirmation payload). For a 6-parameter tool with mutation, quota, and confirmation semantics, nothing material to correct invocation is missing.

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 coverage is 100%, so the baseline is 3; the description adds meaning beyond it by explaining that kind drives injection truncation priority (constraint>design>directive>preference) and by tying supersedes/confirm_shared_scope to the confirmation gate and scope quarantine behavior. This exceeds what the schema fields convey.

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+resource ('Add a direction-layer memory') and defines the resource ('shared, cross-task standing preferences') in a way an agent can act on. It also explicitly distinguishes itself from the sibling task_memo_add, which removes route ambiguity.

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 when-not rule tied to a named alternative: content affecting only a single task goes to task_memo_add. It also gives scope-selection guidance ('write global only if true for any directory/session') and the project-vs-global routing rule. This is as close to a decision procedure as a description gets.

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

Deploy Server

Other Tools