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

With no annotations, the description carries the full burden. It usefully discloses automatic cadence and the cost/latency of all_notes=True (one Jev call per note). It does not say what consolidation actually does to stored notes, whether it merges/rewrites/drops anything, or whether it is reversible.

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 dense sentences, front-loaded with the action, followed by cadence and parameter guidance. Slightly jargon-heavy ('Jev call', 'jevmem') but nothing wasted.

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?

Covers trigger, cadence, cost, and the single parameter, which is enough to invoke it. However, with no annotations and no output schema, the description omits the effect of consolidation on stored memory and any indication of what the pass returns, leaving a mutation-adjacent tool under-described.

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, and it does: it explains that all_notes=True re-judges every stored note from scratch, that it is slow, and when to use it. Only the default (false) behavior is left implicit.

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 verb+resource: 'Run a consolidation pass now.' The parenthetical about automatic runs clarifies scope. It does not differentiate itself from siblings like memory_flush_pending or memory_pending_synthesis, which an agent might reasonably confuse with 'consolidation'.

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?

Gives a clear condition for the non-default path ('use it once after upgrading jevmem') and the cadence context (auto-runs every 20 writes) implies manual invocation is optional/on-demand. No explicit when-not-to-use and no named alternatives among the many memory_* siblings.

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 full behavioral burden, yet it says nothing about whether rejection is permanent, whether it discards the proposal or merely defers it, what permissions are needed, or what happens to the underlying memory. Only the bare mutation intent is communicated.

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?

A single front-loaded sentence with no filler, which is structurally clean. However, at one short clause it is arguably undersized for a destructive state-changing tool, so the brevity is as much under-specification as 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 mutation tool with one undocumented parameter, no annotations, and no output schema, the description is too thin: an agent cannot determine side effects, reversibility, or where the synthesis_id comes from. The missing pieces are exactly the ones the description would have to supply.

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 sole parameter, synthesis_id, is undocumented in both schema and description. The phrase 'merge/promote proposal' loosely implies the id targets a proposal, but the description never explicitly maps the parameter to it or states its format/source.

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 gives a specific verb ('Reject') and a clear object ('a merge/promote proposal'), so the agent knows this is a state-changing rejection of a pending proposal. It does not, however, use the term 'synthesis' that appears in the parameter and sibling names, so the link to memory_pending_synthesis/memory_resolve is left implicit.

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?

There is no guidance on when to reject versus when to use memory_resolve, memory_consolidate, or memory_pending_synthesis, and no prerequisites or preconditions are stated. The agent must infer usage purely from the one-line purpose.

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 behavioral burden. It indicates a retry of queued mutations but says nothing about idempotency, what happens to the queue on failure, whether it blocks, or what errors surface — significant gaps for a write-side recovery tool.

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?

A single short sentence front-loaded with the action verb; nothing is wasted. It is arguably too terse for a mutation tool, which caps it below 5.

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?

A zero-param tool with no output schema is simple enough to describe briefly, but with no annotations and no return-value detail, an agent lacks information about outcomes, failure modes, or post-condition state.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 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?

States a specific verb (retry) and resource (writes queued during an outage), so an agent can tell it is about flushing a backlog rather than writing new data. It does not explicitly contrast itself with memory_write or memory_pending_synthesis, but the purpose is 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 phrase 'while Jev was unreachable' implies the triggering condition, giving implicit usage context. However, it never names an alternative (e.g., memory_write) or states when not to call it, so the routing decision is left 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose one useful trait – that deletion cascades to 'its edges' – but says nothing about irreversibility, required permissions, whether the node must exist, or what is returned on success/failure.

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?

A single tight sentence with the destructive action front-loaded and no filler. It is efficient, though arguably under-specified rather than genuinely concise.

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 destructive, non-read-only operation with no annotations, no output schema, and an undocumented sole parameter, the description is too thin. It omits the information an agent most needs before calling it: that the delete is permanent, and what identifier form node_id expects.

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 never mentions node_id. It also introduces a terminology mismatch, calling the target 'a memory' while the schema parameter is 'Node Id' (integer), leaving an agent unsure whether it passes a memory identifier or a graph node identifier.

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 verb ('Delete') and resource ('a memory') and adds a scope detail ('and its edges') that distinguishes it from a mere unlink. However, it never names a sibling such as memory_dismiss or memory_consolidate, so an agent must infer which of the many memory-mutating siblings this is for.

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?

