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

The annotations already declare destructiveHint: true, readOnlyHint: false, and idempotentHint: true, so the behavioral safety profile is covered by structured metadata. The description itself adds no extra behavioral detail about permanence, error behavior, or side effects, but it also does not contradict 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?

The description is a single, front-loaded sentence with no filler. It names the operation, target, and parameters compactly, earning its place without 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 two-parameter destructive operation with useful annotations already present, the description is largely complete. It could mention what the tool returns or what happens when the memory does not exist, but the simplicity of the operation makes the absence a minor gap rather than a significant one.

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 both parameters adequately: id is a UUID and type is an enum of project/preference/learning. The description repeats the 'type and ID' concept but contributes little beyond what the schema already provides.

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 ('Delete') and resource ('memory') and identifies the exact identifier needed: type and ID. It clearly stands apart from the sibling save/get/search/list tools, which are all non-destructive operations.

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 intended use is clear: call this when a specific memory should be removed using its type and ID. It does not explicitly name alternatives or exclusion cases, but the delete action is unambiguous enough that an agent can readily infer when to invoke it.

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?

Annotation shows this is a mutating, non-idempotent, non-destructive operation. The description adds what kinds of learning should be captured without claiming destructive effects, but it does not disclose whether repeated calls create new records or overwrite existing ones.

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 short, dense sentence carries all the essential purpose and content guidance. No filler, no repetition of schema information, and the central action verb is front-loaded.

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 fully documented parameters, and the annotations declare the mutating but non-destructive custom strength. With no output schema, the description does not need to explain return values; the one meaningful gap is explicit caller guidance for distinguishing this tool from memory_save.

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 each parameter already has a meaningful description. The tool description provides illustrative examples of what the content might include, but it does not add additional semantic constraints 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 uses the specific verb 'Record' on the resource 'session learning' and includes concrete content examples such as solutions, bugs, and insights. It is clear and distinct from sibling save tools for projects/preferences, though it does not explicitly name an 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?

The sentence signals when to use it: after a session a learning should be recorded. The domain terminology and sibling set make the intended use obvious, but there is no explicit when not to use this tool or a named 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?

The annotations already convey readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral detail about which fields are matched, but it does not disclose result shape, ordering, or whether matches are partial/exact.

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 short sentences with no wasted words. The purpose is stated immediately, and the matching scope follows naturally, making it easy to scan and apply.

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 read-only search tool with all parameters documented in the schema, the description is largely sufficient. The main gap is the lack of return-format information, but for a search tool this is fairly 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%, providing a baseline of 3. The description adds that query matches title, content, and tags, which is helpful, but it does not add meaning for limit or project_name beyond what the schema already provides.

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 clear verb and resource ('Search session learnings by keyword') and adds the scope of matches ('title, content, and tags'), which tells an agent exactly what the tool operates on. It does not explicitly distinguish this from the sibling memory_search tool, but 'session learnings' gives enough specificity.

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 scope 'session learnings' makes the intended use fairly clear, but the description does not explicitly say when to prefer this over memory_search or when not to use it. The usage context is implied rather than directly 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?

Annotations already declare the tool read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context by mentioning optional type filtering, pagination, and stats, which go beyond the schema and clarify 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?

The description is a single efficient sentence with the main action front-loaded and optional capabilities listed compactly. Every phrase carries useful information and there is 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 tool with no required parameters and fully documented input parameters, this is a sufficient definition. The main gap is that "stats" is not explained and the response payload is not described, but the high schema/annotation coverage keeps the description 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?

Schema coverage is 100%, so all three parameters are already documented in the input schema (type, limit, offset). The description's mention of "type filter" and "pagination" adds only general framing—it does not provide meaningful detail beyond what the schema already states.

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 action ("List"), a clear resource ("all stored memories"), and the key optional capabilities (type filter, pagination, stats). It is easily distinguishable from save/get/delete/search siblings, though it does not explicitly contrast with the type-specific list siblings such as memory_project_list.

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 "all stored memories" with an optional type filter implies this is the general listing tool, but it does not explicitly say when to use this tool instead of memory_search or the type-specific list tools. The intended usage is inferable, but not clearly 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no further behavioral detail (e.g., missing-key behavior, return format), but it does not contradict 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 a single, front-loaded sentence: 'Retrieve a specific preference by key.' It contains the essential verb, resource, and scoping detail with zero 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?

