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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the mechanism and the conditional write ('optionally create derived memories'), which is genuinely useful, but it says nothing about whether original memories are modified or deleted, whether the operation is idempotent, or what a consolidated memory's contents look like.

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 mechanism front-loaded and the optional behavior second. The closing usage sentence is somewhat vague but still occupies little space; 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?

Six optional parameters with a fully documented schema and no annotations make this a moderately complex, mutation-capable tool. The description covers the mechanism and write condition adequately, though with no output schema the return shape (a cluster report? created memories?) remains unspecified.

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

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

Schema coverage is 100%, so all six parameters are already documented, including threshold default 0.7 and minClusterSize default 2. The description adds only that 'derive' produces memories linked via 'derived_from'; it does not clarify scoping precedence (userId vs projectId vs sessionId) or how threshold affects output volume.

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 ('Cluster similar memories') plus the mechanism ('embedding similarity') and the optional side effect ('create derived/consolidated memories linked via derived_from'). This is clear, but it never distinguishes itself from near-neighbors like merge_memory or link_memory, leaving some ambiguity about which tool produces which shape of result.

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?

'Use during periodic consolidation' implies a trigger context but gives no explicit when-to-use vs when-not rules and names no alternatives among the 15 siblings. An agent still has to infer whether to reach for this instead of merge_memory or link_memory.

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 does real work: it discloses the write side effect and constrains it to data/exports/, and it states the return payload (path, byte size, JSON preview). It omits important mutation behavior such as what happens when the target filename already exists (overwrite vs error) or failure modes.

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?

Three short sentences, front-loaded with what is exported and where, then the write constraint, then the return shape. Nothing is padded, though the parenthetical is slightly awkward.

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 two-parameter, non-annotated tool with no output schema, the description covers the side effect, its directory boundary, and the return values, which is what an agent needs. Only overwrite/error semantics are missing.

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

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

Schema coverage is 100%, so the schema already documents filename constraints and the includeInteractions flag with its default. The description only echoes the optional raw-interactions behavior and the directory constraint, adding little syntax or format detail 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 gives a specific verb (export) and enumerates the resources (preferences, lessons, profile, optionally raw interactions) plus the destination (a JSON file under data/exports/). It implicitly separates itself from recall/import_memory by stating the result is a file, but it never names a sibling, so an agent must infer that distinction.

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

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

Usage is only implied: dumping memory to a file suggests backup or portability scenarios, but the description never says when to prefer this over recall or get_profile, nor any preconditions. No explicit exclusions are given.

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 and does well: it discloses determinism, dry-run default behavior, the mutation triggered by apply=true, and the source tag (source=captured). It does not cover authorization, rate limits, duplicate handling, or what the proposed candidates look like.

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 action, and contains no filler. Every clause adds useful information about determinism, default mode, or the apply toggle.

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 five-parameter tool with no annotations and no output schema, the description is largely complete on purpose and mutation behavior. It does not describe the shape of proposed memory candidates or return behavior, but it covers what an agent needs to choose dry-run versus apply.

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 five parameters including defaults and constraints. The description adds meaning only for apply=true, which is already described in the schema, and does not add further parameter semantics beyond that baseline.

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: scan recent captured interactions for memory-intent phrases and propose memory candidates. The phrase 'deterministic, no LLM' adds a useful distinguishing trait. It does not explicitly distinguish itself from siblings like remember or consolidate, so it falls 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?

The description gives clear operational guidance for dry-run versus apply: 'Dry-run by default; pass apply=true to create them.' However, it does not explain when to use this tool instead of alternatives such as remember, save_lesson, or consolidate, nor does it state prerequisites.

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 disclosure burden. It does say the operation deletes a row and syncs the search index, which is real behavioral context, but it doesn't state whether the delete is permanent, whether it requires confirmation, or what happens to data created by link_memory or merge_memory when a row disappears.

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, both front-loaded and free of filler. The destructive action comes first and the parameter hint follows, so an agent can read the essentials immediately.

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

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

