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

With no annotations, the description carries the burden. It states the action (merge) and the criterion (similarity threshold), but doesn't disclose potential side effects (e.g., how merging affects importance, whether data loss occurs, or if it's reversible). This is a moderate gap for a mutation tool.

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, concise, and the purpose is front-loaded. No fluff, but noting the threshold could be slightly more explicit, though it's in the 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?

Given no output schema and moderate complexity (7 parameters), the description is adequate but doesn't explain the return value (e.g., what dry_run returns). It's missing details on how merges affect memory integrity, which could be important for selection.

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 parameters are documented. The description doesn't add much beyond the schema, except that it clarifies the overall purpose. Baseline 3 is appropriate as the schema does the heavy lifting.

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 merges similar or duplicate memories to reduce redundancy, which is a specific action on a resource. However, it doesn't explicitly differentiate from siblings like 'forget' or 'decay', though the context is unique enough.

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: when there are similar or duplicate memories. It doesn't explicitly mention when not to use or alternatives, but the context is clear that this is for reducing redundancy, which is distinct from forgetting or decaying memories.

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

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

With no annotations, the description carries the transparency burden. It communicates a discovery-style behavior ('Find', 'Discovers') and defines what a bridge is, but it does not explicitly state that the operation is read-only, describe side effects, or mention any behavioral caveats beyond what the schema already encodes.

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 front-load the main action and then explain the bridge concept clearly. There is minor redundancy between 'cross-namespace bridges' and 'memories in different namespaces,' which keeps it from a perfect score.

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 definition is adequate for a simple read-only discovery tool: purpose is clear, parameters are fully described by the schema, and the return concept ('bridges') is explained. It lacks richer context only in that it gives no output-structure details and does not relate this tool to sibling discovery 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 100%, so the schema fully documents max_bridges, min_similarity, namespace_filter, and _agent_id. The description adds no parameter-level detail, which is acceptable under the baseline for full schema coverage.

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 ('Find') and resource ('cross-namespace bridges in the memory corpus'), then clarifies the semantics: semantically similar memories across namespaces, flagged as potential links or duplicates. This scope distinguishes it from sibling tools like nearby or recall.

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 core use case is inferable: use this when you want cross-namespace semantic links or duplicates. However, there is no explicit guidance about when to prefer this over sibling tools such as discover_connections or recall, and no when-not-to-use 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?

With no annotations, the description carries the full burden. It clearly states the core effect (decay reduces importance for stale memories) but omits critical behavioral traits such as the dry_run default (default true means calls preview rather than apply), mutation side effects, and whether changes are reversible. The description adds some context but not enough for safe invocation.

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

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

Two tightly written sentences with zero redundancy. The main action and resource are front-loaded, followed by a clarifying consequence. Every word 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?

Given 8 parameters, no output schema, and no annotations, the description is too sparse. It omits when to use the tool, what a dry-run preview returns, whether the operation is destructive, and any return-value expectations. An agent would need to inspect the schema and still lack usage context.

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 adds conceptual value by linking 'time and access-based' to half_life_days and access_weight, but it does not detail individual parameters. The schema already carries the semantic weight, so a 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 action ('Apply') and a clear resource ('memory importance scores'), and explains the mechanism ('time and access-based decay') with a concrete consequence. This distinguishes it from siblings like reinforce or forget without needing to inspect 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?

The description implies a maintenance use case ('memories not accessed recently will have reduced importance') but does not explicitly state when to prefer this over alternatives like forget or consolidate, nor does it mention exclusions. The context is implied, not explicit.

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. 'DESTRUCTIVE' flags the risk and 'use dry_run first' gives a safe workflow. It could add irreversibility or confirmation requirements, but the warning is sufficient for a deletion tool.

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 two-clause sentence that leads with the operation and immediately adds the critical warning. No filler or redundant schema repetition.

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 destructive operation with a fully documented schema and no output schema, the description plus the schema provide everything an agent needs to invoke it safely. The optional _agent_id and the dry_run/confirm semantics are already covered in 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?

Schema coverage is 100%, so the baseline is 3, but the description adds safety-meaning by instructing dry_run-first behavior beyond the schema's parameter defaults. This helps an agent act correctly without reading deeper into the parameters.

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 clear verb and resource: 'Delete all memories in a namespace.' This is distinct from siblings like forget/forget_batch or rename_namespace. The word 'all' also signals full-namespace scope.

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?

