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

With no annotations, the description carries the behavioral disclosure burden. It states the core non-destructive consequence—removed from search results but still accessible via includeArchived—and implies reversibility by contrasting with forgetting. It does not detail return values, idempotency, or behavior for already-archived memories, but it covers the key behavioral trait for this simple 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?

Two tight sentences with no filler: the first states the action and immediate consequence, the second gives selection guidance. The most important behavioral detail is front-loaded before the alternative reference.

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 one-parameter, no-output-schema tool, the description is complete: it explains what happens, how archived memories can still be found, and when to use this over the main alternative. Nothing an agent needs to select or invoke the tool correctly is obviously 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%, and the single 'id' parameter is already described as coming from memory_store or memory_list. The tool description adds no extra parameter-level meaning, but since the schema fully documents it, the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Move a memory to the archived tree') and clearly states the effect: out of search results but kept and listed with includeArchived. It also differentiates from the sibling memory_forget, so an agent can distinguish the two at a glance.

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 names the alternative (memory_forget) and gives the condition for choosing this tool: 'Prefer this over forgetting when something may be needed again.' This gives the agent a clear decision rule for when to archive instead of delete.

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 disclosure burden and does add meaningful execution details: 'Items are validated before writes; operational failures are returned per item and are not a transaction.' This clearly communicates the non-atomic, per-item failure behavior. It stops short of describing return shapes, permissions, or size limits, but the core execution semantics are 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?

Two sentences with no fluff. The action and scope are front-loaded, and the second sentence adds non-obvious behavioral constraints. Every clause 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 is adequate for selecting and using the tool at a high level: it names operations, validation, and non-transactional behavior. However, no output schema exists, and the description does not clarify the item structure for store/update, the meaning of 'bounded,' or the success response shape, so an agent is left with some uncertainty after 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 coverage is 100%, so each parameter already has a description; the description adds little that is not already expressed by 'Delete/export ids' and 'Store or update items.' It does reinforce the operation-to-parameter mapping, but this is modest value beyond the schema.

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

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

The description names a specific action ('Run') and an explicit resource ('a bounded store, update, delete, or selected export batch'), with the four operation modes enumerated. It clearly differentiates itself from the single-operation sibling tools by being the batch variant.

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 word 'batch' and the operation list imply usage for grouped memory operations, but the description never explicitly says when to choose this over memory_store, memory_update, memory_delete, etc. There are no exclusions, prerequisites, or alternative-routing statements; usage is mostly inferred rather than stated.

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 behavioral disclosure burden. It does disclose deduplication behavior and the REMEMBRA_LLM/API key prerequisite, but the phrase 'changed quantities go to the LLM merge' is vague and unexplained, and side effects or failure behavior are not covered.

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 main action, and includes dedup behavior, timing, and a prerequisite without filler. 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 core operational context is present: what to do, when to call, and what input to provide. However, with no output schema, the description does not explain what the tool returns or how the LLM merge behaves, leaving some ambiguity for an agent.

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 baseline is 3. The description adds little beyond the schema, only reinforcing that transcript can be a detailed summary. No extra semantics are provided for scope or 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 clearly states the tool extracts facts, decisions, roles, and history from a transcript and stores them, which is a specific verb+resource. It does not explicitly name sibling tools to differentiate, but the session-digest framing distinguishes it from memory_store and memory_batch.

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 clear timing guidance: 'Call at the end of a session' with a transcript or detailed summary. It does not mention when not to use the tool or alternatives, so it stops short of full 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the most important trait for a destructive operation: the deletion is "Permanently" irreversible. However, it says nothing about deletion side effects (e.g., impact on related memories given memory_relate and memory_digest siblings), behavior on a non-existent id, or required permissions, which leaves gaps for a mutation 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 a single six-word sentence with zero filler. The destructive scope "Permanently delete" is front-loaded, and the deletion key "by its id" completes the sentence efficiently. 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 one-parameter delete-by-id tool this is minimally adequate: the agent knows the action, the key, and the permanence. But with no annotations and no output schema, an agent is left guessing about error behavior (e.g., deleting a non-existent id), cascading effects on related memories, and confirmation semantics. A short note on side effects or missing-id handling would make it complete.

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

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

