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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: the payload comes back as text, it is capped by a server-side export byte limit, and segments are chained via cursor — exactly the truncation semantics an agent must know. No contradiction with 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?

Front-loaded with the verb, resource, and formats, followed by the sibling alternative and the pagination note, with no filler. It is dense — three distinct points packed into two sentences — but 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?

An output schema exists, so return-value details need not be explained, and annotations handle the safety profile. Between the description and schema, formats, byte cap, and cursor continuation are all covered; only snapshot consistency across segments is left implicit.

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 every parameter (tag, limit, cursor, format, prefix) is already documented in the schema, and the description mostly restates the format enum and the cursor/next_cursor relationship. Baseline 3 applies when the schema does the heavy lifting; the description adds little syntax or edge-case 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?

States a specific verb and resource ("Read a portable snapshot of memory contents") plus the three serializations produced. It explicitly differentiates from the `list` sibling by naming it as the short-preview alternative, so an agent can route without opening either 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 one explicit exclusion with a condition: use `list` for short previews instead. It also explains the continuation path ("pass `next_cursor` as `cursor` to continue"). It does not address when to prefer export over `get`, `recall`, or `search`, so it stops short of full when/when-not coverage.

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 and idempotentHint, so the description's added value is the confirm gate for prefix deletion and the note that the tool reports deletion count plus absent ids. That is genuine behavioral context the annotations do not carry; it stops short of stating irreversibility or how partial failures are handled across a 1000-id batch.

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 dense sentence front-loads the action and selection modes, then the alternative, the pre-check, and the return contract follow in order. Every clause carries information; nothing is 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?

With a destructive, no-required-param tool and an output schema, the description covers the destructive scope of prefix deletion, the confirmation requirement, the recommended inspection step, and the sibling to use instead. An agent can call this correctly without further reading.

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

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

Schema description coverage is 100% and the schema already documents the id/ids/prefix mutual exclusion and the confirm flag, so the description is largely restating it. It does tie `confirm` to the prefix mode operationally, but adds no new syntax or edge-case semantics (e.g. calling with no selector at all, where all params are optional).

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 ("Delete") plus resource ("memories from the active store") and names the three selection modes (id, ids, prefix). It also routes away from a sibling by naming `remember` for the update case, so the tool is distinguishable without inspecting the schema.

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

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

Explicitly names the alternative for the adjacent use case ("use `remember` to update content instead") and gives a precondition/ordering rule ("Inspect prefix matches with `list` first"). It also states the gate condition for the risky path (prefix deletion requires `confirm: true`), leaving nothing 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?

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context by stating that an unknown id returns an error, though it repeats the read-only trait already covered by 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?

The description is three compact sentences with no wasted text. The core operation is front-loaded, followed by sourcing and alternative guidance.

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 one-parameter read tool with rich annotations and an output schema, the description is complete. It covers the operation, id source, alternative tool, and error behavior for unknown ids.

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 the `id` parameter is fully documented in the schema as the exact id returned by `remember`, `list`, or `search`. The description reinforces the id provenance but adds little parameter-level 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 states a specific verb and resource: reading one known memory id in full. It also names included fields and explicitly differentiates this from `recall`, `list`, and `search`, so an agent can distinguish it from siblings without opening the schema.

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

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

It gives explicit sourcing guidance: use an id from `list` or `search`, and use `recall` when only a natural-language question is known. This directly covers when to use this tool versus a key alternative.

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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds useful behavioral detail beyond that: results are in id order, previews are returned unless `full` is true, and pagination continues by passing `next_cursor` as `cursor`.

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?

It is a single dense sentence with zero filler, front-loading the core operation and ordering before alternatives and return behavior. Every clause carries operational information.

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 tool is simple, has full schema coverage, has output schema support, and has clear annotations. The description still covers ordering, filtering, preview-vs-full behavior, pagination, and the sibling alternative, so nothing important is missing for correct invocation.

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

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

Schema description coverage is 100%, and the schema already documents tag, full, limit, cursor, and prefix in detail. The description reinforces the important filter and pagination semantics but largely restates what the schema provides, so 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 states a specific verb and resource ('Browse memories') plus the ordering ('id order') and filtering options ('id prefix or tag'), and explicitly contrasts this with `search` for relevance ranking. An agent can distinguish it from siblings without opening the schema.

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

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