Provides clear context: the operation is destructive and should be preceded by dry_run. It does not explicitly name alternatives or exclusions, but the dry-run-first instruction is actionable and contextually useful.

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. It discloses the ANN-based search mechanism and pluggable scoring, which is useful. However, it doesn't disclose potential side effects (likely none), performance characteristics, or what happens with missing/invalid memory_id. The description is honest but not deeply transparent about edge cases or failure modes.

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 core purpose is front-loaded, and the technical mechanism (ANN-based search, pluggable scoring) is stated efficiently. Every word 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 read-only search tool with 100% schema coverage and no output schema, the description is largely complete. It explains the cross-corpus scope and the scoring mechanism. It could be improved by noting that results are ranked by similarity and that no side effects occur, but the absence of annotations and output schema is partially mitigated by the clear schema descriptions.

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 parameters. The description adds the conceptual context of 'cross-corpus' and 'ANN-based search with pluggable scoring', which helps understand scoring_strategy and exclude_same_namespace. However, it doesn't add specific parameter-level details beyond the schema, 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 clearly states the tool's function: finding cross-corpus connections for a memory via semantically similar memories across all namespaces and projects. It uses a specific verb ('find'), names the resource ('memory'), and distinguishes itself from siblings like recall and nearby by emphasizing cross-corpus/namespace scope and ANN-based search.

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 cross-corpus connections rather than same-namespace recall. It doesn't explicitly name alternatives or exclusions, but the cross-corpus emphasis and the exclude_same_namespace parameter provide clear context. Sibling names like recall, nearby, and hybrid_recall suggest alternatives, but the description doesn't explicitly route between them.

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 of behavioral disclosure, but it only restates what the name implies. It does not say whether the operation is read-only, whether an existing file is overwritten, whether vectors are included by default (the schema says true, the description is silent), or what the tool returns — and there is no output schema to clarify.

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 zero wasted words. The verb leads, and the format parenthetical packs the key parameter dimension into the description efficiently without repeating schema content.

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 is rich (100% parameter coverage, one enum, clear defaults), but with no annotations and no output schema, the prose must supply the operational context — and it doesn't. Missing: safety profile (read-only vs. destructive), return value or confirmation behavior, file-overwrite semantics, and usage context relative to import/recall siblings.

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 of 3 applies — all six parameters are already well documented in the schema. The description's mention of formats and file output lightly echoes format and output_path but adds no parameter-level meaning 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 ('Export') and resource ('memories') with a destination ('to file') and enumerates the supported formats (Parquet, JSON, CSV). This is unambiguous and naturally separates it from siblings like import_memories, recall, and hybrid_recall, even without naming 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?

Usage is implied by the verb — when memories need to be written to an external file — but no explicit conditions, exclusions, or alternatives are given. The description doesn't contrast this with import_memories (the inverse) or recall/hybrid_recall (in-memory retrieval), so an agent must infer when this is the right choice.

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 full responsibility for behavioral disclosure. It mentions the pattern-matching mechanism but doesn't disclose whether the tool writes to persistent storage, what it returns, or any side effects. The schema hints at namespaces and deduplication, but the description doesn't explain these behaviors, leaving a significant gap for a tool that likely mutates memory state.

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 sentences, front-loaded with the core purpose and then the method. No redundant wording; each sentence contributes. It's concise and easy to scan, with no wasted words.

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 has seven parameters, no output schema, and no annotations, yet the description is only two sentences. It doesn't explain what the extraction produces, whether it persists memories, or how the various thresholds and namespaces affect behavior. An agent cannot fully predict the tool's side effects or return value, making this incomplete for its 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 description coverage is 100%, so all seven parameters have descriptions. The description's mention of 'conversation text' aligns with the 'text' parameter but adds no meaningful semantics beyond the schema for other parameters like 'project', 'namespace', or 'deduplicate'. Baseline 3 is appropriate because the schema handles the heavy lifting.

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 a specific action ('extract memories') on a specific resource ('conversation text') and explains the method ('pattern matching'). It distinguishes implicitly from siblings like 'remember' (which likely stores explicit memories) by emphasizing automatic extraction, but it doesn't explicitly name alternatives or contrast with them.

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

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