No when-to-use guidance at all. With siblings like memory_dismiss, memory_resolve, and memory_consolidate all plausibly removing or altering memories, the description gives no condition for choosing memory_forget over them, nor any prerequisite.

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 full burden. It does disclose ordering (newest first) and the shape of returned content ('top memory types'), which is useful behavioral context, but it says nothing about pagination, how limit interacts with the ordering, what 'scope' filters, or whether this is a pure read 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?

A single sentence with zero filler, and the most decision-relevant detail (newest first) is front-loaded. Nothing to trim.

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?

An output schema exists, so return values need no explanation, but two parameters are completely undocumented and there are no annotations. For a list tool with a nullable 'scope' argument and a defaulted 'limit', the definition leaves the agent guessing at invocation semantics.

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 explains neither parameter. 'limit' (default 30) and 'scope' (nullable string) are undocumented in both places, so the agent cannot tell what scope accepts or how limit bounds the result set. The ordering hint is output-related, not parameter-related.

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 gives a specific verb ('List') and resource ('stored memories') plus the ordering (newest first) and the returned content (top memory types). It is clear on its own, but it never differentiates itself from siblings like memory_recall or memory_stats, so an agent must infer which listing tool to pick.

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?

There is no when-to-use guidance and no named alternative among the ten sibling tools. The phrase 'list stored memories' implies a browse/inventory use case, but nothing tells the agent when to prefer this over memory_recall.

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 full behavioral burden. It usefully discloses that the agent is the writer and that output items carry an `instruction` field to follow, but it never states whether calling this tool mutates state, whether items persist across calls, or whether the operation is idempotent.

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 the core action front-loaded and the workflow instruction immediately after. The backtick-quoted `instruction` and the dense slash in 'Merge/promote' cost a little clarity, but nothing is wasted.

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?

An output schema exists, so return values need not be explained, and the description covers the workflow an agent must execute. The remaining gap is that it never states where synthesis_id or the pending items come from, forcing the agent to infer the entry point.

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 takes zero parameters, so the baseline is 4. The description does add context by naming the arguments the downstream calls require (synthesis_id, text), which helps the agent understand the data flow even though there is nothing to document on this tool itself.

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 verb and resource: merge/promote proposals produced by consolidation. It distinguishes itself from memory_consolidate by describing the post-consolidation promotion step, though the phrasing 'merge/promote' is slightly ambiguous about whether the tool returns items or performs the merge itself.

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 routes the agent: for each item follow `instruction`, then call memory_resolve(synthesis_id, text), or memory_dismiss if the proposal is wrong. It names the alternative tool and the condition that selects it. It does not say when to prefer this over memory_flush_pending or memory_consolidate, so it stops short of a 5.

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 present, the description carries the full burden, and it delivers a key downstream behavior: SessionStart injects pinned notes first. That tells the agent the real effect of pinning and the injection ordering. It still omits persistence/permission semantics, but the core behavioral payoff is disclosed.

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?

A single tight sentence with the action front-loaded and the downstream effect attached. Every clause earns its place with no 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 simple two-parameter tool with no output schema, the description covers purpose and effect reasonably. The gap is the unexplained required node_id and no mention of what happens for an invalid id or whether pinning is idempotent, which a 0%-coverage schema leaves the description responsible for.

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 does clarify the 'pinned' boolean by framing the tool as pin-or-unpin, but the required node_id parameter is never mentioned or explained, leaving the most important argument undocumented in both schema and description.

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 verb (pin/unpin) on a specific resource (a note), and the parenthetical 'or unpin' immediately clarifies the bidirectional nature. The pinning operation is distinct from siblings like memory_write and memory_recall, so an agent can select it without ambiguity.

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 'the user wants in every session' implies the selection criterion for pinning, which is useful context. However, it names no alternatives (e.g., memory_write for one-off notes) and gives no explicit when-not guidance, so routing is left partly 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 carries the full behavioral burden and does so richly: it explains the adaptive escalation logic for `auto`, the cost/multi-hop trade-offs of `full` vs `lite`, the ~4x cheaper lite path, and the `sufficient`/`missing` and `stop_reason` return signals. This is unusually thorough disclosure for a memory tool.

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 compact and front-loads the core idea ('Adaptive recall'), then layers conditionals and mode semantics without excessive padding. The dense parenthetical for `auto` is information-rich, though the overall flow could be slightly better 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?

