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

With no annotations provided, the description fully covers behavioral traits: read-only, no side effects, pure introspection, no drift detection, no signals, no receipt. This is comprehensive for a safe introspection 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 three concise sentences. First sentence captures purpose and return. Second lists fields. Third summarizes what it is not. Efficient and front-loaded with key information.

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

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

For a simple, single-parameter, read-only tool, the description fully explains its purpose, behavior, and return value. No output schema exists, but the JSON-like return structure is described. Given the complexity, it is completely adequate.

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% for the single optional path parameter. The schema already explains it clearly. The description adds no further meaning about the parameter, but the behavioral context (pure introspection) is indirectly useful. 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 clearly states the tool introspects the orchestration policy without running the orchestrator, distinguishing it from faf_orchestrate_recommendation. It specifies the verb 'introspect', the resource 'orchestration policy', and the concrete return structure, leaving no ambiguity.

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 tells when to use (to check policy before actual orchestration) and what not to expect (no drift detection, no signals, no receipt). Implicitly contrasts with faf_orchestrate_recommendation by naming it as the sibling that would perform orchestration.

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

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

Annotations already indicate destructive behavior (destructiveHint=true). The description adds context: writes file to target directory (created if missing), refuses overwrite unless force set, and returns confirmation. No contradictions with annotations.

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

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

Three well-structured sentences, front-loaded with purpose. No wasted words; every sentence adds necessary 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?

Covers key aspects: file creation, overwrite behavior, directory creation, return value, and next step (call faf_score). Despite no output schema, the return value is described. For a tool of this complexity, 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 coverage is 100%, so baseline 3. The description adds value by explaining the force parameter's effect (override refusal) and implying the directory parameter's role (target for writing). This goes beyond schema 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 it creates a project.faf file (IANA-registered context file) with specific purpose (persistent project DNA). It distinguishes from sibling tools like faf_score (readiness check) and faf_sync by detailing its unique role and output.

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 says 'Run once at project start, or with `force` to regenerate, then call faf_score to check readiness.' It also notes the refusal to overwrite without force. However, it does not directly compare with all siblings like refresh_faf, but the intended use case 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 fully discloses behavior: it is read-only with respect to substrate state, never auto-fires, writes a recommendation receipt for audit, and composes multiple internal checks. This provides clear expectations for the agent.

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 well-structured, starting with the main purpose, then listing components, usage caveat, audit behavior, and read-only nature. Each sentence adds value, though it could be slightly more concise by removing the list of components which may be unnecessary for the 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 no output schema and no annotations, the description covers all essential aspects: purpose, behavior (advisory, read-only), side effects (writes receipt), and internal logic (composes multiple checks). No critical information is missing for an agent to invoke 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 has zero parameters, and schema description coverage is 100%. The description does not need to explain parameters. It adds context by noting that the tool operates on 'current substrate state,' which is implicit rather than parameter-driven. Baseline score for 0 parameters is 4.

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 returns a structured recommendation about drift, specifying the output includes which refresh to call or no_action, severity, and underlying signals. It differentiates itself from siblings by being a 'heavy orchestrator' that composes multiple checks, distinguishing it from lighter tools like faf_guide or faf_status.

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 'ADVISORY ONLY — never auto-fires,' telling the agent not to automatically execute actions based on the recommendation. It also mentions it writes an auditable receipt, implying it's for logging. However, it does not specify when not to use this tool versus alternatives like faf_get_orchestration_policy or refresh_faf.

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 explicitly states determinism ('the same .faf always scores the same') and that it returns score, tier, and per-slot breakdown. It does not mention side effects, auth needs, or rate limits, but none are expected.

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 defines purpose and scale, second adds determinism and return info. No fluff, front-loaded with key information.

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

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

Given no output schema, the description adequately explains return values (score, tier, per-slot breakdown). It covers the single parameter's effect implicitly. Could mention tier categories but sufficient for a simple 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?

Schema coverage is 100% for one optional parameter. The description aligns with the schema ('Returns the score, tier, and per-slot breakdown') but adds no additional meaning beyond what the parameter description already provides.

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

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

