agent-memory

by ac0033

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation on a distinct aspect of memory (long-term, working, review, context, transcript, session). Even within the same subdomain (e.g., add/update/forget/search for long-term memory), the action is clearly different. No two tools could be confused for the same task.
Naming Consistency4/5
All tools share the 'memory_' prefix and use snake_case, and most use an action verb (add, update, forget, search, read, write, clear, resolve, list, end). However, the verb placement varies (memory_add vs memory_wm_read) and two tools are noun-only (memory_context, memory_feedback), which is a minor inconsistency.
Tool Count5/5
13 tools is well within the ideal range (3-15). Each tool covers a distinct feature of the memory system without redundancy or bloat.
Completeness5/5
The server covers the full lifecycle of long-term memory (add, update, search, forget, feedback) and working memory (read, write, clear), plus review queue handling, context assembly, transcript reading, and session-end orchestration. No obvious gaps for the stated purpose.
Average 4/5 across 13 of 13 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful behavioral detail: the memory layer and index are deleted synchronously, ensuring consistency. However, with no annotations at all, it does not disclose irreversibility, permission requirements, or what happens to related feedback/review data.
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 description is one short sentence, efficient and easy to scan. The parenthetical adds a relevant operational detail without bloating the text, though a bit more context could be added.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is under-specified. It does not mention irreversibility, how to retrieve memory_id, or any side effects on related data, leaving an agent to guess critical usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention memory_id at all. It simply says 'delete a memory' without explaining that the memory_id parameter identifies the target or how to obtain it, leaving the schema to bear all meaning.
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?
The description uses a specific verb '删除' (delete) and a clear resource ('一条记忆' - one memory), and the parenthetical clarifies it removes both the memory layer and its index. This clearly distinguishes it from siblings like memory_search or memory_wm_clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not state that this is for permanent removal of a specific memory, nor does it mention prerequisites such as obtaining a memory_id from memory_search or memory_review_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It reveals the action of adjusting confidence and the conditional manual review queue, adding context beyond the verb. However, it does not disclose whether the operation is a write, if it is reversible, return format, or error handling, leaving notable gaps.
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 description is a single concise sentence, front-loaded with the action. It is efficient and easy to scan, though it lacks structure for parameter details. It earns a high score for conciseness, not for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description should compensate by explaining parameter semantics and usage context. It explains the main behavior but omits parameter meanings and when to use this tool over siblings, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters memory_id, helpful, or note. The description implies 'helpful' relates to usefulness but never explicitly defines each parameter, leaving agents to infer meaning from types and names alone.
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?
The description states a specific action (feedback on memory usefulness), the resource (memory), and the outcome (adjust confidence, possible manual review). This clearly differentiates it from siblings like memory_add, memory_update, and memory_review_resolve, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for providing feedback on memory usefulness, but does not explicitly state when to use it versus alternatives like memory_review_resolve or memory_forget. No when-not-to-use conditions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述提到更新内容会经过脱敏与评价门，揭示了一个重要的处理流程，但未说明失败行为（如门拒绝时返回什么）、权限要求、可逆性或副作用。由于无注解，描述承担全部责任，但此处提供的信息有限，仅部分披露了行为。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
一句话完成，无冗余，动作前置，括号补充关键流程约束。紧凑且信息优先，符合高效结构要求。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
无输出schema，无注解，且为变更操作，但描述未说明返回内容、错误处理、副作用（如修改是否不可逆），也未说明通过门失败时的行为。对于调用者而言，信息不足以做出正确调用决策，完整性不足。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema描述覆盖率为0%，参数名称和类型是唯一信息。描述未对memory_id或new_content增加任何额外语义，如格式、长度限制、示例或注意事项。描述仅重复了'正文'概念，对参数理解帮助有限。
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?
描述明确给出具体动作'更新'和资源'记忆的正文'，并附带脱敏与评价门的处理提示，使工具用途清晰且与其他记忆操作（如添加、删除）区分开来。即使未命名兄弟工具，名称和描述已足够明确。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
未提供任何使用时机或与其他工具的对比。没有说明何时应使用更新而非添加或删除，也没有提及前置条件（如记忆必须存在）。仅凭工具名称和描述推断用途，缺乏明确指导。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and delivers substantial behavioral detail: the fixed assembly order, conditional recall on query, and the review-gate state machine (status=blocked, retry flag, prerequisite cleanup via review tools). The blocked/retry workflow is non-obvious and not inferable from the schema. It stops short of stating whether the operation has side effects or how a successful response is structured.
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?
Two dense sentences with the primary assembly behavior front-loaded before the conditional review-gate flow. Every clause carries information — assembly blocks, ordering, query conditionality, and the blocked-state retry procedure. It is slightly dense with domain terminology but efficient overall with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and no parameter descriptions, so the description must cover both return values and parameter semantics. It explains the blocked status and retry path but never describes the success response shape, and leaves scope (required), k, and current_turn undefined. This is insufficient for an agent to invoke the tool reliably on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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, but it only explains two of five parameters: query (triggers recall) and acknowledge_pending (retry after user confirmation). The required parameter scope is never defined at all, and k (despite its default of 5) and current_turn are also left unexplained. An agent cannot determine valid scope values or what k controls, which is a critical gap for the only required parameter.
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?
The description states a specific verb ('统一组装注入上下文' — uniformly assemble and inject context) and names the exact resources: resident profile block, working memory block, and recall block, with their concatenation order. This composition detail differentiates it from siblings like memory_wm_read or memory_search that handle only individual memory pieces. It doesn't explicitly name a sibling it is not, but the assembly semantics make the tool's role clear.
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?
The description gives explicit conditional guidance: recall is only performed when query is passed ('传 query 才检索历史记忆'). It also specifies a concrete edge-case workflow with named alternatives — when status=blocked, retry with acknowledge_pending=true or first process pending items via memory_review_list / memory_review_resolve. It does not contrast normal-use selection against siblings like memory_search or memory_wm_read, but the blocked-state routing is explicit and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description only states that it lists items and the fields returned; it does not explicitly state that it is read-only or lacks side effects. While the name suggests a list operation, the description does not communicate this behavioral guarantee, leaving the agent to infer safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource, then specifies the returned fields. There is no extraneous information, and it is appropriately concise for a list operation.
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?
The tool is simple, but the description omits how to identify specific items for later resolution (e.g., an ID field) and does not mention any ordering or pagination behavior. Without an output schema, an agent may need more context to use the results with sibling tools like memory_review_resolve, which would require some reference to individual items.
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?
The tool has no parameters, so schema description coverage is trivially 100%. The baseline for 0 parameters is 4, and the description does not need to add parameter meaning because there are none. It provides no extra parameter information, which is appropriate.
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?
The description uses the verb '列出' (list) with a specific resource '人工复核队列的全部待办' and enumerates the returned fields (content, reason, queue file name). This clearly distinguishes it from siblings like memory_review_resolve, which handles resolution, and memory_search, which is general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for viewing the review queue but does not explicitly state when to use it over alternatives, such as when to use memory_review_resolve after listing. There is no mention of prerequisites, exclusions, or the relationship with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that clearing a non-existent scope returns 'already empty' rather than an error, which is a key behavioral nuance. While it does not elaborate on side effects or permissions, this is sufficient for a simple clear operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and efficiently includes the critical edge case. There is no redundancy or unnecessary detail.
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?
For a simple tool with one parameter and a clear action, the description covers the primary behavior and a notable edge case. It is slightly lacking in defining 'scope' and specifying the success return value, but these are minor given the tool's minimal complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain what 'scope' refers to or what valid values it accepts. The agent is left without guidance on this essential parameter, and the description fails to compensate for the missing schema documentation.
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?
The description uses a clear verb '清空' (clear) and a specific resource 'scope 的工作记忆' (working memory of a scope), explicitly distinguishing this from sibling tools like memory_wm_read and memory_wm_write. The edge case about returning 'already empty' further clarifies its purpose.
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?
The description provides clear context that this tool operates on a scope's working memory, which makes its usage obvious given the sibling set. It does not explicitly name alternatives or exclusions, but the action is unambiguous and no conflicting tools exist in the visible sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description becomes the sole source of behavioral disclosure. It discloses scope normalization, immediate errors on illegal scope (rather than silent empty results), and the review-gate blocking behavior with status=blocked and the resolution path. This is substantial, though it doesn't cover aspects like authentication or rate limits.
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 description is structured with a clear first sentence stating purpose and output, followed by two sentences explaining error handling and the review-gate flow. It's detailed but not verbose, and every sentence carries relevant operational information.
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?
Since there is no output schema, the description must convey return structure, and it does: it mentions the XML block and structured hit list, plus the status=blocked variant. It also covers edge cases (illegal scope, review backlog) and provides the retry/alternative paths. For a search tool of this complexity, this is adequate.
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. It explains the behavior of 'scope' (normalization) and 'acknowledge_pending' (used in retry after confirmation), which are the non-obvious parameters. 'query' and 'k' are self-explanatory from their names and defaults, so the description adds sufficient meaning.
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?
The description states a specific verb ('检索' = retrieve), a resource ('历史记忆' = historical memory), and what it returns (XML block and structured hit list). This clearly distinguishes it from sibling tools like memory_review_list or memory_add, which serve different purposes.
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?
The description gives explicit guidance on handling the blocked status: after user confirmation, retry with acknowledge_pending=true, or use memory_review_list / memory_review_resolve to process pending items. This tells the agent when to use alternatives, though it doesn't explicitly say 'use this tool when you need to search' vs. other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses detailed behavior: append-only archiving, conflict updates during distillation, veto with status=vetoed and force override, archived_only fallback, and adapter auto-detection. This goes well beyond minimal expectations.
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 description is a single dense paragraph that covers all key points without fluff. It is front-loaded with the main orchestration, then veto, then material options. However, it could be improved with bullet points for readability, but it still earns its place.
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?
Given the complexity (7 params, no output schema, no annotations), the description is quite complete. It explains the core flow, edge cases, and material options. The main shortfalls are undocumented parameters and lack of return-value details, but these are partially offset by the thorough behavioral coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. It explains conversation_json, log_path, adapter, and force thoroughly, but omits scope, source, and session_id entirely. These are not self-evident from the schema, leaving gaps for the agent.
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?
The description clearly states the tool's purpose: orchestrating session-end wrap-up with archiving, distillation, and cleanup. It distinguishes itself from siblings (e.g., memory_transcript_read, memory_add) by focusing on the end-of-session flow, making its role unambiguous.
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?
It provides strong context on when to use the tool (at session end) and explains veto/force behavior for incomplete tasks, plus fallback to archived_only without LLM. However, it does not explicitly contrast with sibling tools like memory_wm_write or memory_add, and the 'agent 中立推荐' note is more about parameter selection than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses the tool is read-only ('纯读不写'), describes the output structure (turn sequences with numbering and timestamps), explains the adapter fallback behavior (auto-detect or explicit, with error message listing available adapters), and notes that missing logs will cause an error. This is thorough behavioral disclosure.
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 description is structured into a logical flow: main purpose, usage pattern with since_turn, then adapter behavior and error conditions. It is four sentences but dense with information, front-loaded with the core function and then branching into usage details. It is not overly verbose for the complexity it covers.
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?
Given the tool's complexity (read logs, parse turns, support filtering, adapter handling) and the absence of annotations, the description covers essential aspects: parameters, usage integration with wm_read/wm_write, error handling (missing log, adapter detection), and output format ('轮次序列（user/assistant/tool，含轮次编号与时间戳）'). No critical gaps for an agent 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 explain all three parameters. It does: log_path is implied ('读取 agent 会话日志'), adapter behavior is explained ('adapter 缺省按日志文件名自动识别，识别不了需显式指定'), and since_turn is clearly defined ('传 since_turn=... 只返回水位之后的新轮次'). Meaning is fully compensated beyond the bare schema.
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?
The description states a specific verb ('读取' = read), a specific resource ('agent 会话日志' = agent session logs), and the output transformation ('解析成干净的轮次序列' = parse into clean turn sequences). It also explicitly distinguishes itself from siblings by emphasizing '纯读不写' (pure read, no write) and unique functionality (transcript reading) not covered by other tools like memory_wm_read or memory_search.
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?
The description provides clear context for use: it explains the integration with memory watermark ('配合工作记忆水位做新鲜度补偿') and explicitly references sibling tools memory_wm_read and memory_wm_write, showing how since_turn should be used. It also covers adapter auto-detection behavior and error conditions. It lacks an explicit 'when not to use' clause but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It reveals the distillation pipeline for conversations, desensitization/reconciliation for single content, server-side auto-serialization for arrays, error behavior for invalid types, and default scope fallback. This is strong behavioral context beyond a simple 'write' action, though it stops short of describing return values or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, logically organized paragraph with no filler. It front-loads the core action, then covers format, scope, and default behavior in sequence. Every sentence contributes essential information, making it highly efficient.
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?
Given no output schema and no annotations, the description covers purpose, key parameter semantics, and processing behavior well. The remaining gaps—such as the exact meaning of optional parameters like entry_id or session_id—are minor because those parameters are either inferable or have defaults. The description is close to complete for an agent to successfully call the tool.
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?
The input schema has zero parameter descriptions, so the description must compensate. It explains the two most complex parameters: conversation_json (JSON string or array, auto-serialization) and scope (global/repo/agent conventions), and mentions content processing. Other parameters like memory_type, confidence, and source remain undocumented, but their names and defaults make them less ambiguous. The description covers the parameters that truly need clarification.
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?
The description clearly states the tool writes memory, using the specific verb '写入记忆' (write memory), and distinguishes it from sibling tools like memory_update and memory_forget by nature. It also explains the processing pipeline for conversation vs single content, which adds further specificity beyond a generic 'write' operation.
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?
The description provides concrete guidance on how to invoke the tool: recommended conversation_json format, explicit scope value conventions (global, repo:<name>, agent:<name>), and default fallback behavior. It does not explicitly state when to use this tool instead of alternative memory tools, but the detailed usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It accurately conveys the side effects of each action: approve persists, modify replaces content before persisting, and discard drops the item. It also explains the provenance of queue_file. However, it does not disclose whether the queue item is consumed after resolution or whether new_content is mandatory for the modify action, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that lists the actions and their meanings, followed by a short clarification of where queue_file originates. Every clause adds necessary information without redundancy.
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?
The description covers the core workflow, parameter sourcing, and action semantics, which is sufficient for an agent to invoke the tool correctly. It omits return values, explicit requirement of new_content for modify, and post-resolution queue state, but these are secondary for a narrowly scoped resolution tool. Given the lack of an output schema, this is reasonably complete.
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 description coverage is 0%, so the description must compensate. It fully documents all three parameters: action enumerates the valid values (approve/modify/discard), queue_file is tied to the output of memory_review_list, and new_content is defined as the replacement body for modify. This resolves the ambiguity left by the bare schema.
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?
The description states a specific verb (裁决/adjudicate) and resource (复核待办/review todo), then enumerates the permissible actions (approve, modify, discard), making the tool's purpose unmistakable. It also distinguishes itself from the sibling memory_review_list by focusing on the resolution step rather than the listing step.
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?
The description explicitly tells the agent that queue_file comes from the return of memory_review_list, effectively positioning this as the follow-up to that tool. It names the source of a key parameter and implies a list-then-resolve workflow, though it does not formalize when-not-to-use or list alternative tools for this specific action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses automatic scope normalization, immediate errors on invalid scope, the stale_wm flag when current_turn is provided, and the return format (rendered injection block + structured fields). It also hints at the refresh path via wm_write. This is comprehensive for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and then adding the advanced staleness detail. Every sentence adds value, no fluff. It is well-structured and easily parsed by an agent.
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?
For a read tool with only 2 parameters and no output schema, the description covers the return format, error handling, normalization behavior, and the staleness mechanism. An agent has enough context to invoke it correctly and interpret results without additional information.
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. It explains both parameters: 'scope' is the working memory scope to read and is normalized automatically; 'current_turn' is used to trigger staleness detection and returns stale_wm. This adds meaningful semantics beyond the schema's bare names and types, though it doesn't detail value formats or ranges.
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?
The description starts with a specific verb '读取' (read) and a clear resource: 'scope 的工作记忆' (working memory of a scope), and enumerates its contents (goals/todos/decisions/variables/notes). It clearly differentiates from siblings like memory_wm_write (write) and memory_wm_clear (clear) by specifying the read operation. This is a precise, unambiguous purpose.
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?
The description gives clear context: use this tool to read a scope's working memory for current task state. It also mentions when to consider using a sibling (wm_write refresh if stale_wm indicates lag), which implies the alternative when the data is stale. However, it does not explicitly contrast with other read/search tools like memory_search or state when NOT to use it, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses the full-replacement semantics (destructive but essential), text desensitization, the pass-through of todo items as imperative sentences (bypassing evaluation gate), and the turn_watermark retention behavior. These are the key behavioral traits an agent needs to 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. The most critical warning (full replacement) is front-loaded, and every sentence adds necessary context—no filler. It efficiently covers the trickiest aspects of the tool.
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?
For a 7-parameter write tool with no annotations and no output schema, this description provides the essential operational knowledge: the destructive replacement behavior, the two tricky parameters (todos and turn_watermark), and the text-processing nuance. It is complete enough for an agent to call it correctly, covering the high-risk elements thoroughly.
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 for parameter meaning. It thoroughly explains the todos parameter (two accepted formats with status semantics) and turn_watermark (current dialogue turn, default retention). It also implies that all text fields undergo desensitization. It does not delve into goal, notes, decisions, or variables, but the general replacement rule covers them, so it adds significant meaning beyond the raw schema.
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?
The description clearly states the action ('写' write) on the '工作记忆' (working memory, current task state), which is a specific resource. This distinguishes it from sibling memory tools like memory_add or memory_update, which likely target long-term memory. The scope is unambiguous.
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?
The description gives clear context (writing current task state) and explicit critical usage instructions (full replacement, not merge; fields not passed are nulled). However, it does not explicitly contrast with alternative memory tools (e.g., when to use this vs memory_update or memory_add), so it lacks exclusions. Still, the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agent-memory MCP server](https://glama.ai/mcp/servers/ac0033/agent-memory/badges/card.svg)](https://glama.ai/mcp/servers/ac0033/agent-memory)

Score Badge

Copy to your README.md:

[![agent-memory MCP server](https://glama.ai/mcp/servers/ac0033/agent-memory/badges/score.svg)](https://glama.ai/mcp/servers/ac0033/agent-memory)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ac0033/agent-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server