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

No annotations are provided, so the description must bear the burden of behavioral disclosure. It does well by stating the operation is recorded as reversible, that old memories are invalidated but never deleted, and that confirmation is conditionally required. It could add more on failure modes or idempotency, but the core behavior is clearly transparent.

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 short, front-loaded with the main purpose, and each sentence contributes distinct information: what it executes, reversibility, memory invalidation policy, and confirmation requirements. 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?

All required invocation details are present: the required plan_id, the confirmation rules, and the important consequence of applying the plan. Without an output schema, return-value details are not necessary for correct invocation, and the description gives enough context for an agent to call this tool safely.

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 both parameters are already documented. The description's confirm note largely mirrors the schema's parameter description rather than adding substantial new meaning, so a baseline score 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 ('Execute') with a clear resource ('previously-generated merge/supersede plan by id'), which cleanly distinguishes it from plan-generation siblings like plan_merge and plan_supersede. It also clarifies that certain plan types need confirmation, so the agent knows what operation this performs.

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 implies this is the execution step after plan generation and gives explicit preconditions for 'possible'/'non_match' plans. However, it does not explicitly say when not to use it or name alternatives like merge_undo for reversing an applied plan, so it falls just short of fully explicit 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 provided, so description carries full burden. It implies a write operation but doesn't disclose side effects like locking, overwrite behavior, or concurrency safety.

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 efficiently written sentences with no wasted words. Front-loaded and to the point.

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 or annotations, the description is too minimal. Lacks details on backup type (full/incremental), performance impact, or prerequisites.

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?

No parameters, baseline 4 per rules. Description adds meaning by stating the action and return value, which is sufficient given zero 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?

Description clearly states it creates a SQLite database backup and returns the file path. However, it does not distinguish from sibling tools like 'restore' or 'protect'.

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. Sibling tools include 'restore', but no mention of when to backup vs other operations.

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 fully disclose behavioral traits. It only states that the tool stores and retrieves data but does not detail side effects, state changes, idempotency, or any other behavioral characteristics.

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 concise at three sentences, front-loading the overall purpose and then detailing actions. It is efficient but could benefit from a more structured layout to improve scannability.

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 9 parameters, multiple actions, and no output schema, the description is insufficient. It fails to explain how to effectively use the tool, what the output of 'get_context' includes, or how to format patterns/decisions. This leaves significant gaps for an agent to use the tool 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?

The input schema provides 100% coverage and already describes each parameter. The description adds minimal extra meaning by mapping actions to required parameters (e.g., name for remember_pattern), but this is also implied by the schema's required field logic. Thus, it meets the baseline without significantly enhancing semantics.

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 it is a unified codebase tool with three specific actions: storing code patterns, storing architectural decisions, and retrieving patterns/decisions. It distinguishes between these actions but does not differentiate from sibling tools beyond listing 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?

No guidance is provided on when to use this tool versus alternatives. The description does not include any 'when to use' or 'when not to use' context, nor does it mention 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 carries the behavioral disclosure burden. It does state that the tool reads durable events and lets users label outcomes, conveying both read and write-like behaviors. But it omits side-effect details such as whether labeling modifies durable state permanently, whether confidence_delta alters weights, or whether any action is destructive.

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 deliver a high density of useful information without redundancy. The first sentence establishes the domain and data sources; the second enumerates outputs and labeling options. It could be slightly more structured, but it remains appropriately sized for a nine-parameter multi-action tool.

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

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

Given the high complexity—seven actions, nine parameters, no output schema, and no annotations—the description is insufficient for safe autonomous invocation. It does not state which parameters are required per action, what responses look like, or whether label actions persist changes. The schema defines parameters, but the tool still lacks a complete operational contract.

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 baseline is 3; the description adds useful semantics on top by mapping actions to their results (recent/already-composed lanes, neighbors, never-composed pairs, bounty-mode lanes) and by listing representative outcome labels. This helps an agent interpret the otherwise terse enum values without fully documenting every parameter relationship.

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 identifies the resource as "ComposedGraph memory topology" and enumerates the concrete operations: reading composition events and members, returning lanes/neighbors/pairs, and labeling outcomes. It is clear in capability, but it does not explicitly differentiate itself from sibling tools like memory_graph or memory_timeline, relying instead on a domain-specific term.

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 through its list of operations—querying composition topology and labeling outcomes—so an agent can infer when it might be relevant. However, it provides no explicit when-to-use guidance, exclusions, or alternatives, and the large sibling list makes such routing guidance more important.

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 reveals that the tool applies decay, generates embeddings, and performs maintenance, which is useful. However, it does not disclose whether this mutates or weakens memory representations, whether it is reversible, or what 'maintenance' concretely involves.

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 concise sentences: the first front-loads the action and behavior, the second gives the usage condition. There is no filler, repetition, or irrelevant detail.

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 trigger tool, this is nearly complete, but because there is no output schema or annotations, the description does not state what the call returns or whether the consolidation is safe or destructive. The vague 'performs maintenance' leaves room for unintended side effects.

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

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