It gives explicit routing: use this tool for browsing in id order, and use `search` when relevance ranking is needed. That is the key alternative among the listed sibling tools, and the condition for choosing it is stated directly.

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 read-only, idempotent, closed-world, non-destructive, so the safety bar is met elsewhere. The description still adds genuine value by disclosing that ranking is lexical by default and becomes semantic when a model is configured, which explains why identical queries may order results differently across deployments.

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, zero waste, with the core purpose front-loaded before the sibling routing and the behavioral note. Nothing is repeated from the title or schema.

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?

Rich annotations, a full-coverage schema and an output schema mean the description need not explain return values. It covers purpose, routing and ranking behavior, but the mismatch between 'use `search` for metadata filters' and this tool's own `tags`/`min_score` params leaves a small ambiguity an agent must resolve.

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 `k`, `tags`, `query` and `min_score` are already fully documented with bounds and defaults. The description adds no per-parameter meaning beyond a general mention of ranking, 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?

States a specific verb and resource ('retrieve full memories') plus the ranking model ('ranked for a natural-language question'), which precisely distinguishes it from `search`. An agent can tell the two apart without opening either 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?

Explicitly routes the agent: 'use this for ordinary recall; use `search` when you need metadata filters, ranking controls or score details.' However, the boundary is muddied because this tool's own schema exposes `tags` (a metadata filter) and `min_score` (a ranking control), so the stated exclusion is not fully consistent with what it accepts.

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 flag destructiveHint=true, and the description supplies the reason an agent needs: supplying an `id` overwrites that memory, omitting it creates a new one. It also discloses the two opt-in guards against clobbering. It stops short of saying what happens to fields not supplied on replace, but that is the only meaningful 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?

Two sentences, both load-bearing: the first establishes scope and the sibling routing, the second covers id semantics and the two guard parameters. The most decision-critical fact (replace vs create) is front-loaded after the routing hint.

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 the schema documents all eight parameters including tags, title, metadata and limits. The description fills the remaining conceptual gap – overwrite behavior and concurrency guards – so an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above baseline by explaining the interaction between `if_version` and `create_only` as a pair of mutually exclusive conflict strategies, rather than just restating the per-field definitions. It adds intent, not syntax, which the schema already handles.

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 (store) plus the resources it stores (durable fact, decision or preference), and explicitly routes the agent away from the sibling `recall`. The create-vs-replace distinction makes the operation unambiguous even before opening the schema.

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

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

Names the alternative tool explicitly ('use `recall` to find one instead') and gives the conditions that select the two conflict-control modes: `if_version` for concurrent-change rejection, `create_only` for overwrite rejection. Nothing about when-to-use is left to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive, so the bare 'Read-only' sentence earns no credit. The description does add real behavioral context beyond the annotations: results are previews with relative ranking scores that are not probabilities, and semantic scoring requires a configured model. These are useful operational caveats, though the preview/pagination details are partly redundant with the output 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 compact sentences with zero filler, front-loading the core purpose before alternatives and output caveats. Every clause carries a distinct instruction.

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 8 parameters, rich annotations, and an output schema, an agent has everything needed: purpose, sibling routing, and the key caveat that scores are relative not probabilistic and that semantic ranking requires a model. Nothing essential 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 coverage is 100%, so every parameter including `k`, `tags`, `fusion`, `min_score`, and the weights is already documented. The description adds only the semantic-weight model requirement, which the schema also states; otherwise it does not add syntax or fusion guidance beyond structured fields, 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?

The description opens with a specific verb and resource ('Find memories with metadata filters or ranking controls') and explicitly contrasts itself with `recall` for simpler full-text answers and `get` for full reads. An agent can distinguish this tool from its siblings 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?

It names both alternatives and the conditions that select them: `recall` when you want simple full-text answers, `get` when you need a result in full. This is explicit routing, not implied usage.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context — that no memory contents are exposed — which matters for a stats endpoint. It stops short of noting cost or latency, but nothing essential is missing.

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, both earning their place: the first defines scope, the second defines the read-only nature and the alternative. Front-loaded with the resource list before the routing hint.

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 needn't be spelled out; combined with annotations covering safety and a zero-parameter schema, the description supplies everything an agent needs to select and invoke 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The listed fields describe the output rather than inputs, which is harmless.

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 ('Inspect') plus an enumerated set of resources (counts, recall mode, encryption status, storage size, active limits). It also distinguishes itself from the sibling `list` by clarifying it does not read memory contents.

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 routes the agent: use `list` to inspect stored memories, implying this tool is for store-level metadata only. The when-not-to-use condition ('without reading memory contents') is stated up front.

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