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

No annotations are provided, so the description carries the behavioral disclosure burden. It does add the key trait that memories persist 'across sessions' and clarifies that only worthwhile information should be stored. It does not disclose duplicate handling, response shape, size limits, or how memories are later retrieved.

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

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

A single, front-loaded sentence with no wasted words. It names the action, the resource, and the relevant content categories without repeating parameter mechanics.

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 schema fully documents all six parameters and the description establishes the persistence concept, which is enough for a basic add operation. Missing are details about the return value, potential duplicates or overwrites, and how stored memories should later be surfaced via memory_search or memory_bootstrap.

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 partly echoes the type enum and gives a content example, but it adds little beyond what the schema already provides for each parameter.

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: 'Store a memory'. It enumerates the exact content types (decision, rule, preference, fact) and is clearly distinct from retrieval and lifecycle siblings like memory_search, memory_clear, and 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?

The description implies when to use the tool: whenever there is a decision, rule, preference, or fact worth persisting. However, it does not explicitly state when not to use it or mention alternatives such as memory_bootstrap or memory_profile.

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 burden, and it delivers: it discloses the aggregation behavior (rules + preferences + recent + optional query matches), the ordering ('by importance'), and the optionality of semantic matching. It does not confirm side-effect-freeness or describe edge cases like an empty memory store, but 'load' clearly implies a non-mutating read, and the result composition is well conveyed.

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 zero waste: the first front-loads verb, resource, purpose, and result composition; the second is a terse call-to-action. Every clause earns its place, and no information 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 moderately complex aggregation tool with no output schema and no annotations, the description covers the essentials an agent needs to invoke it correctly: what it returns (result categories and ordering), when to call it (session start), and parameter control (schema-provided defaults). Minor gaps remain—return format is unspecified and edge behavior (empty store, overlap between recent and matches) is unaddressed—but the description compensates well for the missing structured metadata.

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 all four parameters with defaults inline. The description adds only marginal mapping value by tying the limit parameters to the result categories (rules/preferences, recent, query matches), which is helpful but not substantive new semantics. 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 opens with a specific verb and resource ('Load relevant memories') and a clear purpose ('to bootstrap a new session'), then enumerates exactly what comes back: top rules/preferences by importance, recent memories, and optional query matches. This composition distinguishes it from sibling memory_search (targeted retrieval) and the mutation/state tools (add/clear/forget), so an agent can tell them apart without opening schemas.

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 at session start' is explicit, crisp usage guidance that anchors when this tool applies. However, it does not mention exclusions or route to alternatives (e.g., 'for targeted lookups mid-session, use memory_search instead'), stopping one step short of the full when/when-not/alternatives standard.

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. It warns 'DANGER ZONE' and requires explicit confirmation, which is strong disclosure for a destructive action. It could more explicitly state irreversibility or lack of undo, but 'Wipe ALL' implies permanence. The description adds substantial context beyond the schema.

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 with zero waste. The purpose is stated first, followed by the critical safety requirement, then the alternative action. Information is front-loaded and each 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?

For a simple tool with one boolean parameter and no output schema, the description covers what, when, and safety. It lacks explicit mention of irreversibility or that all memory content is permanently destroyed, but the warning and 'Wipe ALL' cover the essential risks. A 4 reflects good completeness 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 coverage is 100% for the single boolean parameter, which already states 'Must be true to wipe.' The description reinforces this with 'requires confirm:true' but adds no new semantic detail beyond what the schema provides. 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 states the action ('Wipe ALL memories') with a specific verb and resource, distinguishing it from siblings like memory_search, memory_add, and memory_export. The scope 'ALL' makes the destructive nature obvious and separates it from more selective operations like 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?

Explicitly provides when-to-use guidance by mandating 'confirm:true' and suggesting 'memory_export first' as a safety alternative. This tells the agent exactly what is required before invoking and routes to a safer sibling when appropriate.

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. It discloses scope ('all memories') and formats, and the verb 'export' implies a read-only operation. It does not state whether the exported data is returned directly, whether files are created, or any side effects/limits.

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

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

A single, front-loaded sentence with no filler. Every word contributes: the verb, the scope, the formats, and the purpose.

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 export tool with one optional parameter and no output schema, the description covers what is exported, the formats, and the intended use case. It does not explicitly describe the return shape, but the behavior is predictable enough from the name and description.

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's mention of JSON or Markdown mirrors the schema enum and adds no new parameter-level meaning. The default value 'json' is only documented in the schema, not reinforced here.

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 ('Export'), a clear resource ('all memories'), and specifies the output formats ('JSON or Markdown') and purpose ('backup or portability'). This clearly distinguishes it from sibling tools like memory_search, memory_add, and memory_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 phrase 'for backup or portability' gives clear context for when this tool is the right choice. However, it does not explicitly state when not to use it or name alternatives, so the agent must infer the decision from the tool names.

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 description discloses a critical behavioral trait: dry-run by default, requiring confirm:true to actually delete. This is valuable safety-relevant context beyond the schema. It also clarifies that query-based removal uses semantic matching. However, it doesn't mention what happens to related data, whether deletion is reversible, or what the dry-run output looks like, but the core safety behavior is well 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?