The tool exposes zero parameters, so there are no parameter semantics to clarify. The input schema is trivially fully covered, and the description adds context that this is a no-argument maintenance operation, which is adequate.

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 ('Run'), a defined process ('FSRS-6 memory consolidation cycle'), and concrete behaviors ('applies decay, generates embeddings, and performs maintenance'), so the purpose is clear. It does not explicitly name sibling alternatives, but 'consolidation' is distinct from search, ingest, and analysis tools.

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 an explicit trigger condition: 'Use when memories seem stale.' It does not say when not to use it, nor does it name alternatives such as `dream` or `memory_health`, so exclusion guidance is incomplete.

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 communicates that the tool is inspection-oriented ('Inspect', 'Scans'), defines the input scope ('topic or recent memories'), describes the output concept ('contradiction pairs'), and mentions trust weighting. It does not detail every edge case or output format, but the core behavior and non-mutating nature are reasonably transparent.

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 with no fluff. The core purpose is front-loaded in the first sentence, and the second adds necessary scoping and algorithmic context. Every phrase contributes to agent understanding, making it concise without sacrificing informativeness.

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 all parameters are optional, the schema is fully descriptive, and the description clarifies purpose, scope, and output type, this is nearly complete. There is no output schema, so the description could have said slightly more about the exact return structure, but 'contradiction pairs' plus the trust-weighting mention gives sufficient context for an agent to invoke the tool confidently.

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 adds a little meaning by linking 'topic or recent memories' to the topic/since parameters and 'trust-weighted' to min_trust, but it does not explain limit or since beyond what the schema already provides. The schema is strong enough that the description adds only marginal value here.

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

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

The description states a specific action ('Inspect memory disagreements'), identifies the exact resource ('memory disagreements'), and explains the mechanism ('Scans a topic or recent memories for trust-weighted contradiction pairs'). It also differentiates itself from the sibling deep_reference by noting it uses 'the same local logic' but is focused on direct contradiction inspection.

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 establishes when to use this tool: when you want to inspect memory disagreements directly by scanning a topic or recent memories. It does not explicitly state when not to use it or name alternative tools beyond the brief mention of deep_reference, so it lacks explicit exclusions but still provides clear contextual guidance.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only mentions 'cognitive reasoning' and 'across memories,' which is too vague to indicate whether the operation is read-only, how much processing it performs, what the output looks like, or whether it has 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?

The description is short and front-loads the alias information, which is efficient. However, 'connect the dots across memories with cognitive reasoning' is vague and does not earn its place by adding concrete detail; it is more a slogan than a specification.

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 two parameters, no output schema, and no annotations, the description leaves significant gaps: it does not explain what the output is, how depth changes results, when to prefer this over alternatives, or what guarantees or limitations apply. The alias is suggestive but not sufficient.

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 both query and depth are already documented in the schema. The tool description adds no additional meaning about how these parameters affect behavior beyond the schema's own descriptions.

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 that the tool connects dots across memories with cognitive reasoning, which conveys a general cross-referencing purpose. However, 'connect the dots' is metaphorical and vague, and the tool is only defined as an alias for the sibling deep_reference without clarifying what that operation actually produces.

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 explicit guidance is given for when to use this tool versus alternatives like search, explore_connections, or deep_reference. The 'alias for deep_reference' clue is helpful, but it does not explain use cases, exclusions, or how this differs from other memory-related 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?

With no annotations, the description carries the transparency burden. It discloses the reasoning steps (FSRS-6 trust scoring, spreading activation, temporal supersession, dream insights, contradiction analysis) and the result shape, which goes beyond a generic 'reason over memories.' It doesn't address cost/latency or explicitly confirm read-only behavior, but the framing implies analysis rather than mutation.

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

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

Three sentences, front-loaded with the core purpose and ending with a usage cue. The list of five internal techniques is dense but informative; no filler or redundant restatement.

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 complex no-output-schema tool, it covers what it does, how it does it, what it returns, and when to invoke it. It lacks details on interpreting trust scores or cost implications, but the basics needed by an agent to select and call it are present.

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

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

Schema coverage is 100%, so the description adds little beyond what the input schema already says: 'query' is described as a question/claim/topic and depth is an integer with higher values meaning more thorough. No extra semantics are introduced.

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 frames deep_reference as a synthesis/analysis tool over memories, naming the techniques involved and the concrete deliverables: trust-scored evidence, fact evolution timeline, and a recommended answer. This distinguishes it from simple retrieval tools like search or cross_reference, though it doesn't explicitly name a sibling.

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

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

It gives an explicit trigger condition: 'Use this when accuracy matters.' That's a clear high-level guideline, but it doesn't name alternatives or state when not to use it, leaving the agent to infer the boundary versus 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?