The description uses a specific verb 'Score' and resource 'project's AI-readiness', clearly defines the 0–100% scale and the 33-slot context model. It distinguishes this tool from siblings by its unique assessment 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 implies usage for scoring AI-readiness but provides no explicit guidance on when to use versus alternatives like faf_trust or faf_init. No exclusions or context are 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. It discloses non-destructive behavior and action (inject at top, preserve prose). However, it does not specify behavior if .faf block already exists, file permissions, or error handling, leaving some 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?

Two sentences, front-loaded with the core action, then adds qualifiers. Every sentence serves a purpose—no waste.

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 zero parameters, no output schema, and a simple operation, the description covers the action, target files, and key behavioral traits. Lacks details on prerequisites or failure modes, but sufficient for basic 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?

The input schema has zero parameters with 100% coverage, so baseline is 4. The description adds value by explaining the tool's purpose without relying on parameters, so no deduction.

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 syncs project.faf into specific AI context files, listing them explicitly. It distinguishes from siblings by specifying its unique action (injecting a .faf block) and its non-destructive nature.

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 when to use the tool (to sync project.faf into context files) and mentions its non-destructive property. However, it does not explicitly compare with siblings like refresh_faf or refresh_blend, missing an opportunity to guide 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?

No annotations are provided, so the description carries the full burden. It discloses the tool validates structure and integrity by checking well-formedness and parsing. However, it does not specify the return format (e.g., boolean, error messages) or what happens if validation fails.

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

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

The description is two sentences, front-loaded with the main action and purpose. Every word serves a purpose, with no 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 and no annotations, the description is brief but covers the core purpose. However, it lacks details on what constitutes a successful validation or the return value, which would be helpful for an agent invoking the 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?

There are no parameters, so the baseline is 4. The description adds value by explaining the tool's purpose and context, which is sufficient since no parameters need documentation.

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 validates a project.faf's structure and integrity, acting as a pre-flight trust check. It specifies the verb 'validate' and the resource, and it distinguishes from sibling tools like faf_init and faf_score by focusing on validation rather than initialization or scoring.

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 advises using this tool before an agent grounds on the context file, with the principle 'never build on a broken context layer.' This gives clear usage timing but does not explicitly state when not to use it or provide alternatives.

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, but the description fully discloses the behavior: it is destructive (drops all cached retrievals) and causes the next query to rebuild from source. This compensates for the lack of 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?

Two sentences, no wasted words. The first sentence states the action and effect, the second gives usage guidance. Perfectly front-loaded.

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

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

Given the tool's simplicity (no parameters, no output schema), the description fully explains what it does and when to use it. No gaps remain.

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 per the rubric baseline is 4. The description does not need to add parameter meaning since there are none.

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 (Clear) and resource (LAZY-RAG cache), explicitly states the effect (drop all cached retrievals), and distinguishes from siblings like rag_query and rag_cache_stats by focusing on cache 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?

Provides clear context for use: 'Use when the underlying context has changed and you want fresh results instead of cached ones.' However, it does not mention when not to use it or suggest alternative tools, which prevents a higher score.

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 the tool retrieves statistics (read-only) but does not disclose any side effects, permissions, or rate limits, leaving 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?

A single, front-loaded sentence with no filler. Every word adds value, listing the core functionality and output metrics concisely.

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 stat retrieval tool, the description covers the basic purpose and output. However, it omits important context such as whether stats are cumulative or per session, and does not reference sibling tools like rag_cache_clear that could affect these stats.

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 no parameters (100% coverage). The description adds value by specifying the output fields (hits, misses, hit rate, cache size), which is beyond the schema and compensates for the missing output 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 verb 'Get' and the resource 'LAZY-RAG cache statistics', listing specific metrics (hits, misses, hit rate, cache size). It effectively distinguishes from sibling tools like rag_cache_clear or rag_query.

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 on when to use this tool versus alternatives such as rag_cache_clear or rag_query. The description implies monitoring use but lacks explicit context or exclusions.

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

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

