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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds the permanence framing and, more valuably, the supersession workflow that tells the agent deletion is not the right move for replaced facts. It stops short of describing irreversibility mechanics or failure modes, so not a 5.

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

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

Two sentences, no waste. The destructive action and its scoping condition lead, and the alternative path follows 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 single-param, no-output-schema tool whose annotations already carry destructiveness and idempotency, the description covers everything an agent needs: what it does, when it is appropriate, and what to do instead when it is not.

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?

One parameter with 100% schema coverage, so the schema already documents 'id' with its mem_ prefix format. The description adds no further semantic detail about the identifier, which is the baseline expectation when the schema does the work.

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 ('permanently delete') and resource ('a memory') and narrows scope to memories that are 'wrong or must not be kept.' An agent can distinguish this from siblings like remember, reinforce, and link without opening any 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?

Gives an explicit trigger ('wrong or must not be kept') and an explicit when-not with the preferred alternative: if a fact was superseded, remember the new fact and use link with relation 'supersedes' instead. This routes the agent to the correct sibling rather than destroying history.

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

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

Annotations already declare non-read-only, idempotent, non-destructive, closed-world behavior. The description adds that the relation is 'named' and that linking affects later recall, but says nothing about directionality semantics, failure when ids don't exist, or how duplicate links are handled despite the idempotent hint.

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

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

A single sentence that front-loads the action and ends with the payoff, with no redundant or filler text.

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, annotations covering the safety profile, and full schema coverage, the description is adequate but thin: it omits directionality of the from/to pair and any error or failure behavior, which an agent linking memories would benefit from knowing.

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 'from', 'to', and 'relation' are fully documented in the schema, including the default relation and allowed values. The description's mention of a 'named relation' adds no syntax or format detail beyond that, 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 gives a specific verb and resource ('Connect two memories') plus a named relation, and it states the resulting effect on recall. It does not explicitly distinguish itself from siblings like reinforce or remember, but the operation is clearly identifiable.

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 phrase 'so recalling one brings context from the other' hints at building a knowledge graph for later recall, but there is no explicit when-to-use, when-not-to-use, or comparison against siblings such as reinforce, which also relates memories.

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

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

The annotations show readOnlyHint=false on what is nominally a search, which would otherwise look contradictory; the description resolves this by disclosing the side effect: 'Returned memories are reinforced.' It also explains the retention/fade behavior that governs ranking, adding real behavioral context beyond the structured fields.

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 sentences, each earning its place: purpose, when-to-call, then ranking/side-effect mechanics. The most important action guidance is front-loaded and there is no filler.

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

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

For a 4-parameter tool with no output schema, the description covers purpose, timing, ranking semantics, and the mutation side effect. It stops short of describing the shape or ordering of results, which an agent might want, but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so query, tags, limit, and since are all documented in the schema with defaults and formats. The description adds no parameter-level detail (e.g., how tags interact with query), 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 names a specific verb and resource ('Search long-term memory') and clarifies the retrieval mechanism (hybrid BM25 + embeddings, weighted by retention). It distinguishes itself adequately from siblings like remember/forget/link, though it never explicitly contrasts 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?

It states a clear trigger condition: 'Call it before answering questions about this user or project and when starting a task.' That is actionable usage guidance. It does not name when NOT to use it or point to a sibling alternative, which keeps it short of a 5.

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

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

Annotations already declare this is a non-read-only, non-destructive write, so the safety profile is covered. The description adds the decay-slowing effect, which is genuinely informative, but it never explains that the operation is non-idempotent (idempotentHint=false) or whether repeated reinforcements stack.

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 well-formed sentence with the action front-loaded and the rationale trailing. 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 one-parameter tool with no output schema, the description conveys purpose and the observable effect, which is largely sufficient. The main omission is guidance on when this mutating call is warranted versus simply recalling or re-remembering.

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?

Only one parameter and schema coverage is 100%, so the schema fully documents 'id'. The description adds no format, sourcing, or lookup semantics for obtaining a valid memory id, 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?

Specific verb ('Mark...as confirmed or useful') plus resource ('a memory') and a stated effect ('so it decays more slowly'). The purpose is clear and distinct from remember/recall/forget, though no sibling is named to sharpen 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?

The phrase 'right now' hints at when to call it (at the moment the memory proves useful), but there is no explicit when-to-use vs when-not, no mention of forget/remember as alternatives, and no conditions for repeated invocation. Usage is only implied.

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 readOnlyHint=false and idempotentHint=true already declared, the description adds real behavioral value by explaining the merge/reinforce semantics for near-duplicates, which is exactly why the operation is idempotent. It does not say what permission or rate limits apply, but the added write-behavior context exceeds the annotations.

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 the core action and scope, then categories, then the dedup contract. No filler and no repetition of the title or 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 6-parameter write tool with no output schema, it covers purpose, content-writing guidance, and the merge contract. The one gap is that it never explains how an agent obtains the id needed by link_to, nor what the call returns.

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 a 3, but the description adds meaning for the content parameter ('write it self-contained, as if read months later without this chat'), which is guidance the schema does not provide. The other five parameters are left entirely to their schema descriptions.

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

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

States a specific verb and resource ('Store one durable fact') plus the scope ('available in future sessions'). It is clearly distinguishable from the sibling store/retrieve tools (recall, forget, reinforce) without opening any 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?

Gives explicit content categories to use it for (decisions and reasons, preferences, project facts, commands, gotchas, fixes) and a writing rule. It does not name the alternative tools or the when-not conditions (e.g., use forget to retract, recall to read), so it stops short of a full routing guide.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful ordering behavior (newest first) and the recorded event taxonomy, but says nothing about pagination limits in practice or the shape of a returned event.

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 tightly written sentences: the first front-loads what the log is and its ordering, the second supplies concrete query examples. 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 read-only listing tool with full schema coverage and strong annotations, the definition covers enough to call it correctly. The remaining gap is that the fields making up each timeline event are never described and there is no output schema, so the agent must discover the entry shape empirically.

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%, with tag, limit/default, scope enum, and since/until formats all documented in the schema itself. The description adds no syntax or interpretation beyond that, 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 states a concrete verb-like resource: a chronological log of memory events, newest first, and enumerates the event kinds it records (remembered, recalled, reinforced, linked, forgotten). That taxonomy is enough to separate it from siblings like recall or remember, though no sibling is named 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?

Concrete usage contexts are given via example questions ('what did we decide last week?', 'what did you look up this session?'), which tells the agent when this tool is the right choice. It stops short of stating when not to use it or naming an alternative sibling.

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