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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action and output format but does not disclose side effects (e.g., whether this is read-only or creates a file), permission requirements, or behavior when the output path is invalid or already exists. For a tool that writes to a user-specified path, this is a significant gap.

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 a single, concise sentence that front-loads the action and scope. It is efficient and easy to parse, though it could add a brief note about the output_path parameter without becoming verbose.

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 has one required parameter, no annotations, and no parameter documentation in the schema. The description provides the core purpose but omits critical context: whether the operation is read-only or writes to disk, what happens if the path is invalid, and whether the output includes metadata or just memory content. An output schema exists, which may describe the return value, but the description still lacks enough detail for safe invocation.

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 0%, so the description must compensate for the undocumented 'output_path' parameter. The description mentions 'user-specified path' but does not clarify whether it should be a file path or directory, whether the file will be created or overwritten, or any format constraints. This leaves the agent to guess the exact semantics of the only parameter.

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 verb 'export' and the resource 'all active and archived memories', and specifies the output format (portable JSON) and destination (user-specified path). It distinguishes itself from sibling tools like import_memory and list_memories, though it doesn't explicitly name them.

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 a use case: exporting all memories for backup or transfer. It doesn't explicitly state when to use this tool versus alternatives like list_memories or import_memory, but the scope ('all active and archived') and format ('portable JSON') provide enough context for an agent to infer appropriate 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?

The description discloses the key behavioral trait: the memory is retained for auditability but excluded from normal recall and startup context. This goes beyond the schema and annotations (which are absent), providing important context about what 'forget' actually means. It doesn't mention reversibility or permissions, but the core behavior is well explained.

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?

One sentence, zero waste, and the most important behavioral distinction is front-loaded. 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 single-parameter tool with no annotations, the description covers the essential behavior. It doesn't explain the return value or whether the operation is reversible, but the output schema exists and the core semantics are clear. The description is complete enough 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.

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. The description doesn't explain the memory_id parameter beyond what the schema shows (a string identifier). However, with only one parameter and a clear name, the meaning is fairly obvious. The description could have added context about where to find the memory_id (e.g., from list_memories), but the baseline is acceptable.

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 verb 'Archive' and the resource 'a memory', and specifies the key behavioral distinction: retained for auditability but excluded from normal recall and startup context. This distinguishes it from sibling tools like recall_memory and list_memories.

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 when to use this tool: when a memory should be archived but not deleted, and when it should be excluded from recall/startup. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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. It discloses that the result is concise and prioritized by critical/high-importance, which is useful, but it does not explain how prioritization works or clarify that the operation is purely read-only.

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 a single well-structured sentence that front-loads the action and the key prioritization behavior. There is no 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?

Although an output schema exists, the description omits guidance on the limit parameter and on when to call this versus sibling retrieval tools. For a tool intended to shape startup behavior, this leaves important selection and invocation gaps.

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, limit, has no schema description (0% coverage) and the tool description does not mention it at all. The agent cannot tell what limit applies to or how it affects the returned 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 uses a specific verb ('Return') and identifies the resource ('startup context') plus its contents (rules, conventions, decisions, recent corrections). It is clear what the tool produces, though it does not explicitly distinguish it from recall_memory or list_memories.

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 phrase 'startup context' implies use at session start, but there is no explicit guidance on when to choose this over recall_memory, list_memories, or list_project_rules, and no exclusions or alternatives are mentioned.

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 of behavioral disclosure. It explicitly states two important behaviors: existing memories are not overwritten, and malformed records are rejected while duplicates are reported. This is valuable beyond the schema. However, it does not disclose the success return format or any permission requirements, so it is not a perfect 5.

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 a single, tightly written sentence that front-loads the core action and resource, then adds behavioral constraints. Every clause earns its place—there is no fluff or redundant wording.

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's low complexity (single parameter, simple operation), the description covers the essential behavioral aspects: non-destructive import and error handling. The presence of an output schema (though not shown) means the description need not explain return values. Minor gaps like the exact format of the JSON export or path requirements are acceptable for this level of complexity, so it is near-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?

The schema has 0% description coverage for the only parameter, input_path. The description does not elaborate on what input_path should contain (e.g., a file system path, a URL, or a raw JSON string). It only implies through the tool name that it is a path to a JSON export, but this is not explicitly stated. The description adds minimal semantic value over the schema's 'Input Path' title.

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 ('Import'), the resource ('JSON export'), and the key qualifier ('without overwriting existing memories'), which distinguishes it from other memory tools like update_memory and forget_memory. It also explicitly names the companion tool export_memory via the phrase 'JSON export', making the purpose 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?

