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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered, but the description adds genuine behavioral context: result counts are capped, bodies are clipped rather than complete, and results span the given scope plus global. That clipping/cap behavior is exactly the kind of trait annotations cannot express.

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: the use-case framing and result composition come first, followed by the clipping caveat and the alternative tool. Every clause carries information, though the parenthetical count list, while informative, makes the sentence dense.

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

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

An output schema exists so return structure need not be explained, yet the description still usefully previews contents and limits. For a one-parameter, non-destructive aggregation tool, the only real gap is the default/null scope behavior.

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 single scope parameter has 0% schema description coverage, so the description must carry the burden. It clarifies that results include the given scope plus global memory, which is real added meaning, but it never explains what happens when scope is null (the default) or what a valid scope value looks like.

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 specifies exactly what the tool returns (top preferences up to 8, procedures 6, strongest facts 5, recent episodes 3) and routes to the sibling memory_get for full bodies, so it is distinguishable from other memory tools. It lacks an explicit verb ("retrieve"/"summarize"), framing the purpose as contents rather than an action, which keeps it just 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?

"What to know before starting work" gives a clear situational context, and it explicitly names the alternative memory_get with the condition for using it (when full bodies are needed). It does not distinguish itself from memory_recall or memory_list, so the when-not guidance is partial rather than complete.

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 destructiveHint=true and readOnlyHint=false. The description reinforces this by emphasizing 'Permanently' and enumerating the artifacts destroyed, which adds useful consequence context beyond the boolean. It doesn't cover auth or reversibility guarantees, hence a 4.

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, front-loaded with the destructive nature and the usage gate; nothing wasted.

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

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

Output schema exists, so return values needn't be explained, and the safety profile is covered by annotations. The main missing piece is what the id refers to and how to find it before calling a destructive operation.

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

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

One parameter 'id' with 0% schema description coverage, so the description must compensate—and it doesn't mention what the id is (file id, graph id, memory id?) or how to obtain it. This is a real gap for identifying the target object.

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?

'Permanently delete a memory' states a specific verb and resource, and the parenthetical enumerates exactly what gets removed (file, graph, archived copy, index), distinguishing it from read siblings like memory_recall and memory_get.

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 qualifier 'Only when the user asks to forget something' gives a clear gate on when to use it, effectively signaling when-not. It doesn't point to a specific alternative, but the constraint is actionable.

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 and openWorldHint=false, so the safety profile is covered. The description adds that the payload includes metadata and the graph, which tells the agent the response is heavier than a brief lookup, but it says nothing about permissions, missing-id behavior, or traversal cost.

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

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

A single short fragment with no filler, and the key scope word ('One') is front-loaded. It is a sentence fragment lacking a verb, which slightly undercuts readability but not efficiency.

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

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

An output schema exists, so return values need not be explained, and the tool is a simple one-parameter lookup. However, with 0% schema coverage on the id and no usage routing among seven siblings, the definition is only minimally 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 0% and the single 'id' parameter carries no description in the schema. The description only implies 'one memory' is identified by something; it never states the identifier format (UUID, slug, composite) or whether a missing id errors or returns null.

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 phrase 'One memory in full, with its metadata and graph' names a specific resource and scope (a single memory), which distinguishes it from list/brief siblings by implication. It never names a sibling explicitly, so an agent must infer the boundary with memory_list or memory_recall rather than being told.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the seven sibling tools. The agent is left to guess that this is the 'fetch by id' path rather than a search path.

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 and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: results are ordered newest first and the scope implicitly includes global memories. It does not mention pagination or what happens when no scope is supplied.

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 plus a fragment, with the core behavior front-loaded and no filler. The 'status: active | provisional' fragment is telegraphic rather than a clean sentence, but it earns its space by documenting an undocumented enum-like parameter.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Still missing for a 4-parameter tool: the meaning of 'kind', the limit/pagination behavior, and any routing guidance among the seven sibling memory tools.

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

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

Schema description coverage is 0%, so the description must carry the load. It explains 'scope' (includes global) and 'status' (active | provisional), but 'kind' and 'limit' are left entirely undefined in both the schema and the description.

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

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

States a specific verb and resource ('List memories'), scopes it ('of a scope (plus global)'), and specifies ordering ('newest first'), so the operation is unambiguous. It stops short of differentiating itself from siblings like memory_recall or memory_get, which an agent must infer from the name 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?

Gives one explicit trigger: 'Use when the user asks what you remember.' That is clear context, but there are no exclusions or pointers to alternatives, and it overlaps conceptually with memory_recall and memory_get without explaining which to pick.

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, so the trailing 'Read-only' is largely redundant. What the description does add is genuine behavioral context beyond the annotations: the ranking is hybrid keyword/vector/graph, results are ordered best-first, and matched results carry the signals that surfaced them, plus the non-obvious default that 'kinds' excludes trace.

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?