For a destructive tool with no annotations and no output schema, the description covers what is deleted and the index-sync effect, but it says nothing about irreversibility, recovery, or side effects on related memory links. Enough to call it, not enough to call it safely.

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 still adds meaning by mapping id sources to the type enum ('remember' implies preference, 'save_lesson' implies lesson), which goes beyond the schema's generic note that ids can coincide across tables.

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 and resource: 'Delete one memory row (preference, lesson or interaction) by id'. It also mentions syncing the search index, which separates it from update_memory, merge_memory and link_memory among the siblings.

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

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

It gives useful calling context about id provenance ('ids from remember are preference ids, from save_lesson are lesson ids'), but that is parameter guidance rather than when-to-use guidance. Nothing says when to forget rather than update_memory, merge_memory or consolidate, and no prerequisite or irreversibility warning is given.

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 disclosure burden and does convey meaningful behavior: hybrid retrieval, optional graph-neighbor expansion, and a token budget that caps the assembled output. It does not state that it is a read-only operation, what the returned context looks like structurally, or what happens when the budget is exhausted or nothing matches.

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, functional detail front-loaded, no filler words. The usage sentence is terse but earns its place by orienting the agent to the pre-task loading pattern.

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 an 8-parameter tool with no annotations and no output schema, the description covers the core concept and the budgeting behavior, but leaves gaps: no return-shape hint, no explanation of how the multiple scope parameters interact, and no coverage of the undocumented sessionId. Adequate but not 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 coverage is 88%, so the schema already documents nearly all parameters, making 3 the baseline. The description adds framing value by explaining that the query seeds hybrid retrieval and that graph expansion and budgeting are tunable dimensions, but it adds no detail on scoping semantics (userId/projectId precedence) or on sessionId, which the schema leaves 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?

Uses a specific verb ('Assemble') plus a clear resource ('relevant memories') and names the mechanism (hybrid retrieval, optional graph expansion, token budgeting), which distinguishes it from plain lookups like recall or search_history. It stops short of explicitly naming the sibling tools it differs from.

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 second sentence gives a use case ('load memory into context before a task'), which implies when to call it. There is no guidance on when to prefer it over recall, search_history, or get_recent_interactions, and no exclusions or prerequisites.

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 load and it does disclose the non-obvious behavioral detail that omitting all scope parameters silently restricts results to GLOBAL memories, plus hard caps on preference and lesson counts. It does not describe authorization, error behavior, or whether the read is cheap or expensive, but the important surprise is surfaced.

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, contents listed first and scoping second, which is the right order for an agent. Slightly dense jargon ("distilled", "auto-projected") costs a little readability.

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-required-parameter read tool with no output schema and full schema coverage, the description gives enough: what comes back, how much of it, and how scoping reshapes the result. Only the absence of any return-shape detail (structure versus plain text) keeps it from being fully 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 coverage is 100%, so the baseline is 3, and the description earns an extra point by explaining how the three scope parameters interact with the auto-projected memory set and what happens when none are supplied. The per-parameter "GLOBAL plus X" wording is largely duplicative of the schema, but the omission default is added value.

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?

"Get the distilled user profile" pairs a specific verb with a resource, and the description enumerates the returned contents (profile sections, top preferences by confidence capped at 15, 5 most recent lessons). It is clear on its own but never names a sibling such as get_context or recall, so an agent must infer the boundary from names alone.

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 states the default behavior when no scope is given (GLOBAL memories only), which is effectively a when-not condition and steers parameter choice. However, it offers no guidance on when to choose this over recall, get_context, or search_history, leaving the sibling routing 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 supplied, so the description carries the full burden. It does disclose ordering and the return line format, and 'List' implies a non-mutating read, but it says nothing about volume, truncation, whether content is full or previewed, or any privacy/permission constraints on captured interaction content.

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, front-loaded with what is returned and in what format before the use case. Nothing is redundant or padded.

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 three-optional-parameter read tool with no output schema, the description usefully compensates by specifying the returned line format. The only real gap is silence on result volume and on the sessionId filter, which matters when logs can be long.

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

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