Given the tool's low complexity—one required parameter, full schema coverage, and readOnly/idempotent annotations—the description is enough to guide correct invocation. The return format is not detailed, but for a simple get-by-key operation the return can be reasonably inferred as the preference.

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 only parameter 'key' is described as 'Preference key to retrieve'. The description's phrase 'by key' restates the schema rather than adding new meaning, so it meets the baseline without exceeding 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 states a clear action and resource: 'Retrieve' a specific preference by key. This distinguishes it from list or search siblings by emphasizing a single preference and key-based lookup, though it does not explicitly name related alternatives.

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 context is implied rather than explicitly stated: use this tool when you know a preference key and want its value. No explicit when-to-use versus sibling tools like memory_pref_list or memory_pref_save is provided.

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 readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds the scope 'all saved preferences' and the optional category filter, but it does not disclose behavior such as pagination, ordering, or return format. This is acceptable but not rich.

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 with no filler. It front-loads the core action and resource, then adds the optional qualifier. Every part is necessary.

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, read-only list tool with one optional parameter, full schema coverage, and no output schema, the description is complete enough for an agent to understand when to call it and what it does. No critical call-time information appears to be 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 input schema already covers the only parameter, category, with 'Filter by category,' and schema description coverage is 100%. The description adds no additional meaning about format, allowed values, or behavior of the category 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?

Description states a specific operation ('List') and resource ('saved preferences'), and notes the optional category filter. This is enough to distinguish it from siblings like memory_pref_get, memory_pref_save, and memory_list.

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 clearly conveys that the tool lists preferences and may filter by category, but it does not explicitly contrast it with alternatives such as memory_pref_get for a single preference or memory_list for non-preference memory entries. Usage is mostly implied rather than 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?

Annotations already provide idempotentHint=true, destructiveHint=false, so the description does not contradict and needs less behavioral detail. It adds that the operation can 'update' an existing preference, but does not explain overwrite visibility, validation, or persistence behavior beyond that.

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 one focused, front-loaded sentence with no redundant wording or unnecessary examples. It reads quickly and tells an agent what the tool does in one pass.

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 save tool with no output schema, the description plus schema are mostly sufficient. The only real gap is the lack of explicit 'when to use this over sibling memory tools' guidance, but most of the structural needs are covered by the schema.

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?

Input schema coverage is 100%, with meaningful descriptions for key, value, and category. The description only reinforces those domains without adding new parameter-specific guidance beyond what the schema already states. 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 uses a specific verb ('Save or update') and names the resource ('personal coding preference') with illustrative examples ('style, tools, workflow patterns'). This clearly separates it from project or learning memory tools and makes its purpose immediately 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?

The description implies the tool is for personal coding preferences but does not explicitly state when to use it over generic memory_save or other sibling tools. No when-not conditions or alternative routing is provided, so guidance is limited.

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, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond what the title and annotations already imply; it does not mention error cases, missing project behavior, or any side effects.

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, no filler, and the core action is front-loaded. Every word contributes to understanding the purpose and input.

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 a simple single-parameter read-only getter with complete schema and annotations. The description is sufficient for an agent to call it correctly. It does not describe the response shape or not-found behavior, but these are minor given the tool's simplicity and lack of output schema.

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 'name' parameter is fully documented as 'Project name to retrieve'. The description only restates this as 'by name' and adds no additional semantic detail, so it meets the baseline without meaningfully extending 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 clear verb ('Retrieve'), a specific resource ('saved context for a specific project'), and a selection criterion ('by name'). It clearly differentiates this from memory_project_list (all projects) and memory_project_save (write operation), so an agent can distinguish it 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?

The description implies usage when you need a single project by name, but it does not explicitly state when to use this tool versus siblings like memory_project_list or memory_project_save. There is no explicit when/when-not guidance or reference to alternatives, so the guidance 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?

The annotations already declare read-only, idempotent, and non-destructive behavior, so the description need not repeat safety semantics. It adds 'all saved projects' as scope, but stops short of documenting output shape, ordering, or pagination; given the annotation coverage, this is acceptable but not rich.

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 entire description is one clear sentence with no filler. It is appropriately sized for a simple, parameterless listing tool and front-loads the action 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 zero-parameter, read-only operation, the schema and annotations supply most of the necessary context. The absence of an output schema leaves return values slightly underspecified, though 'list' strongly implies a collection, so the gap is minor.

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 input schema has zero properties and 100% schema description coverage, so there are no parameters to document. This matches the baseline expectation: the description adds nothing more than 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?

