MemoryGuard

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

Annotations already declare read-only, idempotent, and non-destructive behavior, and the description adds useful context beyond those: the audit targets local V2 reference integrity and is deliberately not a general memory/quality inspection. It does not describe the audit's exact output shape, but the annotation burden is low.

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 short sentences carry the primary use case, the timing, and the key exclusions. There is no filler or 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?

The tool is simple, has one optional parameter, and its safety profile is covered by annotations. The only gap is that no output schema exists and the description does not indicate what the audit returns or how its result is reported.

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 only parameter, workspace, is fully described in the schema with a default value, so the description does not need to repeat it. With 100% schema description coverage, the baseline of 3 applies.

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 names a specific action ('checking local V2 reference integrity') and a clear scope ('local V2') with an explicit timing ('before repair or release'). The exclusions ('Do not use to read a memory record, modify data, or assess general Agent quality') distinguish it from its siblings.

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 gives an explicit when-to-use condition ('before repair or release') and an explicit when-not-to-use list covering reading, modifying, and general quality assessment. This is unambiguous routing guidance even though sibling tool names are not repeated.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds valuable behavioral context: 'Reads only V2 manifest state and registry metadata; requires no memory binding or source access.' This explains what exactly is read and what prerequisites are absent, going beyond the annotations to clarify side-effect-free execution.

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 with no filler. The first sentence front-loads the purpose and scope, the second provides crisp usage directives. Every phrase earns its place, making it easy for an agent to parse quickly.

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 read-only discovery tool with six optional parameters and no output schema, the description is quite complete. It covers purpose, scope, prerequisites, and usage patterns. It doesn't describe the response format, but given the tool's nature (listing capabilities), the agent can infer reasonable output. The absence of an output schema doesn't leave a critical gap.

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 all six parameters are individually documented. The description adds usage semantics that the schema lacks: it specifies pagination strategy (operation/query plus offset) and advises to use include_schema only for a selected page. This helps the agent understand how to combine parameters effectively, adding value beyond the raw 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: discovering registered MCP operations and GUI operations with their headless availability. It specifies the resource (operations) and the action (discover), and distinguishes itself from sibling tools that perform memory operations or audits. The mention of reading V2 manifest state and registry metadata further clarifies scope.

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 explicit usage guidance: 'Use operation/query plus offset pagination; request include_schema=true only for a selected page.' This tells the agent how to navigate results efficiently and when to include schemas. It doesn't explicitly list alternatives, but the nature of the tool (capabilities discovery) is distinct from siblings, so the context is clear enough.

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 are all false and uninformative, so the description carries the behavioral burden. It adds a meaningful non-obvious side effect: 'may mark one pending local CodeGraph receipt consumed.' This exceeds annotation coverage and helps an agent anticipate state change, though 'Uses trusted binding' remains somewhat vague about what that entails.

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 use case, followed by exclusions and side effects. Every clause contributes something: when to use, when not to use, and behavioral caveats. There is no padding or repetition.

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 six parameters and no output schema, the description covers the essential operational context: purpose, usage boundaries, and side effects. The schema covers parameters, so the remaining gap is minor—terms like 'trusted binding' and 'pending local CodeGraph receipt' are not explained, but the overall call guidance is sufficient.

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%, and the input schema already documents each parameter, including defaults, bounds, and enums. The description itself does not elaborate on individual parameters, so it adds no semantic value beyond the schema. Baseline 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 opens with a specific use case and resource: 'starting one new task to build bounded mandatory rules and relevant governed memory context.' It also actively distinguishes itself from siblings by saying 'Do not use for exact record lookup or repeatedly within same task,' so an agent can tell it apart from recall and search tools without opening schemas.

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 gives explicit when-to-use ('Use when starting one new task') and when-not-to-use guidance ('Do not use for exact record lookup or repeatedly within same task'). While it does not name sibling tools, the positive and negative instructions are unambiguous enough to route an agent correctly.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns evidence, impact, and suggested repair, and explicitly states it does not apply repairs, reinforcing the non-destructive nature. This goes beyond the annotations by specifying the output content and what it does not do.

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 sentences, no filler. The primary usage is stated first, followed by clear exclusions. Every word 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 read-only tool with one required parameter, the description covers purpose, usage, exclusions, and return content (evidence, impact, repair). Annotations cover safety. Nothing essential is missing.

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 coverage is 100% and both parameters have descriptions. The tool description adds meaning by clarifying that finding_id comes from a memoryguard_audit and that the tool explains the finding's evidence/impact/repair, which enriches the schema's minimal 'finding id from audit' with usage context.

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: it explains a memoryguard_audit finding by providing evidence, impact, and suggested repair. It explicitly differentiates from generic memory lookup and repair application, making its scope unambiguous relative to the sibling tools.

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 explicitly says when to use it (for audit findings needing explanation) and when not to (not for generic lookup or repair). However, it does not name specific alternative tools, only implies them. It could be improved by pointing to memory_search or memory_read for lookup, but the exclusion guidance is 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?

