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

The description discloses that it searches, selects, and composes memories, but does not explicitly state whether it is read-only or if it has side effects. Since no annotations are provided, this lack of explicit side-effect disclosure leaves 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 concise, with the main purpose stated first, followed by a clear usage note. It is well-structured and free of unnecessary 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?

The description provides the core purpose and usage, but it does not specify the exact output format (beyond being a context string) or details about the multi-resolution levels. Given the tool's role in automatic injection, this is sufficient for basic use but lacks some detail for complex interactions.

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 description only repeats the parameter names and defaults from the schema without providing additional semantics. For example, it doesn't explain the purpose of top_k or token_budget beyond their names, which is insufficient given the schema has no 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 clearly states the tool automatically retrieves and composes relevant memories, which is a specific verb and resource. It distinguishes from sibling memory_search by mentioning the composition into a context string with token budget and multi-resolution levels, though it could be more explicit about the differentiation.

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 states when to use: at the beginning of every conversation turn to inject relevant memory context. However, it does not explicitly mention alternatives or when not to use, relying on the automatic nature to imply the distinction.

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 takes on the full burden of disclosing behavior. It transparently states two important behaviors: the restriction on deleting immutable memories and the automatic cleanup of graph edges. This is more than a minimal disclosure, though it does not cover all possible edge cases like error handling.

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, well-structured, and front-loaded with the main purpose. The additional behavioral notes are presented as separate sentences, making it easy for an agent to quickly grasp the tool's function and constraints without unnecessary 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 simplicity of the tool (one parameter, clear action), the description is mostly complete. It covers the action, a key constraint, and a side effect. The presence of an output schema means return values need not be explained. It lacks only details on failure scenarios, which is a minor gap for a delete operation.

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

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

The schema provides no description for the single parameter, so the tool description's explanation ('The ID of the memory to delete') is the only semantic guidance. However, this is essentially a restatement of the parameter name and lacks additional context such as format, origin, or validation rules, which limits its usefulness.

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

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

The description clearly states the action ('Delete a memory') and the resource ('from the knowledge graph'), which unambiguously distinguishes it from sibling tools like memory_update or memory_save. The purpose is explicit and specific.

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

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

The description does not provide explicit guidance on when to use this tool over alternatives. It mentions a constraint ('Cannot delete immutable memories') but does not compare with other memory-related tools or describe ideal usage scenarios, leaving the agent to infer the appropriate context.

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

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

No annotations are provided, so the description carries the burden. It states the tool 'gets' memories, implying a read-only operation, but does not explicitly declare side-effect-free behavior or discuss any potential errors or limitations beyond the depth max. The 'Get' verb provides reasonable transparency for a simple retrieval.

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, using two sentences and a clear parameter listing. It avoids unnecessary detail while providing essential 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?

For a straightforward retrieval tool, the description is complete. It explains the purpose, parameters, and traversal depth. No output schema is shown, but the return (related memories) is implicit and sufficient for the tool's simplicity.

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

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

Both parameters are clearly explained: memory_id is the starting memory ID, and depth specifies how many hops to traverse with a default of 1 and a max of 3. This fully covers the schema's meaning and constraints.

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 function: retrieving related memories via graph edges using BFS. It specifies the resource (memories) and the operation (get related), distinguishing it from search or save tools by its graph-based traversal focus.

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 explains what the tool does but does not explicitly state when to use it versus alternatives like memory_search or memory_visualize. It implies a use case (having a memory ID and wanting related ones) but lacks direct comparison or conditions.

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

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

No annotations are provided, so the description carries the full burden. It discloses the primary effect (protection from forgetting) but does not mention reversibility, permissions, or error cases; however for a simple pin operation this is 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 two short sentences, front-loaded with the action and purpose, and the parameter explanation is minimal and relevant.

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

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

The tool is simple – one required parameter. The description fully explains what the tool does and what the parameter means. Since an output schema is indicated as present, return values need not be described.

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

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

The schema only specifies memory_id as a required string, but the description adds 'The ID of the memory to pin', giving clear meaning to the parameter and explaining what value to provide.

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

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

The description clearly states the action ('Pin a memory') and the purpose ('protect it from the forgetting pipeline'), differentiating it from the sibling memory_unpin which reverses this action.

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 use case (protect a memory from forgetting) but does not explicitly contrast with alternatives like memory_unpin or mention conditions for use, leaving the guidance implicit rather than explicit.

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

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

The description does not disclose side effects, return values, error handling, or idempotency. It mentions auto-extraction and auto-classification of parameters but omits important behavioral details such as whether the operation can fail or what the success response looks like, especially given no annotations.

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

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

The description is concise, using a clear list format for parameters with no superfluous text. Each line is purposeful and directly explains a parameter or the core function, making it easy to scan.

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

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

The description covers parameters well but omits any mention of the output schema or return value, which is necessary for an agent to know what to expect. It also lacks edge-case information, but given the tool's simplicity, the gaps are moderate rather than severe.

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 description adds meaningful explanations for all six parameters, including the purpose of content, auto-extraction behavior for keywords, allowed categories, default of category, and semantics of immutable, pinned, and related_ids. This goes beyond the raw schema, which only lists types and defaults.

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

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