The description provides clear context: this tool is for importing a JSON export, implying it should be used when bringing in externally generated memory data. It does not explicitly name alternatives or conditions for not using it, but the context is sufficient to differentiate from sibling tools, so it meets the 'clear context, no exclusions' criterion.

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 full responsibility for behavioral disclosure. It states the tool lists memories and supports filtering, implying a read-only operation, but it does not mention defaults, pagination, or any side effects. The description adds minimal context beyond what the schema already shows.

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 a single, front-loaded sentence with no wasted words. It states the action upfront and then mentions the optional filters.

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 three parameters with no schema descriptions, no annotations, and several related sibling tools, the description is too sparse to fully contextualize correct usage. It does not distinguish this tool from recall_memory, nor does it clarify what values are acceptable for status or memory_type. The presence of an output schema helps, but the description still leaves important gaps.

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 has 0% parameter descriptions, so the description must compensate. It mentions 'type' and 'status' as filters but does not explain valid values or the meaning of these parameters, and it omits the 'limit' parameter entirely. This leaves agents without necessary semantic context for correct invocation.

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 'List' with a clear resource 'repository memories,' which distinguishes it from sibling tools like update_memory and recall_memory. It also notes optional filters, clarifying the scope of the operation.

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 no guidance on when to use this tool versus alternatives such as recall_memory or list_project_rules. It does not mention any scenarios or exclusions, leaving the agent to infer appropriate usage from the name alone.

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 behavioral burden. 'List' clearly signals a non-mutating read operation, and the description adds useful scope details: only active and durable rules, and only for the current repository.

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 a single, concise sentence that front-loads the core action and resource. Every word contributes meaningful information without 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?

For a zero-parameter, read-only list tool with an output schema present, this description is complete. It specifies what is listed, the scope, and the filtering ('active durable'), leaving no essential calling context 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?

The tool has zero parametersasi ušak, so there are no parameter semantics to document. The schema coverage is 100% because the input schema is an empty object; the description needs to add nothing here.

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 ('List') and a specific resource ('active durable project rules'), and scopes it to the current repository. This clearly distinguishes it from sibling memory tools like list_memories.

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 intended use is implied: call this when you need the active durable project rules for the current repository. However, there is no explicit guidance about when to prefer an alternative or when not to use this 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It does this meaningfully by stating that scoring is 'deterministic', local, and applies across specific memory fields, and that only active memories are searched. It leaves ranking and pagination details implicit, but the core behavior is transparent.

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 a single concise sentence with the primary action front-loaded. Every phrase adds either scope, mechanism, or matching criteria, with no filler 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 simple search tool, the description covers the target, the active-only constraint, and the matching dimensions, and an output schema exists so return values do not need to be restated. The only notable gaps are the lack of explicit alternative guidance and the undeveloped limit parameter, but neither prevents correct invocation.

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 0%, so the description must add parameter meaning. It clarifies that query can match against topic, content, tags, context, and type, which genuinely helps the agent understand the query parameter. However, limit is left entirely to its name and default value, with no stated semantics or cap behavior.

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 ('Search') on a specific resource ('active repository memories') and details the matching dimensions: topic, content, tags, context, and type. It clearly differentiates this tool from list_memories by indicating scored retrieval rather than plain enumeration.

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 conveys that this tool is for finding relevant memories rather than merely listing them, so the intended use is implied. However, it does not explicitly state when to prefer this over list_memories or any alternative, leaving sibling selection to inference.

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 must carry the behavioral burden; it does disclose that stored content is durable rather than transient. However, it does not describe what happens on repeated topics, whether stored corrections are automatically applied later, or what response the caller should expect.

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 filler; the first establishes the action/resource and the second gives usage boundaries. Every phrase contributes to selection and safe use.

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 core purpose and exclusions are present, but the description omits any explanation of the optional parameters, value semantics, or persistence behavior, and no annotations compensate. For a 5-parameter tool with 0% schema coverage, this leaves meaningful gaps.

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 0% and the description only conveys the general semantic of topic/lesson as a correction. Tags, importance, and context_file are left entirely to their bare titles and defaults, so agents cannot infer valid values or intended usage.

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 clear verb ('Store') and resource ('correction or lesson learned') and states the purpose ('durable guidance... prevent repeated mistakes'). It does not explicitly contrast with sibling remember_rule or remember_decision, so it stops short of full differentiation.

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 positive guidance ('Use for durable guidance that should prevent repeated mistakes') and explicit negative boundaries ('do not store credentials, secrets, or transient chat context'). It does not name alternatives such as remember_rule or remember_decision, so the routing guidance is clear but not fully 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?