The description adds useful behavioral constraints beyond the annotations: operations must be explicitly registered, native/GUI names are rejected, and mutating targets require confirmed=true and idempotency_key. This complements the destructiveHint and readOnlyHint flags without contradicting them.

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 sentences carry all essential information with no redundant phrasing. The core constraint is front-loaded, and the mutation safety requirements follow immediately.

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?

The definition is complete enough for a generic invocation tool: it names the discovery source, restricts accepted operation names, and explains the safety contract for mutations. It does not describe return values, but those are operation-dependent and no output schema is provided, so this is a minor gap.

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 coverage is 100%, so the baseline is 3. The description adds modest extra meaning by tying operation to the capabilities catalog and specifying that confirmed must be true for mutating targets, which is slightly more precise than the schema's 'required for a mutating target.'

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 identifies the tool as a generic dispatcher for registered MCP operations discovered via memoryguard_capabilities, using the concrete verb 'Invoke' and specifying the resource type. It also distinguishes itself from sibling tools by stating it never accepts native handler or GUI method names, so an agent can understand its unique role.

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 explicit context about when to invoke: only for operations found through memoryguard_capabilities, and only with the required confirmation/idempotency for mutations. It states a clear when-not ('Never accepts native handler or GUI method names'), though it does not explicitly enumerate the direct sibling tools as alternatives.

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 already declare idempotentHint=true and destructiveHint=false, but the description adds key behavioral context: it is a local soft-delete recorded as status=deleted and affects future recall. This goes beyond the annotations and clarifies the non-destructive nature explicitly, with no contradiction.

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 sentences with no waste; the primary usage is front-loaded, and the clarifying soft-delete note is brief and valuable. It is efficiently structured for quick parsing.

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 3-parameter tool with no output schema, the description covers purpose, usage, and behavioral outcome. It does not explicitly mention the requirement of idempotency_key or prerequisites, but these are captured in the schema. It is largely complete, with only minor gaps like potential audit implications.

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 each parameter is already described (memory_id, idempotency_key, agent_instance_id). The description does not add additional semantic meaning beyond the schema, so baseline 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 uses a specific verb (remove) and resource (one known memory) with scope ('from future recall'), clearly distinguishing it from write/update/read siblings. It also clarifies it is a soft-delete, not irreversible erasure, which is a precise behavioral distinction.

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?

Explicitly states when to use ('Use when owner must remove one known memory from future recall') and when not to ('Do not use for irreversible erasure'), but does not name a specific alternative tool. It gives clear guidance without naming a sibling, so it is slightly below the 5 threshold.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the qualifier 'governed record,' which hints at access control or authorization context, but does not elaborate on what governance entails or potential errors. It adds a small amount of behavioral context beyond annotations, but not enough to warrant a higher score.

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 exactly two sentences, with the primary usage condition front-loaded and the exclusion/alternative stated immediately after. There is zero filler, and every word earns its place. It is a model of conciseness.

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 read-by-ID tool with annotations covering safety and no output schema required, the description is complete. It specifies when to use, when not to use, and the alternative. Nothing an agent needs to correctly invoke this tool is missing.

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% for both parameters (memory_id and agent_instance_id), so the schema already documents their purpose. The description does not add any additional parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate when the schema handles parameter documentation fully.

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 (reading a memory record) and the specific precondition (exact memory_id already known). It also differentiates from the discovery-oriented sibling memoryguard_memory_search by explicitly naming it as the alternative. This makes the tool's purpose unambiguous and distinct from its siblings.

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 explicit when-to-use guidance ('Use when an exact memory_id is already known') and when-not-to-use guidance ('Do not use for discovery'), and directs the agent to the correct alternative (memoryguard_memory_search). This is textbook usage routing with no ambiguity.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond purpose, such as the governance aspect of memories, but does not describe return format, pagination, or other runtime behaviors. Given annotation coverage, a score of 3 is appropriate.

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 sentences, front-loaded with the primary use case and followed by an exclusion with a clear alternative. No redundant phrasing or unnecessary detail; every word serves a 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 search tool with all parameters optional and fully described in the schema, the description adequately covers the core purpose and usage guidance. It does not explain the return format, but this is common for search tools and the schema covers parameter semantics. The absence of an output schema is compensated by the description's clarity on when to use the tool.

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 schema already documents all four parameters (limit, query, status, agent_instance_id) with meaningful descriptions. The tool description does not add any parameter-level insight beyond what the schema provides, meeting the baseline expectation.

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 (finding) and resource (governed memories) with specific criteria (text and lifecycle status). It explicitly differentiates from the sibling memoryguard_memory_read by noting it should not be used when an exact memory_id is known, which prevents confusion between search and direct read 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?