Schema description coverage is 100%, so the schema already documents id as "Memory id (from memory_store or memory_list)". The description only echoes the parameter relationship with "by its id" and adds no new semantics such as id format, validity constraints, or idempotency behavior. Baseline 3 is appropriate since the schema does the heavy lifting.

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 and resource: "Permanently delete a memory by its id." The word "Permanently" usefully differentiates this from the sibling memory_archive (likely a soft-delete) without naming it. It slightly misses the top tier because it does not explicitly name the sibling it is not, but the intent 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?

No guidance is given about when to use this tool versus alternatives. The sibling list includes memory_archive, memory_revive, memory_update, and memory_get, any of which could be relevant alternatives for a user considering deletion, yet the description offers no routing or exclusion. The usage context is only weakly implied by the purpose statement itself.

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 burden. It discloses that the tool returns the memory plus related links and backlinks, and implies a read-only operation via 'Fetch'. However, it does not explicitly state the absence of side effects, authentication requirements, or error behavior (e.g., if the id does not exist). It adds some behavioral context but leaves gaps.

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 core operation and return content, followed by a targeted usage note. No extraneous information; each sentence contributes meaningfully.

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 read tool with no annotations and no output schema, the description covers the essential purpose, return contents, and a usage trigger. It is somewhat incomplete regarding error cases or side-effect confirmation, but these are minimal for a 'get' operation. Overall it provides enough for an agent to select and invoke the tool 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?

The schema already describes the 'id' parameter with 100% coverage ('Memory id — returns the memory with related links and backlinks'). The description does not add new parameter-level meaning; it repeats the same return behavior. Baseline 3 applies under high schema coverage.

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 the specific verb 'Fetch', names the resource ('one memory by id'), and specifies the return content ('related links and backlinks'). It also distinguishes from memory_search by noting it returns the full statement rather than a snippet, making the tool's role clear relative to 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 explicitly says 'Use after memory_search when you need the full statement, not the snippet,' which names the relevant alternative and the condition for using this tool. This is clear when-to-use guidance, and it also implies when not to use it (when a snippet suffices).

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 and it does add value by disclosing snapshots on content-changing updates, unified line diffs, and newest-first ordering. However, it does not state that the operation is read-only, whether non-content changes are excluded, or any side effects or access requirements, leaving notable gaps.

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

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

The description is compact and front-loaded: the first sentence states the core purpose, and the em-dash clause adds the snapshot rule without excess. The final 'Newest first' specifies ordering 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?

There is no output schema, so the description must compensate for return expectations. It gives high-level behavior (diffs, newest first) but does not specify the shape of each version entry (e.g., timestamps, fields, diff format). The tool is simple, but an agent lacks precise output structure knowledge.

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 description coverage is 100%, so the schema already defines each parameter clearly. The description adds no parameter-specific meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description clearly names the action ('show version history'), the resource ('one memory'), and the key qualifier 'one memory' that distinguishes it from collection-oriented siblings like memory_list and memory_batch. It also implies it is not the current-state tool (memory_get) by emphasizing 'history'.

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 the use case—retrieving a memory's historical versions—but does not explicitly state when to choose this over alternatives like memory_get, nor does it provide any exclusions or alternative routing. The usage context 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering and pagination but does not state default behavior for the boolean include flags (e.g., whether expired/archived are included by default), ordering, or whether the operation is read-only (though implied). This is a significant gap for a list 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 a single, efficient sentence that front-loads the primary action and immediately covers filtering and pagination. No wasted words or redundant details.

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 8 parameters, no annotations, and no output schema, the description is insufficient. It does not explain default filter behavior, response format, or how it differs from sibling list-like tools (memory_search, memory_history). An agent would need to infer too much 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 only 38% (3 of 8 params have descriptions). The description adds meaning for scope/type and offset/limit (matching the text), but completely omits explanation for includeFuture, includeExpired, includeQuarantined, and only partially covers includeArchived (which the schema already describes). Since coverage is low, the description should compensate more thoroughly.

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 ('List'), a clear resource ('stored memories'), and mentions filtering and pagination. It is unambiguous about what the tool does, though it does not explicitly name sibling alternatives like memory_search or memory_get to differentiate 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?