For a tool with no annotations, no output schema, and four parameters at 0% schema coverage, the description is only partially complete. It covers behavior and mode selection well but omits any explanation of `max_items`, the full return shape beyond `sufficient`/`missing`/`stop_reason`, and does not explicitly route the agent away from sibling list/stats tools.

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 thoroughly explains `mode` and mentions `scope` (searches scope plus global), but leaves `max_items` (default 8) entirely unexplained and does not clarify `query` formatting. Partial compensation across four undocumented parameters.

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 opening 'Adaptive recall' names the operation and resource, and the following sentences describe the retrieval behavior (searching scope plus global, sufficiency checking). It distinguishes the tool from write-oriented siblings by implication, but does not explicitly contrast it with memory_list or memory_stats. Clear purpose, though sibling differentiation is left to the tool name.

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 detailed guidance for choosing among the `mode` values (auto, full, lite) and tells the agent to verify in code/docs when `sufficient` is false. It does not, however, state when to use memory_recall instead of sibling tools like memory_list or memory_stats; that choice is left 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?

With no annotations, the description carries the full burden. It does disclose one real behavioral trait — source notes are retained and merged ones rank lower — which is genuine context. However, it says nothing about what happens to the pending proposal after resolution, whether the operation is reversible, permission requirements, or the return format.

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, zero waste, with the core action front-loaded and the retention caveat immediately after. Appropriately sized for a two-parameter tool.

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?

This is a mutation tool with no annotations, no output schema, and 0% parameter documentation. The description omits how to obtain a valid synthesis_id, what resolution does to the pending proposal, and whether the write can be undone — significant gaps for a state-changing operation.

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 there are two required parameters. The description hints that 'text' is the synthesized fact and that 'synthesis_id' links to a pending proposal, but it adds no format, source, or constraint details for either parameter, so it does not compensate for the empty 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 states a specific verb ('Store') and resource ('your synthesized fact') and scopes it to a 'pending proposal,' which maps to the memory_pending_synthesis workflow. It does not explicitly name or differentiate itself from the nearest siblings (memory_write, memory_dismiss), leaving the 'resolve' semantics partly to inference.

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?

Phrasing 'for a pending proposal' implies the tool is used after a proposal has been surfaced, but there is no explicit when-to-use statement, no prerequisite chain (e.g., obtain synthesis_id from memory_pending_synthesis), and no guidance on when to prefer memory_dismiss or memory_write instead.

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 full behavioral burden. It adds real signal by naming a degraded/queued write state and scoping the output to 'this server process', but it says nothing about cost, whether it mutates state, or the format of the response.

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?

A single compact sentence with the key content front-loaded and no filler. The unexplained term 'Jev' slightly reduces clarity but costs no extra length.

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?

No output schema exists, so the description must describe the return shape. It lists the reported categories but leaves 'Jev' undefined and the exact fields/units unspecified, so an agent still cannot anticipate the full response.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool 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?

States concretely what the tool returns: node counts, queued/degraded writes, and Jev usage for the server process. Its diagnostics/stats nature clearly distinguishes it from the action-oriented siblings (memory_write, memory_recall, memory_forget), though it never names those siblings 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?

There is no guidance on when to reach for this tool versus the other memory_* tools. An agent can infer it is a read-only diagnostic, but the description supplies no trigger condition, prerequisites, or 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 and does meaningful work: it discloses that the memory model reads content literally, that instruction-like content is rejected, and that pinned notes surface every session. It omits permissions, idempotency, and what a successful write returns.

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?

Four short sentences, front-loaded with the core purpose and constraints, with no filler. Density is high but each sentence carries a distinct rule; the trailing pinned clause could arguably be folded into the scope sentence.

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 6-parameter mutation tool with zero annotations and no output schema, the description covers the essential authoring and scoping behavior but leaves several parameters and the write result unaddressed. Adequate to call it correctly for the common case, incomplete for the full surface.

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% across 6 parameters, so the description must compensate. It explains content (one fact, literal phrasing), scope ('global' or 'project:<name>'), and pinned semantics, and hints at entities/timestamp via 'explicit entity names and ABSOLUTE dates', but leaves source and the entities/timestamp formats entirely undocumented.

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 verb+resource ('Store ONE literal fact') and enumerates the accepted fact types (decision, bugfix, convention, gotcha, preference, event), which sharply separates it from memory_consolidate or memory_recall. It does not name any sibling explicitly, so an agent must still infer that memory_pin exists for pinning rather than using the pinned flag here.

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 concrete authoring rules (explicit entity names, absolute dates, no relative dates) and one conditional trigger for pinned=True. However, it never states when NOT to use this tool versus siblings such as memory_pin, memory_consolidate, or memory_pending_synthesis, leaving the routing ambiguous.

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