Provides explicit when-to-use (finding memories by text and status) and when-not-to-use (exact memory_id known) conditions, and names the alternative tool to use instead. This leaves no ambiguity for the agent in selecting the correct tool.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds value by enumerating what the status covers (metrics categories), but does not disclose additional behavior such as freshness of counts, failure modes, or return structure. With annotations carrying the safety burden, a 3 is appropriate.

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 sentences, zero filler. The primary use case is front-loaded, followed immediately by a clear exclusion. Every word contributes.

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 read-only status tool with zero required parameters and no output schema, the description conveys the essential return categories (availability, scope, counts) so an agent knows what to expect. Minor gap: no hint about return shape or whether counts are live, but the metric list largely covers the agent's needs.

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%, and the single optional parameter agent_instance_id is already documented as an 'optional identity consistency check.' The description adds no parameter detail, but with full schema coverage the baseline of 3 is correct per the rubric.

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 states a clear purpose: checking shared-memory availability, scope, record counts, lifecycle/kind counts, and evidence-link counts. It differentiates from siblings via 'Do not use to search or read individual memory content,' which maps to memory_read and memory_search, though it doesn't name those alternatives explicitly.

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?

Provides explicit when-to-use context ('Use when checking shared-memory availability...') and an explicit exclusion ('Do not use to search or read individual memory content'). It stops short of a 5 because it doesn't name the sibling tools to use instead, leaving the routing slightly implicit.

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 already signal a write operation (readOnly=false) and non-idempotence, and the description adds ownership and scope constraints beyond those annotations. However, it does not disclose partial-update behavior, return semantics, or identity-check consequences, so behavioral disclosure is only moderate.

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 tight sentences with no filler: the use condition is front-loaded and each clause carries routing or exclusion 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 mutation tool with nine parameters and no output schema, the description supplies the needed selection criteria and exclusions while the schema covers parameter details. It could specify update result/return semantics, but what is needed to choose the tool correctly is present.

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 coverage is 100%, so the baseline is 3 and the schema documents all parameters. The description lightly maps 'recall policy' to injection_policy and emphasizes which fields are correctable, but it does not add substantive meaning 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?

States a specific action: owner correcting body, kind, recall policy, or priority of one known memory. It clearly distinguishes from memory_write by excluding record creation and from memory_status by excluding lifecycle changes.

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?

Provides an explicit when-to-use condition ('Use when owner must correct ... one known memory') and explicit exclusions (not for creating a record, changing lifecycle status, or modifying another owner's memory). This is strong routing guidance.

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 already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds value by disclosing local write behavior and the potential to organize duplicates or conflicts, which goes beyond the annotation flags. No contradiction found.

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 sentences with zero filler. The primary use case is front-loaded, and the exclusion and behavioral notes are placed efficiently. 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?

The description covers purpose, usage boundaries, and key behavioral traits. With a high-coverage schema and no output schema, it provides sufficient context for an agent to call the tool correctly. Minor gaps like success return values are acceptable given the lack of an output schema.

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 coverage is 100%, so all parameters are documented. The description enriches the meaning of the primary parameter 'body' by providing concrete examples of durable content (facts, preferences, decisions, procedures), which goes beyond the schema's generic 'memory content'.

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 ('retain a durable fact, preference, project decision, or procedure') and the resource (durable memory). It also differentiates from siblings by explicitly excluding raw transcripts and temporary task notes, making its scope unambiguous.

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?

Provides explicit triggers ('when user explicitly asks to retain') and exclusions ('do not use for raw transcripts or temporary task notes'). While it doesn't name alternative tools like memory_read or memory_update, the guidance is clear enough for an agent to decide when to invoke this write tool.

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