The description implies when to use it (listing memories with optional filters) but provides no explicit guidance on when to prefer this over memory_search, memory_history, or memory_get. There are no exclusion criteria or alternative routing.

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 it delivers. It discloses destructive auto-deletion, archiving conditions, TTL defaults, embedding backfill, and explicitly states that roles never decay. It also reassures that calling it is safe anytime.

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 one dense but well-organized sentence that front-loads the action and then lists each behavior clearly. There is no filler, and every phrase contributes operational meaning.

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 parameterless maintenance tool with no annotations and no output schema, the description covers what happens, when it happens, configuration defaults, and safety. Nothing needed to invoke the tool correctly 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?

The tool has zero parameters, so the schema carries no burden. The description adds useful configuration context by naming REMEMBRA_ARCHIVE_AFTER_DAYS and REMEMBRA_ARCHIVE_TTL_DAYS with defaults, which is more than baseline for an empty-schema tool.

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 action ('Run maintenance') and enumerates concrete operations: archive unused memories, auto-delete old archived memories, and backfill missing embeddings. This clearly differentiates it from the sibling list/forget/store/digest/search 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?

The description does not name alternatives, but it gives explicit timing guidance: 'Safe to call anytime.' Since this is a standalone maintenance operation rather than a choice among competing query/update tools, this contextual guidance is sufficient.

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 disclosure burden. It does add useful behavioral context: links are directed, targets must pre-exist, and backlinks are observable via memory_get. But it omits other behavioral traits an agent may need — whether add is idempotent when a link already exists, whether a partially failing batch is transactional, or error behavior on missing targets. Adequate but with clear gaps.

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 core action and domain are front-loaded in the first sentence, while the second adds examples plus two constraints (target existence, backlink visibility). Every clause 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 graph-modifying tool with a rich schema (enums fully enumerated, 100% param coverage) and no output schema, the description covers the essential operational facts: what it does, a prerequisite, and how to observe results. Minor omissions like idempotency and partial-failure behavior exist, but the essentials an agent needs to invoke it correctly are 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 description coverage is 100%, so the schema already documents all four parameters and the two enums (kind with six values, action with two). Per the baseline for high schema coverage, the description need not repeat parameter details. It does add genuine value by explaining the semantics of the link kinds ('tie a decision to the facts it depends on'), but that is contextual enrichment rather than compensation for a documentation 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 states a specific verb (create/remove), a resource (directed links between memories), and names the domain ('relationship graph'). The examples — tying a decision to its facts, or a history entry to the decision it records — make the resource concrete and clearly distinguish this from sibling tools like memory_store (storing a memory) and memory_get (reading one). An agent can tell what this does without opening the schema.

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 examples imply when to use it (relating decisions, facts, history entries) and it states a concrete prerequisite ('Targets must exist'). It also routes the agent to memory_get for viewing backlinks. However, it never explicitly names alternatives or states when NOT to use this tool versus memory_update or memory_store. The usage context is present but implicit rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a state change (archived to active) but does not specify whether the operation is idempotent, what happens if the memory is already active, whether it is reversible, or any potential side effects. For a mutation tool, this is a significant gap in transparency.

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 no wasted words. It is front-loaded with the action and result, making it immediately clear. For a tool with only one parameter and no complexity, this is appropriately sized.

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 simplicity (one parameter, no output schema, no annotations), the description is minimally sufficient but lacks important operational context. It does not mention error conditions, idempotency, or prerequisites (e.g., that the memory must already be archived). An agent could call it correctly based on the schema, but would benefit from a note about failure cases or state constraints.

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 provides 100% coverage of the single 'id' parameter with a description indicating it comes from memory_store or memory_list. The description adds no additional meaning beyond the schema, so the baseline of 3 applies. No extra context about the parameter is needed, as the schema is fully descriptive.

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 ('bring back') and specific resource ('archived memory') plus the result ('active search'). It clearly indicates the tool unarchives a memory, but it does not explicitly distinguish from siblings like memory_archive (which archives) or memory_update (which could modify status). However, the purpose is unambiguous enough for an agent to infer its role among 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?