Schema description coverage is 100%, so all three parameters (kind, limit, sessionId) are already documented in the schema, including the enum and the limit range. The description only echoes the kind filter and adds no new meaning for limit or sessionId, so the baseline of 3 applies.

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

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

It states a specific verb and resource ('List recently captured raw interactions') and adds ordering ('newest first') plus the exact output line shape '[id] ts [kind] content lines'. It implicitly separates itself from the memory siblings by emphasizing 'raw' interactions, but never names search_history or get_context as the alternative.

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?

'Use for auditing history or before distilling memory' supplies a clear use context, which is more than most tools offer. It stops short of exclusions or naming which sibling to use instead when the agent wants semantic search rather than a raw chronological dump.

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 and does real work: it discloses validation of type, deduplication against existing memories, that active memory is never blindly overwritten, and that the operation is non-mutating unless apply=true. It omits what a skipped/duplicate item looks like in the result and any size or permission constraints, which keeps it below the top tier.

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?

Three short sentences, front-loaded with what is imported and from where, followed by behavior and then the safety/dry-run rule. Every clause carries information an agent needs; nothing is padding.

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 5-parameter mutation tool with no annotations and no output schema, the description covers inputs, validation, dedupe, overwrite safety and the dry-run gate, which is the critical surface. It leaves the result shape (counts, per-item errors) unexplained, which an agent would need to interpret the dry-run report, but the omission is narrow.

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 file, json, apply, userId and trusted are already documented, including the non-obvious trusted behavior around auxiliary data. The description restates the dry-run/apply behavior and the input shapes but adds no syntax, precedence, or edge-case meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Import memories') plus the two accepted input forms ('a JSON array or a .json file inside data/exports/'). The inverse relationship to export_memory and the distinction from remember/save_lesson (bulk vs single) is implicit in the scope, and the name/schema line up 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?

Gives concrete operational guidance: 'Dry-run by default; pass apply=true to insert', which tells the agent the calling pattern and that a safe preview exists. It stops short of naming when to prefer remember/save_lesson over a bulk import, or what the source of the export must be, so no explicit exclusions are 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?

No annotations are provided, so the description carries the full disclosure burden. It does not say whether the link is directional (source→target), whether duplicates are rejected or merged, whether it is idempotent, or what happens if an ID does not exist – significant 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?

A single front-loaded sentence that names the action and the resource. The parenthetical enum list is redundant with the schema and is the only wasted content.

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 three-parameter mutation tool with no annotations and no output schema, the definition covers what is created but not directionality, idempotency, failure modes, or return value. Adequate to attempt a call, incomplete for calling it correctly in edge cases.

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

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

Schema coverage is 100% and each parameter already has a description, so the baseline is 3. The description repeats the relation enum verbatim without explaining semantics of individual relations (for example, whether 'supersedes' deactivates the target) or which ID is source versus target.

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

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

The description states a specific verb and resource: 'Create a typed relationship between two memories in the graph.' The agent can tell this is a graph-edge creation tool, but nothing distinguishes it from siblings like merge_memory or update_memory.

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 use this rather than merge_memory, consolidate, or update_memory, and no prerequisites such as both memories needing to already exist. The agent must infer usage entirely 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?

No annotations are provided, so the description carries the transparency burden. The verb 'Summarize' clearly implies a non-mutating read-style operation, but the description does not explicitly state that it makes no changes, nor does it describe any other behavioral details like cost or freshness.

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 leads with the core action and then enumerates the exact delivered statistics. Every word adds useful information, with no filler or redundancy.

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

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