With no annotations, the description carries the full burden of behavioral disclosure. It says the tool 'strengthens important patterns,' which strongly implies mutation of memory state, but never states whether this is a read-only operation, whether changes are reversible, or what side effects occur. It also does not mention cost or runtime considerations. This ambiguity 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, front-loaded sentence that conveys the action, the purpose, and the expected return value without wasted words. It delivers high information density in under thirty 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 description provides a high-level output ('insights, connections, and dream stats') but lacks detail on return structure, potential side effects, prerequisites (e.g., sufficient memory history), or performance implications. Given no output schema and no annotations, this leaves noticeable gaps for an agent deciding whether to invoke the tool and how to interpret its effects.

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 the ideas of 'recent memories' (memory_count) and 'connection discovery' (min_similarity) but adds no detail beyond the schema. It neither compensates for nor obscures the parameter meanings.

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 ('Trigger') with a clear resource ('memory dreaming') and states the outcome: 'replays recent memories to discover hidden connections, synthesize insights, and strengthen important patterns.' This distinguishes the tool's core function, though it does not explicitly differentiate it from similar siblings like explore_connections or consolidate.

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 purpose is implied through the stated outcomes—use when you want to discover hidden connections, synthesize insights, or strengthen patterns. However, there is no explicit guidance on when NOT to use this tool or which siblings (explore_connections, consolidate, predict) are better suited for similar goals. The large sibling list makes this ambiguity more costly.

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

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

The description adds behavioral context beyond the schema by mentioning 'spreading activation + hippocampal index' and explaining what each action computes. However, with no annotations present, it does not disclose whether the operation is read-only, whether it mutates memory, what output shape to expect, or any side effects or prerequisites.

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 compact and front-loaded with its core identity, followed by the action enum in a scannable list. It wastes no words, though the unexplained 'hippocampal index' jargon slightly reduces clarity.

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 4-parameter tool with no output schema and no annotations, the description adequately covers the core actions and their intent. It is not fully complete because it leaves return formats, action-specific output differences, and when to prefer this over sibling graph tools unspecified.

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 adds little parameter-level semantics beyond restating the action types already in the enum, and it does not clarify 'limit' semantics or the conditional requirement of 'to' 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 verb-resource pairing: 'Graph exploration tool for memory connections,' and enumerates three distinct actions ('chain', 'associations', 'bridges') with brief meanings. It is clear in its purpose though it does not explicitly differentiate itself from sibling graph tools like memory_graph, composed_graph, cross_reference, or deep_reference.

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 per-action descriptions imply when each mode is appropriate: building a reasoning path, finding related memories, or finding connecting memories. However, it provides no explicit when-to-use guidance versus the many sibling search/graph tools, and no exclusions or alternative 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?

The description lacks behavioral details beyond the basic function. It does not disclose side effects (e.g., file creation in the exports/ folder), required permissions, or whether the operation is safe. With no annotations, the description carries the burden but fails to provide sufficient transparency.

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 short and direct, but it inaccurately limits formats to just 'JSON or JSONL' while the schema includes 'portable'. Still, it is front-loaded and avoids verbosity.

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 that the tool has 4 parameters, no output schema, and no annotations, the description is too brief. It does not explain the export behavior, file naming, overwrite policy, or how the 'portable' format differs. For a data export tool, more context 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?

Schema description coverage is 100%, so the parameters are already documented. The description adds marginal value by mentioning 'tag and date filters' but does not provide additional syntax or constraints beyond what the schema offers. 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 that the tool exports memories in JSON or JSONL format, using a specific verb ('Export') and resource ('memories'). However, it omits mention of the 'portable' format available in the schema, slightly reducing clarity.

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. The description does not indicate when to use this tool versus other sibling tools like 'backup' or 'memory_changelog', nor does it mention prerequisites 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?

With no annotations, the description takes on full disclosure responsibility. It explains the method (cosine similarity) and output (clusters with suggestions), but does not state whether the tool is read-only or if it performs any modifications. The phrase 'clean up' could imply action, but the description clarifies it returns suggestions.

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 extremely concise with only two sentences, each serving a distinct purpose: first explaining what the tool does, second recommending when to use it. No extraneous 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?

Given the absence of annotations and output schema, the description adequately covers purpose, method, and use case. It could be slightly more complete by explicitly noting that the tool does not modify memories (only returns suggestions), but overall it is sufficient for an AI agent.

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% with well-described parameters. The description adds no additional context beyond the schema for the three parameters, so it meets the baseline for parameter semantics without adding extra 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 clearly states the tool's action ('Find duplicate and near-duplicate memory clusters'), the method ('using cosine similarity on embeddings'), and the output ('returns clusters with suggested actions'). It is specific and uniquely identifies the tool among 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?

The description explicitly recommends using the tool 'to clean up redundant memories', providing clear context. However, it does not mention when not to use it or suggest alternatives (e.g., merge_candidates, contradictions), though the tool is niche enough that this is less critical.

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 full burden. It discloses the destructive potential by mentioning dry_run safety, and the threshold criteria. However, it does not detail side effects, irreversibility, or behavior during actual deletion.

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 is front-loaded with the main purpose. No extraneous words, every part 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?