The description provides no guidance on when to use this tool versus siblings like 'remember', 'recall', or 'remember_batch'. It doesn't state prerequisites, exclusions, or alternative conditions, leaving the agent to infer usage from the tool name and schema alone.

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 burden of explaining behavior. It clearly indicates a destructive action targeting a memory, but it does not disclose whether the deletion is permanent/irreversible, whether there are side effects, or what happens when the memory_id does not exist.

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, complete sentence with no redundant words. The core information is front-loaded and every word contributes to understanding the operation.

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 delete operation with one required, well-documented parameter and no output schema, the description is mostly sufficient for an agent to select and invoke the tool. It only lacks minor behavioral details such as permanence or response 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?

Schema description coverage is 100%, so the schema already documents memory_id as 'The ID of the memory to delete'. The description adds no additional meaning beyond that, and the optional _agent_id parameter is only described in 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 a specific verb ('Delete'), a specific resource ('a memory'), and a precise targeting method ('by its ID'). It is clear and unambiguous, though it does not explicitly differentiate itself from sibling tools such as forget_batch.

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: when you have a single memory_id and want to delete that memory. However, it gives no explicit conditions, prerequisites, or exclusions, and does not mention the sibling forget_batch for bulk deletion scenarios.

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 of behavioral disclosure. It clearly indicates a destructive delete action but provides no details about reversibility, partial failure handling, permissions, or what happens if some memory IDs do not exist.

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 efficiently conveys the action, target, and selection mechanism, earning its place in one concise sentence.

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 with one required parameter and full schema coverage, so the core invocation is complete. However, there is no output schema and no behavioral caveats, leaving some uncertainty about batch operation semantics such as invalid IDs or return values.

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 both parameters. The description adds no extra meaning beyond the schema; it only restates the deletion purpose, warranting the baseline score.

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 ('Delete') and resource ('multiple memories') and adds the key differentiator 'by their IDs' and 'multiple', which distinguishes it from the singular sibling tool 'forget'. An agent can immediately understand the tool's scope.

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 this tool is for deleting multiple memories at once, which provides an implied usage context relative to the 'forget' sibling. However, it does not explicitly state when to choose 'forget_batch' over 'forget' or any other alternative, leaving usage rules inferential.

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 must carry the burden of behavioral disclosure. It only states that health is checked, but does not mention whether the operation is read-only (likely, but not stated), what the output format looks like, or any side effects. For a tool that presumably performs a read-only check, lacking explicit read-only disclosure is a significant gap, especially with no annotations to fall back on.

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, short sentence that conveys the core purpose without waste. It is appropriately front-loaded and easy to parse. It earns a high score because it is concise and to the point, though a bit more specificity could be added without breaking conciseness.

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 simplicity (no output schema, no required parameters, no nested objects), the description is minimally sufficient for basic understanding. However, since annotations are absent and there's no output schema, the description fails to disclose return behavior or any system-specific health semantics. For a health-check tool, agents may need to know what a healthy state looks like or how to interpret results, which is missing.

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

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

Schema description coverage is 100%, and both parameters are well-described in the schema. The description adds no extra semantic information about parameters, but given the high schema coverage, the baseline of 3 is appropriate. The 'verbose' parameter's effect is documented, and '_agent_id' has a clear purpose, so the description doesn't need to repeat those details.

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 'Check system health status.' clearly states the verb (check) and resource (system health), making its purpose understandable. However, given the large set of sibling tools covering memory operations, there's no explicit differentiation from potential health-like tools, but no sibling appears to directly compete. The simplicity is adequate but could be more specific about what 'health' means (e.g., service status, database connectivity).

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 provides no guidance on when to use this tool versus alternatives, nor any context about typical use cases or exclusions. Since the siblings are diverse (memory operations, stats, namespaces), a brief note on when to check health (e.g., before other operations) would help. The absence of any timing or conditional advice leaves usage entirely 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?

