Skip to main content
Glama
Sign In
agent-memory-router

agent-memory-router

by lss486558354-ship-it
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

save_memory

Writes a new long-term memory record with type, title, content, keywords, and optional relations so agents can preserve decisions, code changes, issues, and notes for later retrieval.

Instructions

把一条新的记忆写入长期库。

什么时候必须调用（Rule 里也有同样的约束）：

  • 做了一个影响后续架构/方案的决策

  • 完成了一次代码修改，且改动原因从代码本身看不出来

  • 排查清楚了一个非显而易见的缺陷

  • 得到了一个以后会反复用到的结论

Args: type: 记录类型。decision / code_change / issue / note / reference。 title: 一行摘要，要能脱离原文独立读懂（例：「改用独立浏览器上下文修复跨站污染」）。 content: 完整原文。建议包含：背景、做了什么、为什么这样做、还有什么没做。 keywords: 逗号分隔的关键词，用于以后检索（例：playwright,context,假阴性）。 relates_to: 可选，关联到已有记录，格式 ID:关系类型（例：D_0002:supersedes）。

Returns: JSON：{ok, id, ...}。拿到的 id 可以用于后续 relations。

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": {
      "type": "<type>",
      "title": "<title>",
      "content": "<content>"
    },
    "name": "save_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeYes
titleYes
contentYes
keywordsNo
relates_toNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/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; it does convey that writes are persistent ('长期库') and that an id is returned for later relations. It says nothing about deduplication, overwrite behavior, or whether repeated calls create duplicate records, which matters for a write tool.

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?

Front-loaded with the purpose then a bolded trigger list, followed by structured Args/Returns sections. Efficient overall, though the parenthetical about rules elsewhere and the verbose content prescription add mild bulk.

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?

Covers purpose, mandatory triggers, and every parameter including formats and examples, which is strong for a 5-parameter write tool with no annotations. The remaining gap is behavioral: nothing about duplicate prevention or relation semantics, and the Returns section is partly redundant given an output schema exists.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate, and it does: it names the five allowed type values, specifies title as a self-contained one-line summary with an example, prescribes content structure, explains comma-separated keywords, and gives the `ID:relation` syntax for relates_to.

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 in one line: write a new memory into the long-term store. This clearly separates it from search_memory and link_memory by action, though those siblings are never named explicitly.

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

Usage Guidelines4/5

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

Provides an explicit, enumerated list of four situations that mandate a call (architectural decision, non-obvious code change, non-trivial bug diagnosis, reusable conclusion), which is far above the typical bar. It lacks any 'when not to call' exclusion or a pointer to the alternatives (search_memory / link_memory).

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