No output schema is provided, and the description does not explain return values or behavior. It lacks context on what happens after the call (e.g., list of deleted items, effect on other tools). It is complete enough for a simple tool but leaves gaps.

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%, baseline set to 3. The description only reiterates the dry_run default and does not add additional context or relationships between parameters 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 clearly states the verb 'Garbage collect' and resource 'stale memories below retention threshold'. It is specific and distinct from many siblings, but does not explicitly differentiate itself from other memory management tools like 'consolidate' or 'merge_candidates'.

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 garbage collection with a safe default (dry_run=true), but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions that would make it inappropriate.

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 of behavioral disclosure. It does well by naming the scoring model and all return components, making the operation appear non-destructive and read-only. It could go further by specifying output format or failure behavior, but this is a fairly transparent scoring 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?

The description is a single dense sentence with no filler. The core action, model, and output fields are all front-loaded and every word contributes useful 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?

There is no output schema, so the description's enumeration of return components provides necessary context. It is reasonably complete for a 3-parameter tool, though specifying the output structure or score scale would make it 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 baseline is 3. The description indirectly references content and novelty context through the model channels but does not add meaningful parameter details beyond what the schema already documents.

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 ('Score content importance'), the distinctive 4-channel neuroscience model, and the concrete outputs (composite score, channel breakdown, encoding boost, explanations). This clearly distinguishes the tool from generic search or prediction 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?

The purpose implies when to use it—when content importance scoring is needed with optional project/topic context. However, it does not explicitly state when to prefer it over siblings such as predict or explore_connections, nor does it provide any 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?

With no annotations, the description carries full responsibility for behavioral disclosure. It mentions actions but fails to describe side effects (e.g., persistence of intentions), required permissions, rate limits, or error conditions. The agent is left uninformed about important behavioral traits.

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 concise—two sentences that front-load the key concept and actions. It is efficient but could be better organized (e.g., bulleted actions) for faster scanning.

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 12 parameters and nested objects, the description does not explain complex structures like trigger or context, nor does it describe return values (no output schema). The description is too brief to provide a complete understanding for effective tool use.

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 no new meaning beyond the schema's parameter descriptions. It restates actions but does not enrich understanding of parameter usage or interrelationships.

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 identifies the tool as 'Unified intention management tool' and lists four distinct actions (set, check, update, list), which communicate its purpose. However, it does not define what an 'intention' is, leaving some ambiguity. The differentiation from sibling tools is implicit as no other tool is for intention management.

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 does not provide explicit guidance on when to use this tool versus alternatives. It only enumerates actions without context on appropriate scenarios or prerequisites. This leaves the agent to infer usage from the action names 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 fully discloses behavior: it explains that 'purge' is irreversible and requires confirm=true, 'promote' increases retrieval strength, 'demote' decreases it without deletion, and 'edit' preserves FSRS state. This is comprehensive and transparent.

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 dense sentence with a list of actions. While efficient and front-loaded, it could be slightly more structured (e.g., using a bulleted list) for easier scanning. However, it earns its place with every word.

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 complexity (8 actions, 6 parameters, no output schema), the description covers all necessary information: each action's effect, parameter requirements (e.g., confirm for purge), and the result of operations (e.g., tombstone after purge). It is 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%, but the description adds significant context beyond the schema, e.g., explaining that 'purge' permanently removes content/embeddings, 'promote' is a thumbs up, and 'edit' preserves FSRS state. This adds meaning that aids correct parameter usage.

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 'Unified memory management tool' clearly states the tool's purpose. It lists all possible actions (get, purge, delete, state, promote, demote, edit), each with a specific role, effectively distinguishing this tool from siblings like search, memory_graph, etc.

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 managing memory nodes but does not explicitly state when to use this tool over alternatives. For instance, it doesn't differentiate when to use 'memory' vs 'search' for retrieving memories. However, the action list provides implicit 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It signals a read-only operation via 'View' and describes what each mode returns, but it does not disclose ordering, pagination, time-range handling, or whether the audit trail is filtered or complete. This is adequate but leaves important behavioral gaps.

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 extremely concise: two short sentences with no filler. The primary purpose and the two distinct operating modes are front-loaded and immediately actionable.

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 lack of an output schema and annotations, the description should explain more about what the returned audit trail contains and how the modes affect results. It covers the basic mode distinction but omits guidance on when to prefer this tool over the similar-sounding 'memory_timeline' and what format or order results will take.

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 adds meaningful mode semantics: per-memory mode corresponds to state transitions, while system-wide mode corresponds to consolidations and recent state changes. This helps an agent understand the effect of supplying or omitting memory_id beyond what the schema 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 clearly identifies the verb ('View') and resource ('audit trail of memory changes'), and distinguishes two modes: per-memory state transitions and system-wide consolidations/recent state changes. It is specific and understandable, though it does not explicitly differentiate this tool from the similarly named sibling 'memory_timeline'.

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 by presenting per-memory versus system-wide modes, which helps an agent decide whether to supply a memory_id or omit it. However, it does not state when to choose this tool over alternatives like memory_timeline, nor does it provide exclusions or explicit conditions beyond the two modes.

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 present, the description carries the behavioral disclosure burden. It explains the return shape—nodes with force-directed layout positions and edges with weights—and 'export' implies a read-only operation. However, it does not explicitly state side effects or confirm no mutation occurs.

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 compact and front-loaded with the core action and inputs. It is slightly redundant because 'Subgraph export for visualization' and 'Powers memory graph visualization' overlap, but it remains easy to scan and understand.

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 simple tool shape and full schema coverage, the description covers inputs, output semantics, and intended visualization use. It could be more complete by clarifying the exact relationship between center_id and query, but the schema already provides that detail.

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 input schema already fully documents all four parameters. The description only echoes the parameter names and constraints without adding deeper semantic detail beyond what the schema 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 clearly identifies this as a 'Subgraph export for visualization' and specifies inputs and outputs, so an agent can understand the basic function. However, it does not differentiate this tool from similarly named siblings like explore_connections or composed_graph.

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 'Powers memory graph visualization' implies when the tool should be used, but the description does not explicitly state when to choose this over alternatives. There are no direct references to sibling tools or conditions for selection.

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 full responsibility for behavioral disclosure. It clearly describes the tool as a read-only dashboard and enumerates its outputs at a useful level of detail, including bucket ranges and trend labels. It does not explicitly say 'does not modify memory,' but the dashboard framing and return-value list strongly imply a non-destructive reporting operation.

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

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