No annotations are provided, so the description carries the burden. It communicates that the operation is a non-mutating search and reveals the hybrid retrieval behavior, which is useful. It does not describe result merging, ordering, or safety guarantees beyond the 'search' wording, so transparency is adequate but not deep.

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 sentence with no filler. It front-loads the core purpose ('Search memories') and immediately states the distinguishing hybrid behavior.

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 rich parameter schema, the description is sufficient for basic invocation, but there is no explicit usage guidance, no mention of return shape, and no output schema to compensate. For a search tool this is acceptable, but not 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 description coverage is 100%, so the parameters are already well documented. The description's 'vector and keyword' framing adds helpful context for the alpha parameter, but it does not add significant meaning for limit, project, namespace, or min_similarity 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 names a specific operation ('Search memories') and a distinguishing mechanism ('combined vector and keyword (full-text) search'). This clearly separates hybrid_recall from sibling recall and other memory tools, so an agent can infer what makes this tool different.

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 hybrid_recall — when both semantic vector matching and keyword/full-text matching are desired — but it does not explicitly name alternatives or state when not to use it. The guidance is present by implication rather than direct routing.

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 exist, so the description carries the disclosure burden. It does add a meaningful safety behavior (dry-run first) and mentions validation, but it does not disclose the mutation/persistence side effects of a real import, how deduplication/embedding regeneration behave, or any rate/limits. This is minimal but not absent.

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 the primary action front-loaded and the safety instruction second. It is efficient, though a little more context about what dry-run produces or what happens on a real import would make it more useful.

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?

Despite the rich schema, this is a 9-parameter mutating operation with no annotations and no output schema. The description does not state what the tool returns, what a successful import changes, what a dry run reports, or how it relates to remember_batch/export_memories. The two-sentence summary leaves material gaps for an agent deciding whether and how to call 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 input schema already has 100% description coverage for all 9 parameters, so the baseline is 3. The description adds only the directive to set dry_run=true first; it does not explain formats, paths, or the dedup/embedding parameters, so it provides no additional semantic lift.

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 ('Import memories'), the object ('memories'), and the source ('from file'), and adds a validation qualifier. It does not explicitly contrast itself with sibling tools such as remember_batch or export_memories, but 'from file' is enough to signal bulk file import.

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?

'Use dry_run=true first' provides a concrete, safe invocation sequence, which is useful guidance. However, the description never states when to choose this tool over alternatives or when not to use it, so the selection context remains 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 of behavioral disclosure. It reveals the SLERP mechanism but leaves a fundamental ambiguity: does 'discovers memories' mean finding existing stored memories near the path, or synthesizing new interpolated vectors, and does it persist anything? No side-effect, ordering, or endpoint-inclusivity behavior is disclosed.

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 totaling roughly 20 words, with the core verb and mechanism front-loaded. It is appropriately tight, though 'semantic space' and 'conceptual path' are mildly redundant phrasings of the same idea.

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

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

With no output schema and no annotations, the description must explain return values and side effects but does neither. An agent is left unsure what it receives (interpolated points vs. existing memory records), whether endpoints are included, and how steps/namespace shape the result.

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 five parameters. The description adds no parameter-level detail (e.g., how steps affects the journey or what namespace filters), so it stays at the baseline rather than adding value.

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

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

The description names a specific verb (Navigate), a clear resource (semantic space between two memories), and a distinguishing mechanism (spherical interpolation/SLERP). This differentiates it from siblings like nearby (single-point search) or discover_connections, since journey is the only tool focused on the path between two endpoints.

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: an agent can infer this tool is for exploring intermediate concepts between two known memories. However, the description provides no explicit when/when-not guidance and names no alternatives, which matters in a 25-tool suite with similar-looking tools like wander, nearby, and hybrid_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?

With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation via 'List' and states the output scope, but it does not mention authentication, rate limits, pagination, or whether include_stats=false changes the output shape beyond what the schema states.

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 concise sentence with no filler. The core action and output details are front-loaded, making it easy to scan.

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, the core behavior is covered. However, with no output schema and no behavioral caveats, an agent must infer the exact response shape and whether 'all' namespaces implies pagination or performance concerns.

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?