The description uses a specific verb ('List') and identifies the exact resource ('all saved projects'), making the tool's purpose unmistakable. The 'projects' scope also distinguishes it from memory_pref, memory_learning, and the generic memory tools 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?

No usage guidance is provided about when to choose this tool over the many alternatives. Only an implicit use case exists—listing projects—with no mention of exclusions or conditions.

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 establish that this is not read-only, is idempotent, and is not destructive. The description adds some useful nuance with 'save or update', indicating an upsert-like behavior, but it does not disclose whether updating an existing project merges fields, overwrites them, or handles omitted fields in a particular way.

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 efficient sentence with the key action and resource front-loaded. Every word earns its place; no repetition, filler, or unnecessary abstraction.

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 description is reasonably complete for a simple parameter-rich, schema-covered save operation, especially with idempotentHint available. However, the lack of update semantics details, such as whether existing fields are merged or replaced, and the absence of any mention of path or project identity behavior, leave some ambiguity for an agent making corrective updates.

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 input schema already documents name, path, notes, tech_stack, conventions, and architecture. The description only re-lists a few of those fields at a high level and does not add meaning beyond what the schema already provides. This maps to the baseline of 3.

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 has a specific action ('Save or update') and a clear resource ('project context'), plus an explicit list of the stored content areas: tech stack, architecture, conventions, and notes. The 'project' framing distinguishes this from sibling memory tools such as memory_pref_save, memory_learning_save, and general memory_save.

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 'project context' wording implies this tool is for project-specific memory rather than preferences or learnings, but it does not explicitly say when to choose this tool over memory_save, memory_project_get, or other siblings. There are no alternatives, caveats, or when-not-to-use conditions 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?

Annotations already signal this is not read-only, not idempotent, and not destructive, and the description complements them by explaining that the tool automatically routes to the correct table, which is behavior beyond the schema. It does not detail overwrites/conflict behavior, but the annotations give baseline coverage and the description adds useful routing context.

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. The purpose and routing behavior are front-loaded, and the per-type field mappings are compact enough to be quickly scanned and acted 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?

For a save/routing tool with only two parameters, it covers what types are accepted, which fields apply, and the automatic routing behavior. A return-value mention would be helpful, but the absence is not surprising for a save operation without an output schema, and siblings provide more specialized endpoints if finer detail is needed.

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 'type' and 'data', and the description meaningfully enriches 'data' by enumerating valid field groups per type: project, preference, and learning. It doesn't specify required vs optional field semantics, but it gives an agent the key content expectations that the schema leaves open.

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 ('save') and a clear resource, and underscores its distinct role by calling itself a 'Unified save' that routes to the correct table based on type. This makes it easy to distinguish from the per-type sibling tools such as memory_project_save and memory_learning_save.

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 communicates how to use the tool: provide a type and data matching that type, and it lists the expected fields for each type. It lacks an explicit 'use this instead of X when...' statement against the sibling tools, but the 'Unified save' framing gives enough context for an agent to infer this is the central routing 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds no behavioral details beyond the read-only search scope—no mention of result formatting, matching behavior, pagination, or sort order, which would add transparency beyond 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?

The description is a tight two-sentence construction with no fluff. The core behavior and modifier (optionally filter by type) are front-loaded. Every word carries semantic value.

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 search with only three documented parameters, full schema coverage, and safety-bearing annotations, the description provides a solid orientation. There is no output schema, but 'Search' implies returning matching memories; a few returned details like sorting or whether type filtering applies to all types could be more explicit, but the current description is sufficient for the listed 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?

Full 100% schema description coverage exists. The schema already explains query='Search query', type filter enum, and limit. The description mainly restates 'keyword' and the type enum values, adding no meaning beyond the schema. 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 ('Search'), the resource ('all memory types'), and the optional filter dimension (by type). It differentiates this tool from memory_type_save/get/list siblings and even from memory_learning_search because the scope is explicitly global, not type-specific.

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 a clear context: use it for keyword search across memory types, optionally filtering by type. However, it does not explicitly say when to choose this over the type-specific memory search siblings (e.g., memory_learning_search) or when not to use it. Usage is implied rather than directly stated.

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