Two tight sentences, with the core identity front-loaded ('Retention dashboard') followed by a compact list of return values and the differentiating alternative. Every sentence earns its place and there is zero 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 parameterless tool with no output schema and no annotations, the description provides a complete picture of what the agent can expect: the type of result, the buckets, trend options, and a recommendation, plus the sibling-tool relationship. Nothing essential is missing for selecting and invoking this tool 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?

The tool has zero parameters and 100% schema description coverage, so there is no parameter semantics to clarify. Per the rubric, a zero-parameter tool receives a baseline of 4; the description correctly adds no irrelevant parameter talk.

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 resource (retention dashboard) and details exactly what it returns: average retention, retention distribution buckets, trend, and recommendation. It also distinguishes itself from system_status as a focused, lightweight alternative, making its purpose unmistakable.

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 explicitly positions this tool as a lightweight alternative to system_status and focuses on memory quality, giving clear context for when to choose it over a broader status check. It does not enumerate exhaustive exclusion conditions, but the guidance provided is sufficient for a zero-parameter read-only tool.

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?

Without annotations, the description carries the full burden. It discloses meaningful behavior: chronological ordering, day grouping, and the default 7-day window. However, it omits details like whether the operation is read-only, how pagination works beyond 'limit', and what values appear in the returned day groups.

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, with the primary purpose front-loaded and the second sentence adding key behavioral context. Every clause contributes meaning and there is no redundancy or filler.

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

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

For a simple browse-with-filters tool, the description is nearly complete: it states the action, time-range behavior, grouping, and defaults. It lacks explicit sibling routing and a note about the shape of the returned day groups, but this is not a severe gap given the exhaustive 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?

The input schema already describes all 6 parameters with 100% coverage. The description adds little beyond restating that memories are returned in a time range and defaults to 7 days, which the schema documents via 'start' and 'end' defaults. With full schema coverage, a baseline of 3 is appropriate.

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

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

The description states a specific action ('Browse memories chronologically') and a clear resource with defined behavior. It differentiates itself from memory search by focusing on chronological browsing, though it doesn't explicitly name a sibling 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 description implies usage for retrieving memories in a time range and defaults to last 7 days, making the general use case clear. However, it does not provide explicit guidance on when to prefer this tool over the sibling 'search' tool or any 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?

With no annotations, the description carries full burden. It discloses read-only behavior and the Fellegi-Sunter algorithm for match/possible/non-match, providing key behavioral insight without covering rate limits or auth needs.

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 concise sentences: first states core purpose with algorithm and output, second emphasizes read-only nature. No unnecessary words 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?

Given no output schema, the description covers the main output (confidence scores, signals) but lacks details on candidate cluster structure. With only 2 simple params and read-only nature, it is mostly complete for agent decision-making.

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 baseline 3 applies. The description adds no extra meaning beyond the schema-provided parameter descriptions; it only mentions the output (scores, signals) but not parameter specifics.

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 'surface' and resource 'likely duplicate/overlapping memory clusters', mentions confidence scores and Fellegi-Sunter signals, distinguishing it from siblings like 'find_duplicates' which likely lacks this algorithm detail.

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

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