The description clearly states the tool's function: 'Save a new memory to the knowledge graph.' The verb 'save' and the object 'new memory' make the purpose unambiguous, and the distinction from update/delete tools is implied by the word 'new.'

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 new memories but does not explicitly contrast with alternatives like memory_update or memory_delete. It lacks explicit guidance on when to choose this tool over siblings, though the phrase 'new memory' provides some implicit direction.

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 verb 'search' and the phrase 'by semantic similarity' clearly describe the core read-only behavior, and top_k indicates result count. It does not mention side effects, but the operation is naturally non-destructive and the description is sufficiently transparent for this 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 concise and well structured, with a short purpose line followed by a compact bullet list of parameters. No filler or redundant information is present.

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 covers the tool's purpose and all parameters, and the output schema is available, so an agent can invoke it correctly. It could optionally mention result ordering or no-result behavior, but these are not critical for basic usage.

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?

All three parameters are explicitly explained: query text language, top_k default and maximum, and category as an optional filter with allowed values. This adds substantial semantic detail beyond the bare schema titles.

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 'search' and the resource 'memories', with semantic similarity as the matching method. It is unambiguous on its own, though it does not explicitly contrast with sibling tools like memory_get_related.

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 parameter notes provide useful usage hints such as query language, top_k default/max, and optional category values. However, it does not explicitly state when to prefer this tool over sibling tools like auto_search or memory_get_related; the intended use case is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only operation but does not explicitly state side effects, permissions, or lack thereof. For a simple stats getter, this is acceptable but not fully 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, concise sentence that directly conveys the tool's purpose without unnecessary detail or repetition.

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

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

The description adequately specifies what statistics are provided (total count and category breakdown), which is sufficient for a simple stats tool. No additional context appears necessary.

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 is empty with 100% coverage, so the baseline is 3. There are no parameters to explain, and the description appropriately focuses on the output rather than 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?

The description clearly states the action ('Get statistics'), the resource ('memory store'), and the specific output (total count and category breakdown). It is distinct from sibling tools like memory_search or memory_visualize.

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 explicitly state when to use this tool versus alternatives, nor does it mention conditions or exclusions. It only describes what the tool does, leaving the agent to infer when it is appropriate.

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral consequence: unpinning allows the memory to be forgotten over time. However, it does not mention reversibility, failure modes, or what happens after unpinning beyond the forgetting implication.

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, one sentence, with a clear argument list. No fluff or redundant wording; it is well-structured and easy to parse.

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

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

For a simple tool, the description covers the essential action and consequence. It does not detail return values or error handling, but the output schema is not shown, so this is acceptable. The exclusion of low-level behaviors does not detract significantly from the completeness.

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 description explains the parameter 'memory_id' as 'The ID of the memory to unpin,' providing clear meaning beyond the schema's minimal string type. This fully satisfies parameter 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 the tool's action: 'Remove pin protection from a memory, allowing it to be forgotten over time.' It distinguishes this from siblings like memory_pin (which adds protection) and memory_delete (which removes the memory entirely).

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 use case (unpinning a memory) but does not explicitly state when to use this tool versus alternatives (e.g., memory_pin or memory_delete). No direct comparisons or conditions are provided, leaving the user to infer the appropriate context.

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

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

No annotations are provided, so the description carries the full burden. It discloses that content and keywords are optional and that omitted fields retain their existing values, which is useful. However, it does not mention what happens on invalid memory_id, whether changes are reversible, or any permission requirements. It is adequate but not rich.

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

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

The description is concise and front-loaded with the core purpose, followed by a simple args list. It avoids unnecessary prose and is easy to scan. The only minor issue is that the args list could be formatted more elegantly, but it is not bloated.

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

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

Given the tool's low complexity and the presence of an output schema, the description covers the essential behavior and parameters. However, it lacks guidance on when to choose this tool over memory_save or memory_delete, and does not address error cases. It is sufficient for a simple update but could be more 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?

The schema has zero description coverage, so the description must compensate. It clearly explains each parameter: memory_id is the ID, content is new text, keywords is a list, and both optional fields preserve existing values when omitted. This adds meaning beyond the bare schema types and nullability.

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 (update), the resource (existing memory), and the specific fields (content and/or keywords). It distinguishes from siblings like memory_save (create) and memory_delete (remove) by focusing on modification of an existing item.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that it requires an existing memory_id or that creating new memories should use memory_save. The context is implied but not stated, leaving the agent to infer when this is appropriate.

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

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

There are no annotations provided, so the description carries the full burden of disclosing side effects. It mentions the 'viz' requirement but does not clarify whether the tool only reads memory or if it has any side effects, such as overwriting files or modifying the memory graph. The statement 'Creates a browser-viewable graph' implies file creation but lacks detail on behavior if the extra is missing.

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

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