Both parameters are fully described in the schema with defaults and explanations, so the description does not need to add much. The phrase 'with memory counts and date ranges' echoes the include_stats parameter but does not meaningfully extend the schema's meaning.

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 clear verb ('List') and a specific resource ('namespaces'), and specifies the returned information ('memory counts and date ranges'). This makes it easy to distinguish from mutation-focused siblings like delete_namespace and rename_namespace.

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 no guidance on when to use this tool versus alternatives, nor does it mention exclusions such as when to set include_stats to false. It is a straightforward command statement without usage context.

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 of behavioral disclosure. It only says 'Find memories similar to a specific memory,' which implies a read operation but does not disclose result ordering, pagination behavior, what similarity is based on, or whether any side effects occur. This is a significant gap for a tool with no annotation safety profile.

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 wasted words. It states the action and the target resource directly, which is appropriate for a concise tool description.

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 tool with five parameters, no output schema, no annotations, and many retrieval-related siblings, the description is incomplete. It explains only the core purpose and omits usage guidance, behavioral details, and any indication of what the response will look like, leaving an agent under-equipped to invoke it 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 description coverage is 100%, so the input schema already documents all five parameters. The description adds no additional meaning beyond the schema, such as how limit interacts with similarity ranking or how project/namespace scoping affects results. Baseline 3 is appropriate because 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 ('Find') and resource ('memories similar to a specific memory'), making the core operation clear. It does not explicitly contrast with sibling tools like recall or hybrid_recall, but the phrase 'similar to a specific memory' distinguishes it from generic retrieval.

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 a usage context: use it when you need semantic neighbors of a known memory. However, it provides no explicit guidance on when to prefer this over recall, hybrid_recall, or discover_connections, and no exclusions or prerequisite conditions are 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the search mechanism (semantic similarity) but doesn't disclose whether this is a read-only operation, how results are ordered, whether it triggers side effects like memory consolidation, or any rate limits. For a search tool with no annotations, this is a significant 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?

The description is a single concise sentence that front-loads the core purpose. It earns its place with no wasted words, though it could add a brief usage note without becoming bloated.

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

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

With no output schema and no annotations, the description is incomplete for a tool with six parameters. It doesn't explain return format, ordering, or how semantic similarity is computed. The schema covers parameters, but the description doesn't provide enough context for an agent to know what to expect from the call or when to use 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?

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.

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 'Search for similar memories using semantic similarity' clearly states the verb (search), resource (memories), and method (semantic similarity). It distinguishes itself from sibling tools like 'hybrid_recall' and 'nearby' by specifying semantic similarity, though it doesn't explicitly name 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?

The description implies usage for finding similar memories but provides no explicit guidance on when to use this tool versus alternatives like 'hybrid_recall' or 'nearby'. The schema parameters (namespace, min_similarity, project) hint at filtering use cases, but the description itself doesn't state when to choose this over siblings.

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 disclosure burden. It does disclose the algorithmic approach (HDBSCAN) and that the tool 'Returns cluster info', suggesting a read/analysis behavior, but it does not mention side effects, scope, rate limits, or edge cases.

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, information-dense sentences with the core action and algorithm front-loaded. There is no fluff or redundant repetition 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?

There is no output schema, so the return-value summary ('cluster info with representative memories and keywords') carries the output burden and is adequate but leaves the exact cluster fields unspecified. With no required parameters and complete schema coverage of the optional parameters, the definition is nearly complete for 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 all five optional parameters are already documented in the input schema. The description adds no extra parameter-level meaning, so the baseline score 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?

States a specific action ('Discover semantic clusters') plus the algorithm ('using HDBSCAN') and resource ('memory space'). The return value ('cluster info with representative memories and keywords') further differentiates it from memory operations like recall or nearby.

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 it: when an agent needs semantic clusters of memories. However, it gives no explicit guidance on when to choose this tool over siblings such as discover_connections or nearby, and no exclusions or prerequisites are 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?

With no annotations, the description carries the behavioral burden and it does state two core effects: increasing importance and resetting the decay timer. However, it is not fully transparent about edge cases, such as set_value with a low boost_amount potentially not increasing importance, and it omits side effects like the default update_access 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?

Two sentences with no filler; the primary action is front-loaded and the second sentence adds a distinct behavioral consequence. Every word 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?