Explicitly states the tool is read-only and 'nothing is changed', guiding when to use for inspection. However, it does not explicitly list when not to use or name alternative tools for actual merging, leaving some inference to the agent.

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 the behavioral disclosure. It honestly states the get/set duality and the no-args read behavior. However, it does not disclose side effects of setting thresholds, whether partial updates are allowed, or what a set call returns. This is adequate but not deeply transparent for a mutation-capable 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, front-loaded with the verb and resource, and no filler. The special no-args behavior is included efficiently.

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 config getter/setter, the description covers the resource and read path, but it leaves ambiguity about partial vs full replacement when setting only one parameter, does not describe the return shape of a set or get call, and does not mention any validation relationship between the two thresholds. These are meaningful gaps for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds the 'Fellegi-Sunter' domain context and names the fields, but most parameter meaning already exists in the schema. It does not materially extend the schema's descriptions.

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 phrase, 'Get or set', a concrete resource, 'the per-project merge policy', and names the three settings. It is clearly distinct from the merge execution siblings like plan_merge and apply_plan because it focuses on configuration rather than 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 description implies when to use it: call with no args to read the policy, call with args to change it. However, it does not explicitly distinguish it from related merge-family tools or state when not to use it, leaving the agent to infer the boundaries from the resource name.

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 disclosure burden. It explains the reversible-log behavior and the optional operation_id dual mode, but does not detail consequences of reversing, error cases, or whether the reverse itself is reversible.

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 main purpose is front-loaded, and the optional-mode behavior is introduced efficiently. The 'git reflog' analogy adds useful context without bloating the 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 single optional parameter and no nested objects, the description covers both invocation modes and the intended list-then-pick workflow. It does not define the return shape, but that is acceptable given the low complexity and the log-listing semantics.

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 restates operation_id semantics and adds the 'pick one from the reflog' workflow, but provides no format or syntax details 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?

States a specific verb 'Reverse' and resource 'prior merge/supersede operation,' and also describes the no-operation-id listing mode. The reflog metaphor and operation-type wording distinguish it from generic restore or consolidate 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?

Clearly conveys when to use it: reverse a prior merge/supersede operation, and when no operation_id is supplied, list the log so the agent can choose one. It does not explicitly name alternatives or exclusions, but the usage context is clear.

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 burden of behavioral disclosure. It states the operation is non-applying, returns a plan_id for a later apply step, and can be blocked by protected members. It does not mention plan expiration or persistence, but the key safety trait (no mutation yet) is explicit.

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

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

Three short sentences deliver the full essential contract without repeated schema content. Key constraints are front-loaded: previewability, memory count, non-application, plan_id routing, and protected-member 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?

For a planning tool with no output schema, the description covers purpose, safety, next step, and a blocker. It is slightly short of a 5 because it omits the tool's relationship to merge_undo/merge_policy and any plan validity constraints, but none of these are required for a correct first call.

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 fully documented in the schema. The description reinforces '2+ memories' and the diff output but does not need to add parameter-level details; baseline 3 applies.

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

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

The description names a specific action ('Produce a previewable MERGE plan'), defines the resource (memories), and scopes it ('2+ memories') and the output (a diff of content/tags/provenance). It clearly distinguishes from apply_plan by stressing 'WITHOUT applying it', which disambiguates it from the apply sibling.

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 clear usage context: call this to preview a merge and get a plan_id for apply_plan, and it notes a blocking condition ('Protected members block the merge'). It does not explicitly enumerate when not to use related tools like plan_supersede or merge_candidates, so the guidance is clear but not exhaustive.

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 disclosure burden. It reveals that the operation is a dry run, describes bitemporal invalidation (stamps valid_until, keeps A queryable for audit), and states it returns a plan_id. It does not cover input validation or plan lifetime, but the key side-effect profile is transparent.

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

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

A single dense sentence packs the action, behavioral mechanism, non-applying caveat, and return value with no filler. Every clue earns its place.

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

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

For a two-parameter preview tool with no output schema, the description gives enough: what it does, what changes it models, that it does not apply, and what the agent receives next. An agent can invoke it correctly and know the follow-up step.

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 both parameters are already well described. The description adds the A/B role mapping and reinforcorces that old_id is kept and marked invalid, but this mostly restates schema semantics rather than adding new 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 opens with 'Preview superseding memory A with B', giving a specific verb and resource, and clarifies the non-applying preview nature with 'WITHOUT applying'. This clearly distinguishes it from apply_plan and other mutation siblings like plan_merge.

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 explicitly frames the tool as a preview ('Preview... WITHOUT applying') and names the follow-up tool ('Returns a plan_id for apply_plan'), so the agent knows when to use it. It does not explicitly rule out related alternatives such as plan_merge, but the workflow context is clear.

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?