The description is concise, consisting of two sentences. The main purpose is stated upfront, and supporting details (what the graph contains, the requirement for the 'viz' extra) are provided without redundancy or unnecessary wording.

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 clear overview of the tool's output (an interactive HTML graph) but lacks details on the exact return value, how to locate the generated file, or any error handling (e.g., behavior if 'viz' is not installed). Given that an output schema is indicated, some of this is mitigated, but the description alone does not fully cover operational context.

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

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

The input schema has zero description coverage for both parameters (output_path and include_inactive). The tool description adds no explanation of what these parameters control or their expected values, leaving the agent to infer their semantics from parameter names alone.

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 primary purpose: generating an interactive HTML visualization of the memory graph. It also specifies what the graph includes (memory nodes, relationships, knowledge graph entity triples), making the tool's function unambiguous.

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

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

The description notes the prerequisite that the 'viz' extra must be installed, which is a useful usage guideline. However, it does not explicitly contrast this tool with alternatives (e.g., when to choose visualization over memory_search or memory_stats), though the unique purpose is fairly self-evident.

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 the decision output and conditional returns (SAVE/SKIP/RETRIEVE with reasoning, and saved/retrieved memories). However, it is ambiguous whether the tool actually saves or retrieves memory or simply returns the decision; the phrase 'also returns the saved memory entry' could imply side effects. Since no annotations are provided, the description carries the full burden of transparency and this ambiguity is a 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 concise, with a clear first sentence stating the purpose. The return behavior is organized into conditional statements, making it easy to scan. No extraneous information is included.

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 covers the tool's core purpose, inputs, and expected outputs. However, it leaves ambiguity about whether the tool has side effects (e.g., saving or retrieving memory) or purely returns a decision. Given the existence of sibling tools that perform actions, clarifying this would improve completeness. Overall, it is mostly complete for a decision-making tool.

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 fully covers both parameters (user_message and turn_id), and the description provides minimal additional context: user_message is the message to evaluate and turn_id is an optional identifier. This meets the baseline for full schema coverage but does not add significant semantic depth beyond the schema.

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

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

The description clearly states the tool's function: asking the RL policy to decide a memory action for a user message. It specifies the verb 'ask' and the resource 'RL policy', and the outcome is a decision (SAVE/SKIP/RETRIEVE). This distinguishes it from sibling tools like memory_save or memory_search which execute actions rather than decide them.

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

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

The description does not provide guidance on when to use this tool versus the sibling tools. It does not mention alternatives or conditions for selection, such as 'use when you need to decide before executing memory_save'. The 'when' context is left implicit.

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

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

No annotations are provided, so the description carries the full burden. It states what the tool returns but does not mention side effects (e.g., read-only, no mutation) or any potential caveats like caching or latency. For a status tool, the read-only nature is generally assumed, but not explicitly stated.

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 highly concise and well-structured. It starts with the action ('Get'), states the object ('current status of the memory policy'), and then lists the return fields in a clear, bullet-free sentence. No unnecessary words or repetition.

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

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

Given that there is no output schema, the description adequately explains what the tool returns. It lists all three fields (epsilon, action distribution, update count) so a user knows what to expect. It does not dive into the meaning of these fields, but that is typically outside the scope of a tool description. Overall, it is complete for its purpose.

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

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

The tool has zero parameters, so schema coverage is 100% by default. The baseline score of 3 applies, and the description appropriately avoids mentioning any parameters since none exist.

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 purpose: to get the current status of the memory policy. It also specifies the exact data returned (epsilon, action distribution, update count), making the tool's function unambiguous. It is distinct from sibling tools like policy_decide or memory_stats, so no confusion arises.

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 explicitly state when to use this tool versus alternatives. However, as a status getter, its usage context is somewhat implicit. It would benefit from a note such as 'Use this to monitor the policy state' or 'Compare with policy_decide for actions,' but its absence is not a major flaw.

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 bears the full burden of disclosing effects. It lists the main actions including 'forgetting,' which implies potential data removal, but does not explicitly state whether the operation is destructive or reversible. It also mentions checkpoint saving without detailing recovery implications. Lacks a warning about permanent memory loss but is reasonably transparent for the listed actions.

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 clear but slightly redundant: it states 'Run the memory sleep cycle' and then 'This performs periodic memory maintenance' which repeats the same idea. Could be tightened but remains concise overall.

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 parameters and an output schema that is not described, the description provides sufficient context: what the tool does, when to use it, and the key operations involved. It does not mention what the output contains, but the output schema exists separately and isn't required for understanding the tool's core 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?

There are no parameters, so the schema coverage is trivially 100%. The description doesn't need to explain any parameters, as none exist. The action is fully described without parameter dependencies.

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 purpose: 'Run the memory sleep cycle' with a specific verb and resource. It enumerates specific actions (consolidation, resolution regeneration, forgetting, checkpoint saving) that distinguish it from other memory-related tools like memory_save or memory_update.

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 recommends when to run: 'Recommended to run periodically (e.g., daily or after many conversations).' This gives clear guidance on when to use the tool, distinguishing it from on-demand memory operations.

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