No guidance is provided on when to use this tool versus alternatives. For instance, it does not mention that this should be used when a memory needs to become searchable again, or that memory_archive is the inverse. The description simply states the action without context on conditions or exclusions, leaving an agent to infer usage from the name and 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 provided, the description carries the full behavioral disclosure burden, but it only says memories are 'relevant' and recoverable. It does not explain matching semantics, ordering, return format, or how filters like includeExpired/includeArchived/includeQuarantined affect results. This is a significant transparency 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 short and front-loaded with the core retrieves role, and the usage note is valuable. However, the phrase 'facts, decisions, roles and history' largely duplicates enum values already present in the schema, so not every word adds unique value.

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 9 parameters, no annotations, and no output schema, this description is insufficient for an agent to fully understand how to invoke the tool correctly. It tells when to call it but not how filtering flags, limits, or explain scoring behave, leaving key invocation details unresolved.

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 only 33%, so the description must compensate for the many undocumented parameters. It does not; it only lists memory categories like facts, decisions, roles, and history, which partially overlap the 'type' enum. The six undocumented include flags and limit behavior remain unexplained.

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 verb ('Retrieve') and resource ('relevant memories from external storage'), and its focus on relevance and session-start recovery distinguishes it reasonably from memory_list or memory_get. However, it does not explicitly differentiate from siblings, so it stops short of a 5.

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?

'Call this at the start of a session (or whenever prior context might exist)' is explicit, actionable guidance on when to use the tool. It lacks any mention of when NOT to use it or which sibling tools are better suited for specific cases, so it does not fully earn 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?

No annotations are provided, so the description must disclose behavioral traits. It states persistence across resets, which implies a write operation, but does not mention side effects, overwrite/deduplication behavior, permission requirements, or what happens on success. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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 concise: a single sentence stating purpose followed by one sentence of type guidance. It front-loads the core action and avoids redundancy. However, it could be slightly more structured by grouping related parameters, but for its length it is efficient with no wasted words.

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 17 parameters including nested objects, the description is minimal. It does not explain the other type enums (preference, constraint, instruction, entity, relationship, event, observation), nor does it clarify owner/scope/trust/access semantics or the provenance object. There is no output schema, so return value is unaddressed. The description is inadequate for the tool's complexity.

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 fully documents all 17 parameters. The description adds semantic guidance for the 'type' parameter by mapping specific types to use cases, which adds value beyond the schema's enum listing. However, it does not add meaning to other parameters like owner, scope, trust, or retention, which remain schema-only. 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 clearly states the tool persists a memory entry to survive context resets, and gives specific examples of memory types (fact, decision, role, history). This distinguishes it from read-oriented tools like memory_search or memory_list, but it does not explicitly compare to other write tools like memory_batch or memory_update. The verb 'persist' and resource are clear.

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 guidance on selecting the 'type' field (fact, decision, role, history) with conditions for each. However, it does not say when to use this tool vs. memory_batch (for storing multiple) or memory_update (for modifying existing entries). No exclusion or alternative tool names are mentioned. Usage guidance is partial.

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 successfully discloses two important side effects: changing scope moves the memory between trees, and a content change refreshes the embedding and snapshots the old version into memory_history. This adds meaningful behavioral context beyond the schema. However, it does not mention concurrency control (expectedVersion) or potential conflict behavior, which could be relevant for agents.

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 fluff. It front-loads the primary action and allowed fields, then adds the two critical behavioral caveats. Every clause earns its place, and the language is precise and scannable.

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 12 parameters, a rich schema, and no output schema, the description covers the essential operational aspects: what fields can be updated and the key side effects. It does not explain return values, error scenarios (e.g., 409 conflict with expectedVersion), or permission requirements, but these are either implied by the schema or not critical for correct invocation. The absence of an output schema means the agent cannot expect structured response details, which is fine. Overall, the description is sufficient for calling the tool 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 coverage is 100%, so the baseline is 3. The description adds semantic value by explaining the effect of specific parameters: scope changes cause tree movement, and content changes trigger embedding refresh and history snapshots. This goes beyond the schema's parameter descriptions, which only state defaults and basic meaning. Other parameters like trust, retention, and reason are not elaborated, but the schema descriptions are adequate.

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 operation (Patch), the target (an existing memory by id), and the supported fields. It distinguishes itself from sibling tools like memory_store (create) and memory_forget (delete) by explicitly limiting to existing memories and listing updateable attributes.

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 explicit guidance on when to use this tool vs. its siblings. While 'Patch an existing memory' implies it is for updates rather than creation, it does not mention alternatives like memory_store for new memories or memory_get for retrieval, nor does it specify prerequisites (e.g., that the memory must already exist). This leaves the agent to infer usage from the operation nature.

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