There are no annotations, so the description carries the burden. It discloses that the tool performs prediction and returns 'predictions, suggestions, and speculative retrievals,' but does not state whether the call is side-effect free, whether predictions are persisted, or any reliability caveats beyond 'speculative.'

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 compact single sentence with the key directive front-loaded. The phrase 'Proactive memory prediction' slightly repeats the verb 'predicts,' but overall it is efficient.

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 annotations, no output schema, and several potentially overlapping siblings, a one-line description is insufficient. It omits side-effect guarantees, return format, and distinction from tools like dream, explore_connections, or intention, leaving an agent to guess when this tool is the correct choice.

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 single 'context' parameter is described in the schema, so the description is not required to add much. It adds a little value by explaining that predictions are based on context, recent activity, and learned patterns, but it does not elaborate on nested fields.

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 identifies a verb ('predicts') and resource ('what memories you'll need next'), and differentiates itself as 'proactive' memory prediction. It does not explicitly distinguish itself from overlapping siblings such as 'dream' or 'intention', 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 description implies when to call the tool—when anticipating future memory needs from context, recent activity, and learned patterns—but never states when not to use it or names alternatives. No explicit routing guidance is 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains the protective effect and the toggle for unpinning. It does not discuss permissions, errors, or return values, but the core behavior and reversibility are clearly communicated.

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, each earning its place: the first states the core action and guarantees, the second explains the reversal. The content is front-loaded and free of filler.

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

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

For a simple two-parameter toggle tool with no output schema, the description plus schema covers the essential use, semantics, and reversal. It is complete enough for an agent to invoke correctly, though it leaves response/error behavior unspecified.

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 id and protected, including the default and meaning. The description's 'Pass protected=false to unpin' adds no new meaning beyond the schema, so it meets the baseline but does not exceed 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 uses the specific verb 'Pin' and clearly identifies the resource: a memory. It also states the exact consequences (no auto-merge, supersede, or garbage-collection), which distinguishes it from sibling tools like merge_candidates, plan_supersede, and gc.

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 a memory should be preserved from automatic maintenance. However, it does not explicitly state when not to use it or mention any alternatives, leaving some usage reasoning to inference.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It omits that this is likely a destructive write operation, whether it overwrites existing memories, or any safety/reversibility caveats. The only extra behavioral detail is the supported file formats.

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 concise sentences, with the core purpose front-loaded and the format details placed right after. Every sentence earns its place.

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

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

The schema provides rich descriptions for all parameters and the description covers formats, but the tool is not complete for safe invocation without knowing the destructiveness of a restore and what happens to existing memories. No output schema or annotations exist to fill that gap.

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

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

Schema description coverage is 100%, and each parameter already has a clear description. The tool description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific action ('Restore memories') and target ('from a JSON backup file'), and the format enumeration adds precision. This clearly differentiates it from siblings like backup or export.

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 restoration use case but does not explicitly say when to choose this tool over alternatives like backup or export, nor does it state exclusions such as prerequisites like an empty target database. The schema's merge parameter hints at context, but the description itself lacks when/when-not guidance.

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

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

The description discloses that the tool auto-strengthens memories on access (Testing Effect), which is a significant behavioral trait not captured in the schema or annotations (none provided). This helps the agent understand 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?

The description is concise with two sentences, but it lacks structured formatting (e.g., bullet points). It efficiently conveys core information without verbosity.

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 complexity (20 parameters, rich schema descriptions, no output schema), the description is minimal. It does not explain return values or when to use specific parameter combinations, though schema details compensate partially. Adequate but not thorough.

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 100% description coverage, so the description itself does not add further parameter meaning beyond what is already documented. 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 clearly identifies the tool as a 'Unified search tool' and outlines its hybrid retrieval method. However, it does not explicitly distinguish it from sibling tools like 'memory' or 'codebase', which may also retrieve information, so it's slightly generic.

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 explicit guidance is provided on when to use this tool versus alternatives. While it implies general-purpose search, there is no mention of exclusions or specific contexts (e.g., when to prefer 'memory' for specific IDs).

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 of behavioral disclosure. It does state a key behavioral trait: combining multiple sources 'into a single token-budgeted response'. However, it does not clarify whether this initialization has side effects (e.g., triggering/generating intentions or predictions) or whether it is purely read-only, leaving some ambiguity.

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 with no wasted words. 'One-call session initialization' is a clear opening that front-loads the core purpose, followed by the concrete list of combined sources and the value proposition of replacing 5 calls.

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 there is no output schema, the description should provide a sense of what is returned; it does list the content categories (search, intentions, status, predictions, codebase context) but not their structure or ordering. With 6 parameters fully documented in the schema and no required parameters, the description is adequate for invoking the tool but not fully complete for understanding 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%, and parameter descriptions already explain queries, token_budget, include_status, include_intentions, and include_predictions with defaults. The description maps the tool's output categories to those parameters but does not add meaningful detail beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'One-call session initialization' that 'combines search, intentions, status, predictions, and codebase context'. It clearly distinguishes itself from the individual sibling tools by framing itself as an aggregate replacement, so an agent can tell it apart from search, intention, system_status, predict, and codebase.

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 explicitly says 'Replaces 5 separate calls at session start', giving a clear when-to-use context and naming the alternative approach (making individual calls). It lacks explicit when-not-to-use guidance, such as 'if you only need one component, call that tool instead', so it stops short of a full 5.

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 full behavioral disclosure. It reveals the internal pipeline—Prediction Error Gating, importance scoring, intent detection, synaptic tagging—and the auto-decide behavior for CREATE/UPDATE/SUPERSEDE. It does not detail destructive consequences of superseding or return-value behavior, but the core mutation semantics are transparent.

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 compact sentences with the primary purpose front-loaded and mode details following quickly. It avoids waste, though the all-caps 'INTELLIGENT' and parenthetical pipeline list add a bit of rhetorical weight without core semantic gain.

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 complex ingestion tool with no output schema and no annotations, the description covers modes, pipeline, and batch limits well. It is still missing expected return values, explicit consequences of SUPERSEDE, and clear guidance on how this tool relates to alternatives like consolidate or apply_plan, leaving an agent to infer those from sibling names.

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 fully documented and the baseline is 3. The description adds useful mode-level guidance by mapping 'content' to single mode and 'items' to batch mode, but it does not substantially extend the schema's own parameter explanations.

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 concrete function—intelligent memory ingestion—and specifies the two operating modes with distinct inputs: single mode via 'content' and batch mode via 'items'. The explicit decision outcome (CREATE/UPDATE/SUPERSEDE) makes the purpose unambiguous and helps distinguish it from retrieval or consolidation 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?

It clearly states when to use each mode: single mode for one content item, batch mode for session-end saves, and the schema adds that batch use is appropriate before context compaction. However, it does not explicitly name alternatives or state when not to use this tool versus the many memory/merge/consolidation 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, the description carries the transparency burden, and it does well: it reveals idempotency, that re-runs update changed issues without duplication, and that reconcile=true tombstones upstream-deleted issues. It does not describe return values or failure behavior, which is the main remaining 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?

Three dense sentences with no filler: purpose is front-loaded, source-specific details are grouped, and the idempotency/reconcile caveat is placed last as operational guidance. Every sentence earns its place.

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

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

For a five-parameter, two-backend sync tool with no annotations and no output schema, the description provides the needed auth, idempotency, and reconciliation context. The only notable omission is the response/return shape, which would make post-call verification easier.

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 value by binding source to repo/project, naming the env vars for auth, and clarifying reconcile's tombstone effect. It supplements the schema rather than merely repeating 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 opens with a specific verb and result: 'Index an external system into Vestige as a durable, offline, semantically-searchable index'. It also names the two supported sources, so the agent knows exactly what scope the tool has and can separate it from generic search/memory tools.

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?

Covers per-source invocation (GitHub needs repo, Redmine needs project), auth env vars, and the idempotent re-run behavior plus reconcile. It does not explicitly name sibling alternatives like smart_ingest or state when not to use this tool, so it stops just short of full exclusion guidance.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses that suppression is non-deleting, that each call compounds suppression strength, that a background Rac1 worker cascades decay to co-activated neighbors, and that reversal is only possible within a 24-hour window. This is substantial, non-obvious behavioral detail.

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 compact and front-loaded with the core action and distinct-from-delete clarification. Each sentence contributes useful information, though the scientific citation '(Anderson 2025 SIF + Davis Rac1)' is arguably unnecessary for tool invocation and may add noise for an AI agent.

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 three parameters, no annotations, and no output schema, the description covers the key outcome, side effects, compounding behavior, neighbor cascading, and reversibility. It does not state the return value or error behavior when reverse is attempted outside the 24-hour window, which is a minor gap.

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

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

Schema description coverage is 100%, so the input schema already documents id, reason, and reverse parameters effectively. The description adds context about repeated calls compounding and reverse=true being tied to the 24-hour window, but it does not materially extend 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 ('suppress'), a clear resource ('a memory'), and the mechanism ('top-down inhibitory control'). It explicitly contrasts with delete by explaining that the memory persists but is inhibited and decays, which gives an agent a precise mental model of what this tool does.

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 clear context for when to use this tool versus delete: suppress when the memory should remain but be inhibited from retrieval. It also notes reversibility within 24 hours via reverse=true. It does not, however, discuss when to use suppress versus other related siblings like protect or restore.

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 present, the description carries the full burden of behavioral disclosure. It compensates well by stating the return value semantics, possible status values (healthy/degraded/critical/empty), and the main output sections. It does not explicitly confirm the tool is read-only, but 'Returns' plus the diagnostic nature of the output strongly imply a non-mutating operation.

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 compact, front-loaded with the core purpose, and uses a single follow-up sentence to list the return contents. Every phrase earns its place, and the response is no longer than needed to convey the tool's scope.

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 description does the work of explaining return values; it lists the major response components in enough detail for an agent to know what to expect. Some terms like 'full stats' and 'recommendations' remain general, but the optional parameter is well-covered by the schema and no required parameters or complex inputs are 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 the single optional schema_introspection parameter is thoroughly documented in the input schema, including its effect on the response and when to use it. The tool description itself adds no parameter-specific meaning, but per the baseline for high schema coverage, no compensation is required.

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 is a combined health and statistics reporter, enumerating the returned categories (status, stats, FSRS preview, cognitive module health, state distribution, warnings, recommendations). The verb 'Returns' and resource 'system health and statistics' make the operation clear, though it does not explicitly contrast itself with the sibling memory_health tool.

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

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

The usage context is implied by 'Combined system health and statistics' and the listed output categories, suggesting a high-level diagnostic overview. However, there is no explicit when-to-use guidance or mention of alternatives such as memory_health or memory_timeline, leaving the agent to infer selection.

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