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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It adds two useful features: unlimited size and semantic search capability, which give some context. However, it does not mention side effects, durability, return values, or permission requirements, leaving gaps for a write operation.

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

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

The description is two sentences, front-loaded with the action, and every word contributes value. It is concise and well-structured, lacking any redundant information.

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

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

For a simple storage tool with 3 parameters and no output schema, the description covers the core purpose and features. However, it lacks explicit usage guidance and any behavioral details like success feedback or side effects, making it minimally adequate but not comprehensive.

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

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

Input schema provides full descriptions for all three parameters, so baseline is 3. The description adds minimal extra meaning by aligning with the enum types (spec, commit, learning), but it does not explain parameter syntax or provide additional semantics beyond the schema.

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

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

The description clearly states the tool's purpose: storing content into Archival Memory. It specifies the types of content (spec, commit, learning records) and highlights distinctive features (no size limit, semantic search), making it easily distinguishable from sibling tools like recall, update, search, and status.

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

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

The description implies usage for archiving content by listing the content types, but it does not explicitly state when to use this tool versus alternatives or when not to use it. There is no mention of sibling tools or any exclusions, so guidance is implicit rather than explicit.

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

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

No annotations are provided, so the description must carry the transparency burden. It uses '讀取' (read) to signal a read-only operation, but does not describe output format, default behavior for the 'all' block, or any potential side effects. It is adequate but minimal.

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

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

Two concise sentences: the first states the function, the second states usage. No redundant words or repetition of the schema. The description is front-loaded with the primary purpose.

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

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

For a tool with one optional parameter and no output schema, the description adequately covers what it does and when to use it. It lacks detail on return format, but that is not critical for such a simple recall operation. The schema covers the 'block' parameter.

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

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

The schema already covers the parameter with a description and enum. The tool description enriches this by mapping the enum values (project, learnings, decisions) to the listed content types, giving semantic meaning beyond the schema's terse label.

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

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

The description clearly states it reads the project's Core Memory to obtain context, learnings, and decisions, and specifies the two use cases (session start and anytime viewing). This verb+resource pair is specific and distinguishes it from siblings like memory_search (which searches) and memory_status (which shows status).

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

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

It provides explicit usage context ('session start to restore context, or anytime to view memory content'), but does not mention when to use alternatives like memory_search instead. No exclusions are given, but the intended use cases are clear.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It says '搜尋' (search), which implies read-only, but does not explicitly state that it makes no changes or disclose other behavioral traits like permission requirements, result limits, or whether it returns full records. The description adds only the context of 'Archival Memory' and a use case, which is insufficient for a safe and informed usage.

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

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

The description is extremely concise, consisting of two short sentences that front-load the main purpose and a use case. Every word adds value, with no unnecessary repetition or filler.

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

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

Given the tool has 4 parameters, no output schema, and no annotations, the description should compensate by explaining what results look like, how the search behaves, and how it differs from sibling memory_recall. The description does none of this, leaving significant ambiguity about the tool's role within the memory tool family.

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

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

Schema description coverage is 100%, so the input schema fully documents all four parameters with descriptions and defaults. The description itself does not add additional parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action (搜尋/search) and the resource (Archival Memory), and specifies the outcome (找出相關的過去記錄/find relevant past records). It distinguishes itself from siblings by focusing on the 'Archival' memory, though it does not explicitly contrast with memory_recall.

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

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

The description provides a clear use case: '遇到類似問題時參考過去的解法' (reference past solutions when encountering similar problems). This gives context for when to use the tool, but it does not mention when not to use it or suggest alternative tools.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It transparently mentions the automatic initialization on first use, which is a side effect, and lists the output fields. However, it omits the behavior of the 'init' parameter (force reinitialization) and its potential consequences, only the schema warns 'use with caution'. This gap leaves some behavioral ambiguity.

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

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

The description is two sentences, front-loaded with the primary purpose, followed by a concise list of displayed items. There is no redundant or extraneous information; every sentence earns its place.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the core aspects: purpose, side effect (auto-initialization), and displayed content. It does not mention the 'init' parameter, but the schema describes it, and the description is otherwise complete. Minor gaps exist around when reinitialization is needed, but overall adequately complete.

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

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

Schema description coverage is 100%, meaning the only parameter 'init' is fully described with '強制重新初始化（謹慎使用）'. The tool description adds no additional meaning about parameters, so a baseline score of 3 is appropriate since the schema already handles parameter semantics.

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

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

The description clearly states the tool's purpose with a specific verb '查看' (view) and resource '記憶系統狀態' (memory system status), and enumerates the displayed items (connection status, Core Memory usage, Archival record count). This distinguishes it from sibling tools like memory_recall, memory_update, memory_archive, and memory_search, which focus on different operations.

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

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

The description provides clear context: it is for viewing memory system status and mentions automatic initialization on first use. It implies when to use the tool, but does not explicitly state when not to use it or mention alternatives (siblings). No exclusions are given, but the context is sufficient for basic usage.

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

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

由於未提供 annotations，描述承擔行為揭露的責任。它新增了 token 限制與 overflow 時改用 archive 的行為提示，這些是 schema 未提供的。但未說明 append 與 content 的實際更新行為（附加或覆寫）、auto_summarize 的具體效果，或更新的權限與後果，行為揭露仍有明顯缺口。

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

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.

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

工具操作相對簡單，搭配 100% 的 schema 參數說明已足夠使用。描述的 token 限制警告補充了重要的操作情境，並引導至 archive。但缺少輸出格式說明，也未描述更新後的驗證方式，因此略有不足。

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

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

Schema 參數描述覆蓋率為 100%，每個參數都有明確說明，描述本身未增加額外的參數語意。僅有 token 限制的警告間接關聯 auto_summarize，但未直接解釋參數用法，因此依基線給 3 分。

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

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

描述明確使用動詞「更新」搭配資源「Core Memory」，並指出記錄專案進度和決策的用途。與 siblings 的讀取、搜尋、狀態、封存操作有清楚區隔，且特別提及 memory_archive 作為 overflow 的替代，進一步強化目的區分。

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

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

描述明確指出當 Core Memory 超過 ~2000 token 限制時建議改用 memory_archive，提供了具體的使用條件與替代工具。但未說明與 memory_recall、memory_search、memory_status 的使用時機，僅依賴工具名稱本身來暗示更新的用途。

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