With no annotations, the description must carry the burden of behavioral disclosure. 'Store' implies a write operation, but the description does not mention side effects such as whether this creates a new memory entry, overwrites existing ones, or how context_file influences storage. It adds minimal behavioral context beyond the obvious mutation.

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 a single, efficient sentence with no wasted words. It is front-loaded with the core purpose. However, it is so brief that it sacrifices useful detail, though that is more a completeness issue than a conciseness problem.

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?

Despite having an output schema, the description does not explain return values, and it fails to cover two of the four parameters. There is no usage guidance, and the behavioral side effects are unstated. For a tool with four parameters and no annotations, this description is insufficient for reliable invocation.

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 0%, so the description must compensate. It mentions 'decision' and 'rationale' indirectly, but it does not explain the purpose or format of 'tags' or 'context_file'. The agent is left without guidance on these parameters, which is a significant gap given the schema provides no descriptions.

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 a specific action ('Store') on a specific resource ('an architectural or implementation decision') and pairs it with its rationale. It distinguishes itself from sibling tools like remember_correction and remember_rule, which handle different memory types, by specifying the decision domain.

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 gives context by limiting to architectural or implementation decisions, which hints at appropriate usage, but it does not explicitly state when to prefer this tool over remember_correction or remember_rule, nor does it mention any exclusions or prerequisites. Guidance is implied but not 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 carries the full burden. It does disclose that the rule is 'durable' (persistent) and 'repository-specific' (scoped), which are meaningful behavioral traits. However, it does not mention side effects such as overwriting behavior, return values, or whether the rule is immediately active. For a write operation without annotations, more behavioral context would be expected.

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 zero wasted words. It front-loads the core action ('Store a durable repository-specific rule or convention') and immediately gives the usage condition. It is concise, clear, and well-structured.

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?

While the description covers the tool's purpose and when to use it, it omits crucial details needed for correct invocation: the meanings of the parameters, the effect of optional fields like tags and importance, and any interaction with the context_file. The output schema exists but does not compensate for missing parameter semantics. Given the tool has 4 parameters and an output schema, the description is inadequate.

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 input schema has zero description coverage for all parameters, and the tool description makes no mention of any parameter. The schema only provides names and types (rule, tags, importance, context_file) with no meaning. The description fails to explain what 'rule', 'tags', 'importance', or 'context_file' represent or how they affect behavior. This is a critical gap.

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 ('store'), a concrete resource ('rule or convention'), and a scope ('repository-specific'). It also differentiates from siblings like list_memories and forget_memory by focusing on creation. The phrase 'durable' adds persistence context. This is a precise, non-tautological description.

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 explicitly tells when to use the tool: 'Use when the agent should follow a project constraint in future sessions.' This is a clear contextual trigger. However, it does not explicitly contrast with similar siblings like remember_correction or remember_decision, nor does it state when not to use it. The guidance is sufficient but lacks explicit exclusions.

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 of behavioral disclosure. It does disclose that the tool mutates an existing record and timestamp and explicitly avoids silent creation, which is important. However, it does not describe error handling for missing IDs, partial updates, or other side effects, leaving 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 concise sentences with the primary action front-loaded. The second sentence adds a valuable behavioral caveat without redundancy. Every word earns its place, making it an efficient and well-structured description.

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 seven parameters with no schema descriptions and no parameter documentation in the description, the definition is incomplete. While the behavioral caveat is useful, the description omits essential details about the meaning and usage of the optional fields, making it inadequate for a tool of this complexity despite the presence 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 description coverage is 0%, meaning the input schema provides no textual descriptions for any of the seven parameters. The tool description does not mention any parameters, leaving agents to infer meaning solely from parameter names like 'tags', 'topic', and 'importance', which is insufficient for correct invocation.

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 specific verb ('Update') and resource ('existing memory') with the condition 'by ID', clearly distinguishing it from create or other operations. It also clarifies it 'never silently creates a replacement', reinforcing that it targets an existing record. This is specific and distinguishes from siblings like forget_memory or list_memories.

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 updating an existing memory, and the note 'never silently creates a replacement' implies you should not use it when you intend to create a new memory. However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions or alternative routing.

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