Five tight sentences, no filler, and the core capability is front-loaded before the per-parameter notes. Every clause carries information an agent can act on.

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

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

An output schema exists, so return-value detail is unnecessary, and the description's note about best-first ordering is sufficient. But for a 5-parameter tool with 0% schema description coverage, leaving k, scope, and include_provisional entirely undefined is a real completeness gap.

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

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

Schema description coverage is 0%, so the description carries the full parameter burden, and it only partially does: it explains what to put in `query` (task/question phrasing, including file/tool/project names) and the default behavior of `kinds`. The three remaining parameters (k, scope, include_provisional) get no explanation anywhere.

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 memory') plus the retrieval mechanism ('hybrid keyword + vector + graph ranking'), which separates it from get/list/brief siblings at a glance. It stops short of naming an alternative explicitly, so a 4 rather than 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?

Usage is implied by the query guidance ('a short description of the task or question'), which tells the agent what kind of input fits. However there is no explicit when-to-use vs when-not, and nothing routes the agent between recall and memory_get, memory_list, or memory_brief.

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 only declare the mutation/safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false); the description goes beyond them by disclosing the actual state changes — confidence increase, decay reset, provisional activation. It does not explain whether repeated calls stack confidence or what happens to an already-active memory, which would be the remaining behavioral 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?

A single sentence that leads with the trigger condition and then the effects. No filler, no repetition of the tool name, nothing to cut.

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

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

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description covers the observable effects well; only the unidentified id parameter and idempotency/stacking behavior leave a small gap.

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?

There is a single required parameter, id, with 0% schema description coverage, and the description never mentions it — not what a memory id looks like, nor where to obtain one. The description fails to compensate for the schema gap, so this sits below the 3 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 names the operation (reinforce a memory) and spells out three concrete effects: raises confidence, resets decay, activates if provisional. It is clearly distinct from memory_recall/remember/forget in substance, but it never explicitly names or contrasts a sibling tool.

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 opening clause 'A memory was confirmed or proved useful' implicitly states the triggering condition, which is real usage context. However, it offers no explicit when-to-use vs. when-not guidance and never routes the agent to or away from alternatives such as memory_remember or memory_recall.

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

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

Annotations already cover the safety profile (readOnly=false, destructive=false, openWorld=false), so the bar is lower, and the description adds real behavior: near-duplicates reinforce instead of creating a new memory, description defaults to the first line, and contradicts replaces an existing memory. It omits what happens on write failure or how the returned id is used.

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?

Front-loads the core action, then uses compact per-field clauses with no filler; every line maps to a parameter or behavior. It is dense and list-like but appropriate for an 11-parameter tool.

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

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

With an output schema present, return values need not be described, and the description compensates well for 0% schema coverage by documenting most fields and the dedup/replacement behavior. The unaddressed name, scope, and confidence parameters keep 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 0%, so the description carries the full burden and does most of it, defining kind values, content expectations, description, provisional, contradicts, entities (with allowed types), relations (with allowed rel values), and source. However, three parameters (name, scope, confidence) are never explained, leaving a real 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?

Opens with a specific verb+resource ('Store one memory') and enumerates the kind taxonomy, so the agent knows exactly what is being written. It does not explicitly contrast with the closest sibling memory_reinforce, though the near-duplicate note gestures at it.

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 rather than stated: the kind list and the 'provisional: true when inferred rather than stated' note hint at when to write, but there is no explicit when-to-use/when-not or routing to memory_recall/memory_forget. Adequate but leaves the agent to infer intent.

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 and openWorldHint=false, so the safe-read profile is covered. The description adds useful context about what the stats include (scope/kind/status counts, storage location, vector-search status), but since an output schema exists this is largely a peek at return values rather than deep behavioral disclosure.

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 terse sentence with semicolon-separated facets and no filler; the most important element (counts per scope/kind/status) is front-loaded. It is a noun-phrase fragment rather than a full clause, but nothing is wasted.

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

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

For a zero-parameter, read-only stats tool with an output schema present, the description need not detail return format. It covers what the tool reports and its safety profile implicitly via annotations, leaving only usage routing unaddressed.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about inputs, and schema coverage is trivially 100%.

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 resource (memory statistics) and enumerates the dimensions counted: per scope, kind, and status, plus storage location and vector-search state. It is clearly distinct from siblings like memory_recall, memory_list, or memory_remember, though it does not explicitly name any 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?

No when-to-use guidance is given beyond the implicit fact that this is a stats/inspection tool. There is no mention of prerequisites, when to prefer it over memory_list or memory_brief, or any exclusions.

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