The definition is adequate for a simple mutation tool with fully documented parameters, but it lacks guidance on when to choose reinforce over siblings and does not describe return or error behavior or edge cases like set_value. Given no annotations and no output schema, more context would make it 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 100%, so the baseline is 3. The description reinforces that boost_amount and boost_type affect importance and mentions the decay timer, but it does not explain the differences among additive, multiplicative, and set_value 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 uses a specific verb ('Boost') and resource ('memory importance'), and explicitly contrasts with decay by noting it increases importance and resets the decay timer. This distinguishes reinforce from siblings like decay and 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 phrase 'based on usage or explicit feedback' gives an implicit trigger for when to use the tool, but it does not state when not to use it or name alternatives such as decay or consolidate. An agent must infer the appropriate context among 24 sibling tools.

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 of behavioral disclosure. It only says 'Store a new memory' and does not mention side effects, duplicate handling, auto-detection of project/namespace, rate limiting, or any write-operation caveats. The schema mentions idempotency behavior, but the description itself adds little beyond the basic action.

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 focused sentence with no wasted words. It conveys the essential action immediately and does not bury key 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?

Despite having eight parameters, nested objects, no output schema, and no annotations, the description provides only one sentence of context. It does not explain return behavior, side effects, or operational considerations, leaving much for the agent to infer.

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 all eight parameters. The description adds no parameter-level detail, but because the schema is thorough, a baseline score 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 states a specific verb ('Store') and resource ('a new memory in the spatial memory system'), making the core function clear. It is distinguishable from siblings like forget and recall, though it does not explicitly differentiate itself from remember_batch.

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 guidance is given about when to choose this tool over alternatives such as remember_batch, recall, or reinforce. The description provides no context for selection or exclusions.

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 present, so the description carries the full burden of behavioral disclosure. It only says storing is 'efficient', but does not explain side effects, overwrite behavior, project scoping behavior, or what happens to failed items in the 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?

The description is one short sentence and front-loads the core action. The word 'efficiently' adds little, but the overall structure is appropriately minimal and scannable.

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 write operation with no annotations and no output schema, the description is too thin. An agent gets no sense of return value, failure handling, project scoping, or behavioral constraints beyond 'store multiple memories'.

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 `project`, `memories`, and `_agent_id`. The description adds no meaningful parameter detail beyond 'multiple memories', so it stays at the 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 states a specific action ('Store') and resource ('memories'), and clarifies the batching aspect with 'multiple memories' and 'single operation'. It does not explicitly name sibling distinctions, but the batch nature is clear enough to separate it from 'remember'.

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 'efficiently in a single operation' implies this tool is for storing multiple memories at once, which is a reasonable usage signal. However, it provides no explicit guidance on when not to use it or which sibling tool to prefer for single-memory storage.

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 that it moves all memories, implying that the operation may have a wide impact, but it does not state whether it is reversible, if it requires special permissions, or what happens to the old namespace. For a mutation tool, this is a moderate 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, concise sentence that front-loads the key action and outcome. No wasted words; every part contributes to understanding what the tool does.

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 performs a rename that moves all memories, the description is adequate but lacks information about potential side effects (e.g., if the new namespace already exists, whether it's reversible, or whether it's a destructive operation). The absence of an output schema is fine, but the mutation impact is not fully contextualized.

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 parameters are well-documented in the schema. The description adds minimal extra meaning beyond implying that the old_namespace and new_namespace are the key arguments. 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 clearly states the action (rename), the resource (namespace), and the effect (moving all its memories to the new name). This distinguishes it from sibling tools like delete_namespace or namespaces, making the purpose unambiguous.

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 that this tool is for renaming a namespace and that it affects all memories, but it does not explicitly state when to use it over alternatives like delete_namespace or namespaces. The context is clear, but there are no explicit exclusions or alternative 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose that the tool generates configuration and returns JSON, and the schema reveals defaults and options. However, it doesn't disclose side effects (e.g., whether it writes files, modifies the environment, or just returns text), nor does it mention any permissions or rate limits. The description is honest but thin on behavioral traits beyond what the schema already shows.

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 sentence that front-loads the core purpose and output format. It is concise and free of filler. It could earn a 5 if it also included a brief usage hint, but as-is it is efficient and clear.

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 tool with no required parameters, no output schema, and no annotations, the description gives the essential purpose and output type. However, it doesn't explain what the generated hooks JSON contains beyond 'hook configuration', nor does it clarify whether the tool writes files or returns content. Given the tool's simplicity and full schema coverage, this is adequate but not 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 100%, so the schema already documents all five parameters. The description adds the high-level purpose ('cognitive offloading') and output format, but it doesn't add meaning beyond the schema for individual parameters. Baseline 3 is appropriate because the schema does the heavy lifting.

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 ('Generate') and resource ('hook configuration for cognitive offloading'), and specifies the output format ('ready-to-use hooks JSON'). It distinguishes itself from the sibling tools, which are all memory operations, by being the only tool about hook configuration. However, it doesn't explicitly name a sibling alternative or contrast itself, so it doesn't fully earn 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?