With no output schema, the description serves as the sole source of return-value expectations, and it enumerates counts, totals, file size, timestamps, and profile sections. Some terms like 'profile sections' remain somewhat vague, but for a simple zero-parameter stats tool this is reasonably 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 tool has zero parameters, so there is no parameter semantics to clarify. The schema coverage is trivially 100%, and the description reasonably focuses on the output content instead.

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 ('Summarize') and identifies a clear resource (memory usage) with a detailed list of metrics included in the output. It is distinct from sibling tools in content, though it does not explicitly contrast with 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 this tool is for retrieving high-level memory statistics and summaries rather than detailed records or management actions. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives.

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

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

With no annotations provided, this sentence carries the behavioral burden and does disclose the key state change: the source is superseded rather than deleted, and provenance lands in metadata.merged_from. It stops short of stating reversibility, whether the merge can be undone, required preconditions (e.g., same type/workspace), or what the call 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?

Two short sentences, zero filler, with the core operation front-loaded and the side effect following. Every clause contributes information the agent needs.

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 two-parameter mutation with full schema coverage and no output schema, the definition covers purpose, direction of the merge, and the resulting state of both records. The main residual gap is the absence of any safety or reversibility note, which matters more here because no annotations supply that context.

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 both parameters already state which record becomes superseded and which becomes active. The description's phrase "duplicate/near-duplicate" adds a small amount of intent framing but no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description uses a specific verb+resource ("Merge a duplicate/near-duplicate memory into a canonical one") and clarifies the source/target duality. It distinguishes the operation from update-style siblings implicitly, but never names the closest sibling (consolidate) so a direct comparison is left to the agent.

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?

"Duplicate/near-duplicate" implies the triggering condition for use, which is useful. However, there is no explicit when-not guidance and no routing to alternatives such as consolidate, update_memory, or forget when a memory is stale rather than duplicated.

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 supplied, so the description carries the full burden; it does disclose the sources consulted (a full-text index over preferences and lessons, plus recent matching interactions), which implies a read-only lookup. It does not say how results are ranked, how 'recent' is bounded, or how the two result sets are combined, which matters for a tool that merges sources.

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 with zero filler; the resource scope is front-loaded and the usage hint follows. Nothing is repeated from the title beyond what is needed.

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 two-parameter, no-annotation, no-output-schema tool, the description covers the core purpose but omits result shape and ranking behavior, which the agent cannot learn from structured fields. Adequate, but an agent cannot predict what the returned matches look like or when 'recent' items appear.

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 both parameters are already documented in the schema. The description adds only that matching is full-text over preferences and lessons and that 'limit' caps preference/lesson matches, which is a marginal clarification rather than new meaning.

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 (search/recall) and concrete resources (preferences, lessons, recent matching interactions), which is far more informative than the bare name 'recall'. It does not explicitly contrast itself with close siblings like search_history or get_recent_interactions, so an agent must infer the boundary.

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?

'Use before starting a new task' gives a concrete application context that tells the agent when to reach for this tool. However, with 15 siblings including search_history and get_recent_interactions, no alternative or when-not condition is named, leaving overlap unresolved.

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 and does well: it discloses upsert semantics, the confidence bump of +0.1 per re-save capped at 1.0, and the return value (row id). It does not say what happens to the previous value on a same-key write, which is the main remaining gap 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?

Three short sentences, each carrying distinct information (upsert identity, confidence behavior, return value), with the core action front-loaded. No filler or restatement of the tool name.

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

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

For a 3-parameter, non-nested, annotation-free write tool with no output schema, the description covers identity semantics, side effects, and the return value. Only the overwrite/conflict behavior and any failure conditions are left unstated.

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, but the description adds genuine meaning the schema cannot express: the pair category+key is the upsert identity, so agents know re-saving with the same pair mutates rather than duplicates. That is the single most decision-relevant fact about these 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?

Description names a specific verb (save/update) and resource (a user preference) and adds the key mechanic, a composite category+key upsert. It implicitly separates itself from siblings like save_lesson and update_memory via the term 'user preference', but never names or contrasts 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?