One sentence, front-loaded with the primary action, and the safety-critical dry-run behavior is included compactly. Every word earns its place; 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 deletion tool with no annotations and no output schema, the description covers the essential safety behavior (dry-run default, confirm flag) and the two deletion modes. It could be more complete by describing the dry-run output format or clarifying that id and query are mutually exclusive, but the core information an agent needs to avoid accidental deletion is 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. The description adds the crucial semantic that confirm gates actual deletion and that query removal is semantic, but it doesn't add detail beyond the schema for min_similarity or id. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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 ('Remove') and resource ('specific memories'), and distinguishes two modes: by id or by semantic query. It also clearly signals the dry-run default, which differentiates it from sibling tools like memory_clear (which likely removes all memories) and memory_search (which only retrieves).

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 this tool: when you need to delete specific memories by id or by semantic query. It doesn't explicitly name alternatives or exclusions, but the dry-run default and confirm flag provide clear operational guidance. Sibling names like memory_clear and memory_search make the context understandable, though explicit when-not-to-use guidance would be stronger.

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. The 'Show' verb implies a read-only, presentational operationositories, and the description adds what output is included. However, it does not explicitly state side-effect freedom, performance considerations, or output limits.

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 terse sentences: the first describes behavior and output content, the second gives a direct trigger. There is no filler, repetition, 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 zero-parameter, no-output-schema tool, the description gives the essential information: what the profile contains, how it is grouped, and when to use it. It could be slightly more explicit about the exact output format, but nothing critical 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 syntax and meaning of arguments are a non-issue. The empty schema already provides complete structural coverage, and the description adds no unnecessary param explanation; baseline 4 applies.

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

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

Description states a specific verb ('Show') and resource ('full memory profile'), adding grouping by topics and counts by type and topic. It clearly differentiates from siblings like memory_search (targeted lookup) and memory_status by emphasizing the full, topic-grouped profile.

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

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

Explicitly maps to the user question 'what do you remember about me?', giving an agent a clear trigger condition. It does not list when-not-to-use it or name sibling alternatives explicitly, so routing to alternatives remains slightly implicit.

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

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

With no annotations, the description carries the full burden, and it discloses real behavioral specifics: local TF-IDF cosine similarity, recency and importance boosts, and that it searches rather than mutates. It does not describe return format or edge cases, but the search behavior itself is unusually well specified.

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 resource, then packs in the algorithm and ranking factors without wasted words. Every phrase 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 two-parameter search tool with a complete schema, the description covers the core behavior and ranking logic well. The only notable absence is the output shape, since there is no output schema to fill that gap, but an agent can reasonably infer that matching memories are returned.

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 documents both parameters at 100% coverage, so the baseline is 3. The description adds meaning by clarifying that 'query' should be a semantic/free-form expression and that result ordering is influenced by recency and importance, which the schema does not state.

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 ('Semantic search') and a clear resource ('stored memories'), and the algorithmic qualifiers make the tool distinct from sibling memory-management tools such as memory_add or memory_clear. An agent can tell this is the retrieval/query tool 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 clearly implies when to use it: whenever the agent needs to retrieve previously stored memories semantically. It does not explicitly name alternatives or exclusions, so it stops short of a 5, but the context is strong enough that the agent would not reach for memory_add or memory_forget.

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 'Service health' implicitly conveys a read-only, non-mutating operation plus what the report covers. However, it does not explicitly state that no state is modified, whether authentication is required, or any failure/error behavior.

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 compact sentence that front-loads the core purpose ('Service health') and packs the key report contents into a tight list. Every word earns its place 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?

For a zero-parameter tool with no output schema, the description does well by naming what the health report includes, effectively substituting for return-value documentation. The only real gap is ambiguity in 'counts' (counts of what?), but overall an agent can call this tool correctly with no further information.

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 baseline is 4 per the rubric. The description confirms this with 'No parameters,' which matches the empty input schema exactly; there is nothing more to add.

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 reports service health and enumerates its scope (storage path, counts, search backend, version). The purpose is distinct from its operation-oriented siblings like memory_add and memory_clear, though it never names them or explicitly positions itself against 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?

There is no guidance on when to call this tool versus alternatives, no prerequisites, and no indication of ordering (e.g., checking health before other memory operations). The phrase 'No parameters' merely restates schema information rather than providing use-case guidance.

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