The description implies usage context: it is for setting up hooks for Claude Code or Cursor, and the 'cognitive offloading' phrase suggests when to use it. But it doesn't explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The client parameter gives some context, but there is no direct guidance on when this tool is the right choice.

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 of behavioral disclosure. It states the tool retrieves statistics and health metrics, which implies a read-only operation, but doesn't disclose potential performance implications of including index details, whether the operation is expensive, or what specific metrics are returned. The description is adequate but not rich in behavioral 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?

The description is a single, concise sentence that front-loads the core purpose. It's appropriately sized for a simple stats tool, though it could benefit from a brief note on what distinguishes it from the 'health' sibling.

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 stats tool with 100% schema coverage and no output schema, the description is mostly complete. However, the overlap with the sibling 'health' tool creates ambiguity about which tool to use for what purpose, and the description doesn't clarify what specific health metrics are included or how they differ from the health tool's output.

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 minimal value beyond the schema, only implying that the tool aggregates database statistics. Baseline 3 is appropriate since the schema does the heavy lifting.

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 'Get database statistics and health metrics' clearly identifies the verb (get) and resource (database statistics/health metrics), which is sufficient to distinguish it from most sibling tools. However, it doesn't explicitly differentiate from the sibling 'health' tool, which likely overlaps in scope.

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 this is for retrieving database-level statistics and health metrics, but provides no explicit guidance on when to choose this over the sibling 'health' tool or other diagnostic tools. The parameter descriptions add some context (e.g., namespace filtering, index details), but the main description lacks clear usage boundaries.

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 the algorithm and output but omits side effects, performance implications, or whether it's a read-only operation. Minimal disclosure for a tool with no annotation coverage.

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?

Single, front-loaded sentence with no filler. Every word is meaningful and the core purpose is stated 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?

With 7 parameters, no output schema, and no annotations, the description is too terse to fully guide an agent. It doesn't explain how to select memories (memory_ids vs namespace), what the coordinate output looks like, or how formats (json, mermaid, svg) differ.

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 covers all 7 parameters, and description adds little beyond it. The mention of 'optional similarity edges' echoes the include_edges parameter but doesn't explain the relationship between memory_ids and namespace filters or output structure.

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 clearly states it projects memories to 2D/3D using UMAP for visualization, and mentions the output (coordinates and optional similarity edges). This is specific and distinguishes it from retrieval tools like recall or nearby.

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 guidance on when to use this tool versus alternatives. The description implies visualization use case but doesn't mention when to prefer it over nearby or recall, nor any exclusions or prerequisites.

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 must carry behavioral disclosure, and it does explain the core algorithm (random walk, temperature-based sampling). It does not state whether the operation is read-only, whether exploration mutates memory state, or what the returned walk contains.

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 compact sentences with the core purpose first and the algorithm detail second. No filler or repetition of schema fields.

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 five-parameter, no-output-schema tool with no annotations, the description gives the high-level operation but fails to state what the returned walk looks like or what side effects, if any, occur. It is usable but leaves the invocation contract partially open.

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 all five parameters have descriptions, so the schema already carries the parameter semantics. The description adds no parameter-level detail, which matches the baseline 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 names a specific action ('Explore'), a concrete resource ('memory space'), and a method ('random walk'), which is enough to distinguish it from targeted retrieval siblings such as recall or nearby. It does not explicitly contrast with siblings, so it stops 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?

The temperature sentence gives an implied use case: choose higher temperature for broader exploration and lower for focused exploitation. However, it never explains when to prefer wander over recall, nearby, or journey, nor does it state exclusions or prerequisites.

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