Usage is only implied: the mention of returning a row id 'for forget()' hints at the store-then-remove lifecycle, but nothing states when to call remember versus save_lesson, update_memory, or link_memory. An agent must infer the routing 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, the description carries the full burden; it makes clear this is a write operation whose content is a correction-derived lesson, which is useful behavioral context. However, it says nothing about persistence, duplicate/repeat saves, whether lessons are later surfaced by recall, or any permission requirements. That is a moderate gap for an unannotated 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?

Two short sentences with zero filler: the content specification comes first and the timing instruction second. Every clause earns its place and nothing is buried.

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 three-param, no-output-schema tool, the description covers both what to record and when to record it, which is enough to invoke it correctly. It leaves open what happens to saved lessons afterward (how they are retrieved or whether saves can be updated), a minor omission given the tool's simplicity.

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

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

Schema coverage is 100% and each of the three properties has its own description. The prose ('what situation, what mistake, what is the correct way') restates the parameters without adding format or length guidance beyond the schema's min/max constraints. 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 gives a specific verb ('Record') and resource ('a lesson learned from a correction') and enumerates the three content components, so the agent knows exactly what gets stored. It does not name or differentiate itself from siblings like remember or update_memory, so it falls 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?

The trigger is explicit and actionable: 'Call immediately after the user corrects your work.' That tells the agent the exact moment to use it. It offers no exclusions or comparison to alternatives such as remember or update_memory, which keeps it out of 5 territory.

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 alone; it does disclose two useful behaviors: snippets are truncated to 200 chars and results are timestamped. It does not state permission requirements, whether search is case-insensitive or substring vs. semantic, or what happens when nothing matches.

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, front-loaded with the core action and searchable scope, followed by the return-value note. No filler or redundancy.

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

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

For a three-parameter read tool with full schema coverage and no output schema, the description supplies the essentials: what is searched, how results are scoped, and the return snippet format. Minor gaps remain around result ordering and empty-result behavior, which matter lightly for a search tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning by naming the searchable field (prompts of kind='prompt') and reinforcing that it is keyword-based, which clarifies query semantics not stated in the schema. It does not elaborate on limit or sessionId beyond the schema.

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

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

States a specific verb (search) and resource (past user prompts, kind='prompt') and discloses the return shape (timestamped snippets truncated to 200 chars). It is clearly distinct from siblings like recall or get_recent_interactions, though it doesn't explicitly name an alternative to distinguish 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?

Usage is implied by the name and by the keyword-search framing, but there is no explicit statement of when to prefer this over recall or get_recent_interactions, nor any exclusion of other memory kinds beyond the parenthetical kind='prompt'.

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 supplied, so the description carries the full burden. It does disclose the single most important non-obvious trait: content edits create a superseding memory by default. It does not say what happens to the original memory (retained, archived, tombstoned), whether the returned id refers to the new or old record, or any auth requirements — significant gaps for a mutation with zero annotation coverage.

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

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

Two sentences, no filler, and the highest-value detail (supersede default) is placed in the second sentence where it is easy to find. Nothing repeats the title or schema verbatim.

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 9-parameter mutation tool with no annotations and no output schema, the description covers the core semantic trap (content edit vs in-place edit). What is missing is the fate of the superseded record and the shape of the result, which an agent would want before calling it.

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 description restates the mutable field set and, crucially, explains the default and override semantics of supersede, which the schema only partially conveys. With 78% schema coverage the baseline is 3, and naming the field group plus the supersede default adds meaning beyond it.

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 (Update) and resource (memory) and enumerates the mutable fields (summary/importance/confidence/valid_from/valid_until/metadata), which tells an agent exactly what can change. It doesn't name a sibling tool, but the supersede-vs-in-place distinction implicitly separates it from remember/merge_memory/forget.

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 one concrete usage condition — set supersede=false to edit in place — which implies the default routing for content edits. It never states when to prefer a sibling like merge_memory or forget instead, so guidance is implied rather than explicit.

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