No annotations present; description mentions LAZY-RAG cache and speedup but lacks details on side effects (e.g., cache writing), permissions, rate limits, or error behavior. Missing critical behavioral context for a query 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: first states purpose, second adds a key technical detail. No fluff, front-loaded, efficiently communicates core function and a differentiator.

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 exists, but description does not explain what the tool returns (e.g., answer text, references). For a simple query tool with one parameter, the lack of return description is a moderate 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?

Single parameter 'question' with schema description 'Question to ask'. Schema coverage is 100%, so baseline 3 is appropriate. Description adds no extra semantic value 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?

Clearly states the verb 'ask' and resource 'question with RAG-enhanced context from xAI Collections'. Differentiates from siblings like rag_cache_clear and rag_cache_stats by specifying the core querying functionality. No ambiguity.

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?

Implies usage for question-answering with RAG, but no explicit guidance on when to use vs. alternatives (e.g., direct search or other faf tools). Does not provide when-not-to-use 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 full burden. It explains the two modes and mentions intensity matching drift rate per layer. It does not disclose potential side effects, authentication needs, or rate limits, but for a refresh operation the behavioral description is 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 concise and well-structured: it begins with the core purpose, then explains the two modes with their analogs, and ends with a relevant behavioral detail. Every sentence earns its place without redundancy.

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

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

Given the tool has 5 parameters and no output schema, the description covers the input semantics and mode behaviors adequately. Missing details include what the output looks like (e.g., success message, return values), but the description is sufficient for an AI agent to understand when and how to invoke it.

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

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

Schema coverage is 100% with parameter descriptions. The tool description adds a high-level context (analogy to keyboard shortcuts, 'light .faf + delta .fafm') but does not significantly extend the meaning beyond what the schema already provides for each parameter. 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 clearly states the tool is a combined refresh that fires both refresh_faf and refresh_fafm. It distinctly separates the two modes ('blend' vs 'nuke') and relates them to keyboard shortcuts (Cmd+R / Cmd+Shift+R), making the purpose unambiguous and differentiating it from the sibling 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 clear context on when to use each mode ('everyday re-ground' vs 'hard reload'). However, it does not explicitly state when to prefer this combined tool over calling refresh_faf or refresh_fafm individually, nor does it mention any prerequisites or conditions that might require separate calls.

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 transparency burden. It discloses re-reading and re-scoring but does not mention side effects (e.g., does it modify any state?), required permissions, or rate limits. The phrase 'Built for Grok, by request' adds no 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?

Three sentences cover purpose, usage flow, and note. The first two sentences are informative; the third ('Built for Grok, by request') is peripheral. Overall concise but not maximally 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?

Given no output schema, the description mentions returning 'fresh context' and drift delta, which suffices for a re-grounding tool. It explains both parameters and the session workflow. Lacks specifics on return format but enough for most agents.

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% (both parameters have descriptions). The description adds no extra meaning beyond the schema: 'baseline' is already described as last-known score for drift, and 'path' as project directory. Per guidelines, baseline is 3.

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

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

The description clearly states the tool re-reads and re-scores the .faf, reports drift vs last-known score, and returns fresh context. It explicitly uses the verb 're-ground' and distinguishes from siblings like faf_read and faf_score by positioning itself as a 're-grounding primitive' for long sessions.

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 in long sessions where drift occurred ('drift → refresh → re-grounded') and mentions the optional 'baseline' parameter for drift reporting. However, it lacks explicit guidance on when not to use this tool or specific alternatives among 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 fully discloses behavior: read-only, returns hash+timestamp stamp, delta by default, verbatim option, and that since parameter is ignored when verbatim=true. No contradictions.

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?

Concise and front-loaded: specifies action, default behavior, and alternatives in two sentences with no redundant information.

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

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

Despite no output schema, the description adequately explains return values (stamped delta or full content with hash+timestamp). Covers all parameters, usage, and relationships between options.

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%, but the description adds significant context beyond the schema: explains default soul behavior, advises sparing use of verbatim, and notes interplay between since and verbatim.

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 reloads structured memory (.fafm) for souls into the current session, with specific verbs like 'reload' and 'refresh', and distinguishes it from siblings (recall, load_soul, etch).

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 explains when to use (reload latest memory) and when to use alternatives (verbatim for full content, delta default). Mentions it complements but does not replace other tools, providing clear guidance.

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