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

Annotations already declare readOnlyHint=true, idempotentHint=true. Description adds context about client sampling and synthesizer field, and reinforces read-only nature. 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?

Four sentences, front-loaded with purpose, followed by usage guidance and parameter roles. No fluff, every sentence adds value.

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

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

Given 7 parameters and presence of output schema, description covers core functionality, usage context, read-only nature, parameter tuning, and client sampling. Missing specifics on return format, but output schema exists 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 coverage is 100%, baseline is 3. Description adds context for some parameters (k, type, snippet_chars, source) but does not explain all (e.g., session_id, include_repos). Schema descriptions are already comprehensive.

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 tool answers a question using memo retrieval and citations. Distinct from sibling tools like memo_search which return raw hit lists.

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 when to use 'synthesized answer grounded in durable memories instead of raw hit lists'. Mentions parameter tuning but does not explicitly list when not to use or 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?

Extends beyond the idempotentHint annotation by detailing the exact return values for known/unknown/already acknowledged cases. This helps the agent understand the tool's exact behavior.

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

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

Two concise sentences, front-loaded with the main purpose, and no wasted words. Efficient and clear.

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

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

Comprehensive enough for a simple idempotent acknowledgment tool with output schema and annotations. Slightly lacking in connecting 'attention item' to broader context, but still good.

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

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

Schema covers both parameters with 100% description coverage. The description adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description states a specific verb 'Acknowledge' and resource 'attention item', and explains the effect 'stops being surfaced'. It is clear and distinguishable from 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?

No explicit guidance on when to use or alternatives are provided. The purpose is clear but an agent might benefit from knowing this is for dismissing attention items rather than other actions.

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 indicate it is a write operation (readOnlyHint false) and not destructive. The description adds that it journals the record and rejects invalid severities, providing extra context beyond 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 with no wasted words; the critical information is front-loaded and easily parsed.

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

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

The tool has an output schema (not shown) so return values are documented. The description covers purpose, constraints, and severity validation, but does not mention prerequisites or duplicate behavior for a simple add 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?

Schema has 100% coverage with descriptions for all three parameters. The description adds value by explicitly stating that severities outside the allowed set are rejected, which is not in the schema.

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

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

The description clearly states the verb ('Add') and the resource ('item that must be surfaced to later agents'), specifying it writes a journaled attention record. This distinguishes it from siblings like memo_attention_ack.

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

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

The description implies usage when a later agent needs to see an item, but does not explicitly state when to avoid using it or mention alternatives like memo_attention_ack for acknowledging.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with 'Read-only' and adds context about synthesis running on the calling model with client sampling, which is beyond 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 very concise: four sentences, front-loaded with the core purpose, and no unnecessary words. Every sentence adds value.

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

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

With 8 parameters (1 required) and an output schema, the description covers the main purpose and key distinctions. It doesn't detail every parameter, but the schema does, and the description adds the conversational context and guidance vs memo_ask.

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 meaning by explaining that history is a list of chat messages, session_id links the answer to a tracked session, and context is used for synthesis. This enriches the 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 the tool answers a conversational question with optional history and context. It distinguishes itself from the sibling memo_ask by specifying when to use this tool instead, mentioning prior turns or explicit context shaping retrieval.

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

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

The description provides explicit guidance on when to use this tool over memo_ask: when prior turns or explicit context should shape retrieval. It also hints at client sampling and synthesizer field but doesn't give exhaustive usage scenarios.

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

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

The description adds behavioral context beyond annotations, noting that the tool writes to a hash-chained journal and that resolution is human-only. Annotations already indicate non-destructive write operations, so the description aligns and adds value without contradiction.

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 very concise with three sentences, front-loading the purpose and then adding key details about the journal and resolution. Every sentence is informative with no fluff.

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 role in conflict management, the description adequately covers the core workflow and mentions the journal's auditability. It does not detail the output schema, but that is acceptable since an output schema exists. Minor gaps in expectations about 'open a conflict' are acceptable.

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

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

Schema description coverage is 100%, so the schema already explains all parameters well. The description does not add new information about parameters beyond what the schema provides, meeting the baseline expectation.

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: 'Open a local, auditable reality conflict.' It specifies that it writes a 'detected' conflict record to a hash-chained journal, distinguishing it from siblings like memo_conflict_resolve which handles human resolution.

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

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

The description implies when to use this tool (to open a conflict) and mentions memo_conflict_resolve for resolution, providing an alternative. However, it lacks explicit guidance on when not to use it or specific 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral context beyond annotations: that it returns a command string for human execution and does not resolve anything itself. No contradiction.

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 adding value. The first states the primary purpose, the second clarifies behavior (read-only, returns command). No unnecessary words, front-loaded with the key action.

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 low complexity (1 param, clear annotations, output schema present), the description is fully sufficient. It explains the tool's purpose, limitation, and output nature. No 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 coverage is 100% with one parameter 'id' described as 'Id of the conflict to resolve.' The description does not add meaningful new semantics beyond the schema; 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 clearly states the tool 'reports the local human action required to resolve a conflict'. It uses a specific verb ('report') and resource ('local human action'), and distinguishes from siblings by emphasizing it does not resolve conflicts itself, unlike other conflict-related 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 explicitly says 'Read-only: never resolves anything itself' and that it returns a command for a human to run. This gives clear context on when to use it (to get the resolution command) and implies when not to (when actual resolution is needed, use another tool). However, it doesn't name specific 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?

Even with annotations declaring readOnlyHint and destructiveHint, the description adds substantial context: it details the AdvancedConsolidator algorithm, sampling behavior, budget-derived defaults, response size calculations, and the middleware refusal rather than truncation. This far exceeds what the annotations alone convey.

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 front-loads the purpose in the first two sentences, then follows with a logically organized explanation of algorithm, parameters, and budget. It is verbose, but every sentence carries useful information, so the length is justified.

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 output schema exists and annotations cover safety, the description completes the picture: it explains the algorithm, parameter trade-offs, default rationale, and failure behavior (budget middleware refusing overruns). No critical context appears missing.

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

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

The input schema already has 100% description coverage, but the tool description adds non-obvious rationale: why defaults are 10x2, the token budget math, and that two sample members are enough to see a duplicate. These insights go well beyond the schema's per-parameter 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 first sentence, 'Detect near-duplicate clusters and propose merges,' is a specific verb+resource statement that clearly defines the tool's function. It also immediately clarifies the read-only nature, distinguishing it from any actual merge-execution 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 description states 'Read-only — returns proposals without modifying the corpus,' providing clear context for when to use the tool. It does not explicitly name an alternative for actually performing merges, but the read-only framing makes the intended use case 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations: it explains that the pack includes dynamic recent context (up to 5 memories updated in last 7 days), static profile, query hits, omissions, and is read-only. It also mentions budget trimming. No contradiction.

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 long. First sentence states purpose clearly. Second sentence elaborates on content and differentiates from sibling. No wasted words, 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 that an output schema exists, the description need not explain return values. It covers purpose, behavioral traits, and high-level output structure. All relevant aspects are addressed for a tool of this complexity.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add specific parameter semantics beyond the schema, but it does provide context on how budget_chars and snippet_chars affect output. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Build prompt-ready memory context without calling the answer LLM.' It contrasts with memo_search's raw hit list, specifying that this returns a budgeted, prompt-ready context pack with static profile, dynamic recent context, query hits, omissions, and a readonly prompt wrapper. This distinguishes it from siblings and is specific about what it 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 explicitly says 'Read-only. Unlike memo_search's raw hit list, this returns a budgeted, prompt-ready context pack for direct injection.' It tells when to use this tool (when needing a prompt-ready pack) and when to use an alternative (memo_search for raw hits). This provides clear 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds meaningful behavioral context: the cache holds offloaded rows, top-K rows remain embedded, and both ingest-time and proxy cache entries can be recovered through 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 purpose is front-loaded, and the supporting explanation is compact. The three context sentences are not wasted; they explain why the cache exists and how recovery works, though some of the narrative could be trimmed without losing value.

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

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

With one fully documented parameter, an output schema, and annotations covering safety and idempotency, the description supplies enough contextual background about the crush cache and its two access paths. Nothing essential is missing 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% and the single parameter, hash_marker, is fully documented with both accepted forms. The description does not need to add parameter semantics because the schema already provides complete 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 first sentence states a specific verb and resource: 'Retrieve original content from crush cache.' The surrounding explanation clarifies the cache's purpose and distinguishes it from ordinary memo retrieval, so an agent can tell exactly what this tool targets.

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 explains when the tool is relevant: after ingest-time crushing, when low-relevance rows were offloaded, and when the context-compression proxy needs to reverse a cut. It does not explicitly name alternatives or exclusion conditions, but the context is enough 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?

Beyond the destructiveHint annotation, the description adds crucial behavioral details: irreversibility (no trash), confirmation behavior for elicitation-capable clients, safe ambiguous-id resolution with errors, and cross-reference warnings. This far exceeds what annotations alone provide.

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 four sentences, each earning its place: main purpose, destructive irreversibility, confirmation nuance, and safety behavior. It is front-loaded with the core action and avoids 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 destructive tool with one parameter and an output schema, the description is remarkably complete. It covers irreversible side effects, confirmation flows, error handling for ambiguous ids, and reference warnings, leaving little ambiguity for the agent about what to expect.

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

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

The schema already fully describes the 'id' parameter (100% coverage). The description adds valuable context about prefix ambiguity resolution and error behavior, which helps the agent understand how the parameter is interpreted without guessing.

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+scope: 'Permanently delete one memory by id or unique prefix.' This clearly distinguishes it from sibling tools like memo_forget (which likely implies a soft delete) and other memory 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 usage through the phrase 'permanently delete' and mentions confirmation behavior, but it does not explicitly contrast with alternatives such as memo_forget or memo_unforget, nor does it state when not to use the 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?

Adds context beyond annotations: confirms read-only, explains empty list returns no vectors without error, and notes it uses the same internal embedder. 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?

Two concise sentences (plus one clarifying) that are front-loaded. Every sentence adds value without redundancy.

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

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

For a simple one-parameter tool with output schema, the description covers purpose, usage context, behavior, and parameter semantics adequately.

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 detailed description of the 'texts' parameter. The description adds no significant new information 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?

Clearly states action (embed), resource (document strings), and context (same embedder model as memo). Implicitly distinguishes from query embedding sibling by mentioning document strings.

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 when to use: for diagnostics or external indexing when document vectors are needed. Does not specify when not to use or alternatives, but 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description reinforces 'Read-only' and adds useful behavioral details: rejects empty text, and returns vector, dimension, and model id. No contradictions, but the description mainly confirms annotations with small additions, so a 4 is appropriate.

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 short sentences that front-load the core purpose, then add usage context and return behavior. Every sentence adds value, with no wasted words. It is highly compact yet informative.

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 a simple tool with one parameter and an existing output schema, the description covers all necessary aspects: purpose, usage context, parameter semantics, and return value structure (vector, dimension, model id). It is fully sufficient for an agent to use correctly.

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

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

Schema coverage is 100% with a single parameter 'text'. The description for this parameter adds key context: 'instruction-prefixed for asymmetric retrieval' and clarifies that empty/whitespace-only input raises an error. This meaningfully extends beyond the schema's basic type description.

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 embeds one query string using memo's query embedding path, and specifies it's for diagnostics or integrations needing the exact vector for retrieval queries. This verb+resource+scope is specific and distinguishes it from sibling tools like memo_embed_batch.

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

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

The description explicitly says 'Read-only' and 'Use for diagnostics or integrations that need the exact vector memo would use for retrieval queries.' It also notes that empty text is rejected. However, it does not mention alternatives (e.g., memo_embed_batch for batch processing) or when not to use it, which would improve clarity.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral details: citations are memo://, abstention policy based on min_coverage. 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?

Three sentences, no unnecessary words. The key one-liner is front-loaded, making it easy for an AI to quickly grasp the tool's purpose.

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 (6 parameters, high schema coverage, output schema exists), the description covers the essential behaviors (citations, abstention). Could be slightly more explicit about output format, but output schema likely compensates.

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 clear parameter descriptions. The description does not add significant meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

Clearly states the tool returns bounded, cited evidence for a question or an explicit abstention. This distinguishes it from sibling tools like memo_search or memo_ask which may not provide citations or abstention.

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 usage context: use for cited evidence, expects abstention when coverage is low. However, it does not explicitly contrast with alternatives like memo_search or memo_ask, leaving some ambiguity.

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 a safe, read-only, idempotent operation. The description adds context about ACL authorization and signed bundles, enhancing understanding of the tool's behavior without contradicting annotations.

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

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

The description is a single, concise sentence that immediately conveys the tool's purpose with no unnecessary 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?

Combined with the input schema and annotations, the description provides sufficient context. The output schema further aids completeness. Minor clarification linking the principal to the ACL would improve it.

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

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

The input schema already describes the 'principal' parameter thoroughly. The tool description does not add extra meaning beyond the schema, so parameter semantics are adequately covered.

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 preview which memories an ACL would allow into a signed bundle. The verb 'Preview' and specific resource 'exact memories' make it distinct from 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 implies the tool is used for previewing memories under ACL constraints, but it provides no explicit guidance on when to use this tool over others or when not to use it.

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

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

Adds value beyond annotations by stating idempotency and return behavior when no focus was set, though annotations already cover idempotency.

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 redundant information, action 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?

Adequate for a simple tool with full schema, annotations, and output schema; could add more context about 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?

Schema coverage is 100%, description adds no extra meaning beyond schema; baseline 3.

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

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

The description 'Clear a project's current focus' uses a specific verb and resource, clearly distinguishing from sibling tools like memo_focus_set.

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; usage is implied but not 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?

The description adds behavioral context beyond annotations: it mentions journaling with the acting agent's identity and that the change replaces the previous focus. Annotations already indicate idempotent and non-destructive, and the description reinforces idempotency by stating 'safe to repeat'. This adds useful context about journaling.

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. The first sentence states the primary action, and subsequent sentences add key behavioral details (replaces, journaled, safe to repeat). No unnecessary words, well-structured and 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 low complexity, the presence of full schema descriptions, and an output schema (not shown but present), the description is complete. It covers the core behavior, idempotency, and journaling, which suffices for this straightforward mutation 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 description coverage is 100%, so the baseline is 3. The description does not add parameter-level information beyond what the schema provides (e.g., project, summary, actor_id). It only elaborates on the overall behavior, not individual 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 'Set the current focus for a project' with a specific verb and resource. It explains that it replaces previous focus, but it does not explicitly differentiate from the sibling tool memo_focus_clear, which clears focus. Thus, purpose is clear but lacks sibling 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?

The description implies usage for setting focus and notes it is safe to repeat, which provides some guidance. However, it does not explicitly state when to use this tool versus alternatives like memo_focus_clear or when not to use it. The guidance is implied 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?

Annotations provide destructiveHint=true, and description elaborates: hidden from recall/search until memo_unforget restores it. Reversible nature clearly stated. 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 concise sentences, front-loaded with main purpose, no wasted words. Efficiently conveys all 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?

With output schema present and low complexity (2 simple params), the description covers all needed aspects: purpose, effect, parameter roles, and relationship to sibling tools.

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

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

Schema coverage is 100%, but description adds value: for 'id' mentions 'unique prefix' not in schema; for 'reason' explains purpose. Adds meaningful context beyond 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?

Description clearly states 'Mark one memory as forgotten without deleting its history.' It uses a specific verb (mark) and resource (memory), and distinguishes from siblings like memo_delete and memo_unforget.

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?

Explanation of destructive retrieval behavior and mention of memo_unforget for restoration provides context. Could explicitly state when to use memo_delete instead, but the guidance is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral context: the read-only nature, the ambiguity error, and the MEMO_EMITTED_LEDGER recovery counting. It goes beyond the structured safety hints without contradicting them.

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 front-loaded with the core purpose, then gives edge cases and usage guidance. The final paragraph about MEMO_EMITTED_LEDGER is detailed and possibly overlong, but it is relevant to behavioral transparency and does not repeat structural data.

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

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

The tool has a simple schema, rich annotations, and an output schema. The description covers purpose, edge cases (None, ambiguity), alternatives, and advanced ledger behavior, leaving no significant gaps for an agent to invoke it correctly.

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

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

The schema already provides 100% coverage for the single 'id' parameter, including the format ('Full 32-char memory id or a unique prefix'). The description does not add meaning beyond the schema; it reinforces the same idea but does not introduce new semantic details.

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

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

The description opens with a specific verb and resource: 'Fetch one memory by id or unique id prefix.' It clearly distinguishes from sibling tools like memo_search and memo_list by focusing on retrieval by identifier, and it explicitly states the possible return outcomes (full record, None, ambiguity error).

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 states when to use alternatives: 'Use memo_search or memo_list first when you do not know the id.' This gives clear contextual guidance for choosing the right tool and when not to use memo_get.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the exact information returned (model id, dimensions, normalization, provider) and its relevance to semantic search. 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?

The description is three sentences, front-loaded with the main action ('Return the active embedding model profile') followed by read-only note and detailed use case. Every sentence contributes value 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 zero parameters, comprehensive annotations, and existence of an output schema, the description fully explains the tool's purpose and the kind of data returned. It also provides context on when to use it (compatibility verification), making it complete.

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

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

The tool has zero parameters, so baseline is 4. The description does not need to explain parameters, but it effectively explains what the output contains, which adds meaning beyond the input 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 it returns the active embedding model profile and lists specific fields (model id, vector dimensions, normalization, provider). This directly addresses the tool's purpose and distinguishes it from siblings, as no other tool retrieves embedder profile details.

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 says 'Read-only' and provides use cases: inspecting model details and verifying compatibility with stored vectors or external retrieval components. While it doesn't list when not to use it, the context is clear and sufficient for a simple 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?

Annotations already declare read-only, idempotent, and non-destructive hints. The description adds substantial behavioral context: the memory-only default, how include_code folds in the codegraph, the meaning of 'why' as a weighted path, and cursor-driven pagination for architecture. This goes beyond the annotations and clearly explains what the tool returns and how it behaves.

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 thorough but well-structured: a one-line summary followed by a bulleted list of verbs with concise explanations. It is front-loaded with the main purpose and no sentence is redundant. Despite its length, it is appropriately sized for the tool's complexity.

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 12 parameters, 7 verbs, and an existing output schema, the description covers all operational aspects: verb definitions, parameter roles, default behavior, include_code toggle, pagination via cursor, and limits. The output schema provides return details, so the description is complete for effective tool selection and 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?

The schema already describes all parameters, so the baseline is 3. The description adds value by mapping verbs to parameters (e.g., 'path' uses a and b, 'impact' uses cwd, 'neighbors/explore' use entity or a) and by explaining the semantics of include_code and cursor. This is more than the schema alone 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 opens with a clear verb+resource statement: 'Navigate the entity knowledge graph (read-only).' It then enumerates specific sub-operations (path, why, neighbors, explore, communities, impact, architecture), which distinguishes it from sibling tools like memo_search or memo_get. The scope is very clear.

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 each verb and explains the default memory-only behavior with include_code to add the codegraph layer. It does not explicitly name alternative tools or when not to use it, but the context is strong enough to infer its intended use-case.

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

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

Annotations already provide idempotentHint=true, and the description adds concrete behavior details: idempotent, returns {'consumed': false} for unknown/already consumed, and true only on first consume. This enriches the behavioral model beyond annotations. Score 4 because it does not cover all possible side effects (e.g., what happens to other agents seeing the handoff).

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: one sentence for purpose, one paragraph for behavioral details. Every sentence is informative and necessary. No redundant or vague language.

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, the presence of an output schema (so return values need not be fully detailed), and the behavioral explanation, the description covers all necessary aspects for correct usage. It is complete and self-contained.

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

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

Schema covers 100% of parameters with descriptions. The tool description does not add additional meaning to parameters beyond what is already in the schema. 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 states the action ('mark a handoff consumed'), the resource ('handoff'), and the purpose ('stops surfacing to later agents'). It effectively distinguishes from sibling tool memo_handoff_create, which creates handoffs.

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 (consuming handoffs to stop surfacing) but does not explicitly state when to use or not use this tool, nor provide any alternatives. It lacks explicit guidance on when-not or comparison to 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?

The description adds behavioral context beyond annotations: notes that the handoff is journaled, durable, and surfaces in operational state until consumed. Annotations are minimal, but the description compensates well.

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: one for primary purpose, one for key behavioral details. 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 schema completeness and presence of output schema, the description explains the lifecycle (created, persists until consumed) and purpose. Minor omission: no mention of effects on operational state beyond surfacing.

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 already clear. The tool description provides high-level context (e.g., 'for another agent or session') but does not add significant per-parameter 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 clearly states the tool creates a durable handoff for another agent or session. It uses specific verbs and resources, and the distinction from the sibling 'memo_handoff_consume' is evident.

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

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

The description implies the tool should be used to pass work to another agent, but lacks explicit when-not-to-use or alternatives. However, the sibling context provides differentiation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by noting that short ids are 'resolved safely' and that ambiguous prefixes return an error list, which is behavioral context beyond the annotations. It doesn't contradict annotations.

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

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

The description is three sentences, front-loaded with the core purpose, and every sentence adds value. It's concise without being under-specified, and the structure flows from general purpose to specific usage guidance.

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 moderate complexity (3 optional params, 100% schema coverage, output schema present, and strong annotations), the description is complete. It covers the tool's purpose, usage context, and key behavioral nuance (short id resolution) without needing to explain return values since an output schema exists.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal extra meaning beyond the schema, but it does reinforce the purpose of filtering by op and id. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool lists recent memory history events, with a specific verb ('List') and resource ('memory history events'). It distinguishes itself from siblings by mentioning audit trails and filtering by op and memory id, which is unique among the many memo_* 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 explicitly says when to use it: 'Use for audit trails across the corpus or filter by op and memory id when investigating a specific write, update, delete, forget, or reindex action.' It also implies when not to use it (for searching content, use memo_search) and mentions safe short id resolution, providing clear context 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?

Description adds behavioral context beyond annotations: it is a write tool that saves to memo records, and dry_run prevents writing. No contradiction with annotations (destructiveHint=false, etc.). Minor gap: does not discuss rate limits or auth, but adequate given 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?

Efficient and front-loaded: first sentence states action and type ('Write tool'). Subsequent sentences provide usage guidance and dry_run behavior. No unnecessary 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 purpose, usage, and parameter behavior. Assumes knowledge of 'idle capture' and 'session transcript', but context signals indicate siblings and annotations. Has output schema, so return values are covered. Minor gap: prerequisites like session existence are implied but not explicit.

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 a brief description for dry_run. The tool description adds meaning by explaining the effect of dry_run in context ('no memories are written and the response only reports what would run'), which is more explicit than the schema's 'Preview what would be saved without writing anything.'

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 'Run idle capture... Extracts durable insights... saves as memo records.' It distinguishes itself as a write tool, contrasting with sibling read tools like memo_search and memo_ask.

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 when to use ('after a meaningful unit of work, or periodically for clients without Stop hooks') and when not to use ('Do not use for normal lookup; call memo_search, memo_ask, or memo_unified_briefing'). Also explains dry_run mode.

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 destructiveHint=true, but description adds that the record is retained and readable, and that invalid_at is set in frontmatter and index. This context goes beyond the annotation to clarify non-destructive nature of the 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?

Two sentences with no fluff. Purpose is front-loaded. Every sentence adds necessary 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?

Given output schema exists and schema coverage is full, description adequately covers the tool's behavior, side effects, and parameter 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 coverage is 100%, baseline 3. Description adds value by explaining the effect of parameters: 'at' defaults to now, 'reason' is sanitized and logged. This supplements the 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?

Description clearly states the action: 'Close one memory's truth-validity interval without deleting it.' It uses a specific verb-resource pair and distinguishes from siblings like memo_delete by noting the record is retained.

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 as an alternative to deletion ('without deleting it') but provides no explicit guidance on when to choose this over related tools like memo_forget, memo_supersede, or memo_update. No 'when not to use' or comparison.

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

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

Annotations already declare the tool as read-only and idempotent. The description adds that it performs verification, which is consistent. However, it doesn't disclose what happens during verification or potential outcomes.

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, one sentence. It front-loads the purpose but may be too terse for clarity. However, it contains no fluff.

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 an output schema (not provided), the description could be larger. It lacks context about verification scope, process, or return values. Adequate 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?

The tool has no parameters, and schema coverage is 100%. While the description could explain why no parameters are needed, it's not required. Baseline 4 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 'Verify every native operational hash chain' uses a specific verb ('verify') and resource, clearly distinguishing it from other memo tools. However, it could be more explicit about what 'native operational hash chain' means.

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

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

The description provides no guidance on when to use this tool versus siblings or its prerequisites. No context about typical use cases 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavior beyond annotations: results are grouped, capped per category, scale with corpus size, and could exceed response budgets if not limited. This explains the limit parameter's rationale without contradicting 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 sentences, each earning their place: purpose, return characteristics plus rationale, and usage guidance. No redundant phrasing or filler. Front-loaded with the core verb and resource.

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 an output schema exists, the description is complete for a read-only lint tool with one optional parameter. It covers what is returned (grouped findings), key constraints (limit, scaling, response budget), and the follow-up action (use other tools to fix). No important 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?

Schema description coverage is 100% for the single 'limit' parameter, which already explains its default and the 'counts' field. The description reinforces the cap behavior but adds little novel meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Inspect') and resource ('memory corpus') with a clear scope ('maintenance issues'). It distinguishes itself from siblings by focusing on audit/lint findings rather than retrieval, updates, or deletion, and explicitly names the categories of findings (malformed metadata, cleanup needs).

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 directs the agent to use memo_update, memo_delete, or vault edits separately to fix findings, making clear that this tool is for inspection only. This provides a strong usage guideline and differentiates it from mutation 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context: 'List recent memories' implying default sorting by recency, and 'Read-only' confirms the safety trait. No contradictions, and the description enriches understanding beyond 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 sentences with every line earning its place: purpose, usage guidance, and parameter context. Front-loaded with the verb 'List' and resource. No filler 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 the tool's simplicity (2 optional params, full schema coverage, output schema present, and clear annotations), the description is complete. It explains the browsing workflow, the filtering behavior, and the limit cap, which is sufficient for the 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?

Schema description coverage is 100%, so baseline is 3. The description mentions '`limit` caps the number of returned records' and 'optionally filtered by memory type', but these add no new meaning beyond what is already in the input schema descriptions. No value is added to parameter understanding.

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 lists recent memories with optional filtering by type, and explicitly differentiates it from other memo tools by positioning it as a browsing step before using get/update/delete/history tools. The verb 'List' combined with the resource 'memories' and scope is specific and 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 provides explicit guidance: 'Use this to browse the corpus before choosing an id for memo_get, memo_update, memo_rename, memo_delete, or history tools.' This tells the agent when to use this tool and what alternatives to use after, plus notes about the `limit` parameter.

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

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

The annotations already indicate idempotency (idempotentHint=true) and non-destructiveness (destructiveHint=false). The description adds valuable context by explaining that retries with identical evidence and actor are a no-op, which enhances transparency. It does not contradict any 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 extremely concise with only two sentences. The first sentence states the purpose, and the second addresses idempotency. Every sentence earns its place without any filler.

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

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

Given the tool has three parameters, an output schema, and annotations, the description provides sufficient context: purpose, idempotency, and a note on evidence sanitization. It does not fully explain 'verify the memory' or 'schedule its next review', but these are likely detailed in the output schema or elsewhere, so completeness is 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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds extra meaning by noting that evidence is sanitized before being persisted, which is not in the schema. This additional detail justifies a slightly higher score.

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

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

The description clearly states the tool records review evidence, verifies the memory, and schedules the next review. It uses a specific verb ('Record') and resource ('review evidence'), making the purpose clear. However, it does not explicitly differentiate from sibling tools like 'memo_review_due' or 'memo_get'.

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

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

The description implies the tool is used when reviewing a memory, but it provides no explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or exclusions. The usage context is implied but not detailed.

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?

Discloses idempotent behavior (deduplication), deterministic synopsis, and that offloaded blobs are excluded from auto-recall. These add context beyond annotations (idempotentHint=true) and enhance behavioral understanding.

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 paragraphs with front-loaded purpose, clear structure. Every sentence adds meaningful information 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 output schema presence and rich annotations, the description fully covers behavior: what tool does, when to use, idempotency, output format (types of fields), and how to retrieve content later with memo_get.

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 already documents parameters with 100% coverage. Description adds value by explaining verbatim storage, rejection criteria for content, and auto-generation for title when null. Minor improvement over 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 purpose: offloading bulky payloads out of the context window, content-addressed storage in reference-tier memory. It differentiates from memo_save by contrasting bulk dumps vs. curated durable facts.

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 when to use this tool ('bulk working-context dumps') versus memo_save ('curated durable facts meant to be recalled'). Also explains idempotency and auto-recall exclusion.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable behavioral context: it returns only open items unless include_closed is set, enforces a per-section limit, and explains why unbounded snapshots accumulate context cost.

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: a crisp summary of what is read, then a concise explanation of snapshot behavior, defaults, and cost rationale. No filler or redundancy; the key action is front-loaded.

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

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

With a rich output schema and parameter descriptions, the description adequately captures the tool's scope without needing return-value details. Its prose list omits 'signals' (present in the schema's limit description), but this is minor and readily filled by the schema.

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

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

Parameter schema coverage is 100%, with each parameter already documented (limit default 20, project scoping, include_closed false). The description references 'include_closed' and 'limit' but adds no new syntactic meaning; it reinforces the reason for the limit but does not expand on 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 opens with 'Read current focus, handoffs, attention items, conflicts, and outcomes,' clearly specifying the action and resource. This distinguishes it from sibling mutation tools like memo_focus_set or memo_handoff_create, which modify those items rather than read 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 establishes a clear read-only snapshot use case and explains default behavior (open items only, limited entries) and the cost rationale. It does not explicitly name alternatives or state when not to use the tool, but the read-only nature and aggregate scope make the intended context obvious.

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 declare idempotentHint=true, and the description elaborates on the mechanism: 'Idempotent per idempotency_key,' explaining that retries replay the stored outcome and reusing the key with a different payload is rejected. This adds useful detail beyond the annotation, though no other behavioral traits (e.g., side effects beyond stat updates) are disclosed.

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

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

The description is two sentences, front-loaded with the core action and followed by key context. Every sentence adds value, and there is no wasted text.

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 6 parameters (4 required) and an output schema exists, the description covers the essential purpose and idempotency. The mention of procedure promotion provides necessary context. It does not explain the output, but the schema covers that. Overall, it is sufficiently 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 each parameter already has a description. The description only adds context about idempotency_key's role in safety, but does not elaborate on other parameters like actor_id or artifacts. Thus, it adds marginal 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?

The description clearly states the action ('record') and the resource ('whether recalled memories helped a task succeed'). It distinguishes itself from sibling tools by explicitly mentioning its role as the signal for procedure promotion, setting it apart from related tools like memo_procedure_promote.

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 after recalling memories for a task, stating it 'feeds success/failure back into each cited memory's outcome stats.' While it does not explicitly list when not to use it, the context is clear. It would benefit from an explicit note that this is for outcome tracking, not for initial memory creation.

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?

Discloses beyond annotations: confirms destructive only to the notification queue, never deletes memories or transcripts, and explains the pop-and-remove behavior.

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

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

Well-structured with a clear first sentence, but slightly verbose with three sentences; could be trimmed slightly without losing 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?

Given no parameters and annotations present, the description fully explains behavior, return value, and usage context; output schema exists so return details are not 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?

No parameters, and schema coverage is 100%. The description adds context that the tool operates on the pending notification implicitly, meeting the baseline for zero params.

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 reads and dismisses a pending idle-capture notification, differentiating it from siblings like memo_search and memo_list for reading durable records.

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 when to use (after memo_idle_capture or before replying) and when not to use (for reading durable memory records, use memo_search or memo_list).

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 read-only and idempotent behavior. The description adds context about the specific subset of memories returned, but no additional behavioral traits (e.g., pagination, auth requirements) beyond annotations.

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

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

The description is a single, lean sentence with no wasted words. It is front-loaded with the key action and criteria.

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 output schema exists and annotations cover safety, the description sufficiently explains the tool's purpose. It is complete for a simple filtered-list tool with no hidden complexity.

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

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

Schema coverage is 100%, so parameters are well-documented. The description does not add any parameter-level details beyond what the schema provides, meeting the baseline for full coverage.

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

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

The description clearly states the tool's function: listing memories that are 'outcome-backed' and 'ready for procedural promotion'. It uses specific verbs and resource, and distinguishes itself from siblings like memo_list (generic list) and memo_procedure_promote (promotion 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?

No explicit guidance on when to use this tool versus alternatives. The naming and sibling list imply that it is a precursor to memo_procedure_promote, but the description does not state this or provide 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?

Annotations provide no safety profile (all false). Description adds that it creates a durable memory and rejects sources not meeting thresholds, but does not disclose other side effects like whether source memories are modified or deleted. More behavioral context would be helpful.

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 purpose, second adds rejection detail. No wasted words, but could be slightly more structured with bullet points.

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 6 parameters and an output schema (not shown), the description does not explain return value or effect on source memories. It says 'creates a new durable memory' but not whether sources remain unchanged. Adequate but not complete.

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

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

Input schema covers 100% of parameters with descriptions. Tool description adds little beyond schema (e.g., repeats threshold condition for 'kind'). Schema does the heavy lifting, 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?

Description clearly states the action: 'Promote grounded memories into a reusable procedure/failure pattern.' It uses specific verb and resource, and distinguishes from siblings like memo_procedure_candidates which likely lists candidates rather than creating the promotion.

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 mentions that sources must meet thresholds based on 'kind', but does not explicitly state when to use this tool vs alternatives (e.g., memo_procedure_candidates, memo_outcome_record). No guidance on when not to use.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds that results are bounded by budget_chars and include stable/active sections with evidence metadata, providing useful behavioral nuance beyond 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?

Description is a single sentence that conveys the core function efficiently. However, it uses jargon ('bounded stable and active memory') that may require prior context; a slightly more structured breakdown could improve 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?

Given the presence of an output schema and detailed parameter descriptions, the description is mostly complete. However, it does not explain what 'stable' vs 'active' memory means or how evidence metadata is structured, which could be ambiguous for an 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 description coverage is 100%; each parameter is well-documented in the schema. The description does not add additional meaning beyond what is already in the schema, so a baseline score of 3 is appropriate.

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

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

Description clearly states it returns bounded stable and active memory with evidence metadata. This is specific to the tool's function and distinguishes it from siblings like memo_search (search) and memo_context (context retrieval).

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

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

No guidance on when to use this tool versus alternatives such as memo_context or memo_unified_briefing. No indication of 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?

Annotations already declare read-only, idempotent, and non-destructive. The description adds value by detailing the type of metadata returned and noting that unknown ids return null, which is consistent 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?

Two sentences: first clearly states purpose, second provides usage context and specifics. Every word is valuable; 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?

Given the output schema exists, the description sufficiently covers what the tool does, when to use it, and what it returns (provenance metadata). It addresses the key use case without missing critical details.

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 description for the 'id' parameter is already detailed (full 32-char hex or unique prefix, git-style, returns null for unknown). The description repeats this without adding meaningful new information, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns provenance metadata for a memory, specifying the kinds of information (origin, lineage, file path, audit details). It mentions usage before trusting, editing, or citing, but could more explicitly distinguish from similar tools like memo_get or memo_history.

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 guidance on when to use: with a full id or unique prefix when needing audit details before trusting, editing, or citing. This sets context, though it doesn't explicitly mention when not to use or offer direct sibling comparisons.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, but the description adds valuable behavioral context beyond that: it specifies chronological ordering, supports full id or unique prefix (with prefix resolution), and explains that `limit` caps events while `has_more` reports truncation. This enriches the agent's understanding of how the tool behaves without contradicting 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 three sentences, front-loaded with the primary action, and every sentence adds value. It avoids redundancy, is concise, and is well-structured for quick parsing by an 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 the tool has only 2 parameters (both documented) and an output schema exists, the description is fully sufficient. It covers purpose, usage context, behavioral details, and parameter semantics. No additional information is needed for an agent to select and invoke 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?

Schema description coverage is 100%, so the schema already fully documents both parameters. The description repeats some of this (e.g., prefix resolution, limit capping) but adds the semantic note about `has_more` reporting truncation, which is a minor addition. Since the schema carries the heavy lifting, 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 starts with a specific verb and resource: 'Return recent history events for one memory in chronological order.' This clearly states what the tool does and differentiates it from sibling tools like memo_history (which likely covers broader history) by focusing on per-memory change 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 gives clear usage context: 'Use to inspect how a memory changed over time before editing or rolling back.' This tells the agent when to invoke this tool. However, it does not explicitly mention when not to use it or name alternative tools, so it misses the 'when-not/alternatives' element 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?

Annotations declare idempotentHint=true and destructiveHint=false. The description adds critical context: 'Writes only derived index state; markdown remains the source of truth.' It also explains the difference between errors (failures) and skipped (deliberate skips), which is important for understanding the tool's behavior. This goes beyond annotations without contradicting them.

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 (three short paragraphs) and front-loaded with the primary purpose. Each sentence serves a purpose: the action, the non-destructive nature, usage context, force explanation, and error semantics. No fluff 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?

The description covers all essential behavioral aspects: what it does, when to use it, the force parameter, and the error/skip distinction. An output schema exists (as noted in context signals), so return details are likely covered there. For a tool with moderate complexity, this is complete enough; could mention potential side effects (e.g., performance) but not 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 single parameter 'force' is fully described in the schema with its purpose and example ('e.g. after an embedder model swap'). The description's additional note '`force` reprocesses records even if memo thinks they are current' adds minimal extra meaning beyond the schema's coverage (100%). Baseline 3 is appropriate as the schema handles the semantics well.

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: 'Rebuild memo's searchable index from the markdown vault.' This is a specific verb (rebuild) with a clear resource (searchable index) and source (markdown vault). It distinguishes from sibling tools like memo_search (which searches) and memo_lint (which checks), making it clear this is about rebuilding the index.

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 explicit when-to-use context: 'Use after hand-editing vault files or changing indexing behavior.' It also clarifies the force flag and error interpretation. While it doesn't name alternatives or explicitly state when not to use it, the context is clear and sufficient for an agent to decide when to invoke it.

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

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

Annotations already mark destructiveHint=true; the description reinforces 'Destructive metadata edit' and adds context on behavior of omitted id (targets most recent save). 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?

Every sentence serves a purpose: first states action and scope, second flags destructive nature, third gives use case and parameter advice. No wasted words.

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

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

Given the annotations and output schema, the description covers purpose, usage, parameters, and behavioral traits comprehensively for a simple rename 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?

Schema coverage is 100% with descriptions for both parameters; the description adds practical nuance about when to omit id (only after a save). This justifies a score above baseline 3.

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

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

The description clearly states the verb 'rename' and the resource 'memory title', and explicitly distinguishes from siblings by noting 'without changing its body or tags' and referencing memo_update for editing other fields.

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 explicit when-to-use context ('after memo_save or memo_search when a record has the right content but the wrong title') and when-not-to-use ('Use memo_update instead when you need to edit content, type, or tags').

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 provide readOnlyHint=true and idempotentHint=true; description confirms read-only and adds behavioral details: no retrieval, adds 'rerank_score' field, drops non-dict entries, and handles disabled state gracefully. No contradiction 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 concise sentences front-load the purpose and key differentiator, then cover usage and edge case. No filler; 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?

Given output schema exists, description need not detail return values. It covers purpose, usage, behavior (including disabled state and score addition), and interaction with parameters. Annotations and schema complement fully.

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

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

Schema covers 100% of parameters with descriptions. Description adds extra meaning for hits (scored on title/snippet/body, adds rerank_score, drops non-dicts) and query (empty returns unchanged). This adds value beyond schema, justifying above baseline 3.

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

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

Description starts with 'Rerank candidate memory hits for a query', specifying a clear verb and resource. It distinguishes from sibling memo_search by stating it performs no retrieval of its own, making its unique purpose explicit.

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: after memo_search or another retrieval source, for answer synthesis. Also mentions an alternative (memo_search) and explains behavior when reranking is disabled, giving clear usage boundaries.

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

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

Annotations already declare read-only and idempotent behavior; the description adds filtering conditions but omits details like default sorting (covered in schema) or record scope (e.g., excludes deleted records).

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

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

Single sentence, 10 words, no redundancy – highly concise and 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?

Covers the essential purpose and conditions; output schema likely documents return values; slight omission of ordering or pagination details, but overall 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 covers all parameters with descriptions (100% coverage); the tool description adds no further meaning beyond the schema.

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

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

Clearly states the tool lists records with specific conditions (passed review date or open conflict), distinguishing it from generic list/search tools 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?

No explicit guidance on when to use this tool versus alternatives like memo_list or memo_search; the description only implies its purpose.

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 only carry readOnlyHint=false and destructiveHint=false (no strong assertions), so the description must disclose behavior, which it does thoroughly. It explains the extraction mode's return shape (extraction summary vs single record), the tag propagation to every fact, the fallback 'blob saved verbatim' behavior, the auto project:<repo> tagging logic including the global recall tier boost, and the authority-controlled key stripping in `extra`. This is rich behavioral context well beyond minimal requirements.

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 organized into clear topically-paragraphed blocks (purpose, extraction mode, scope, defer_embed), each earning its place. It is long but every paragraph addresses a distinct behavioral aspect necessary for correct usage. Shorter than the length would suggest given 9 parameters and several conditional behaviors it must explain.

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 9 parameters, an output schema exists (which presumably documents the extraction summary shape), and no strong annotations to lean on, the description fully compensates. It covers the two major sub-modes (extract vs normal), the scope/recall-tier mechanics, the defer_embed flow, cross-references memo_reindex, and notes CLI parity. For a tool this complex, this 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 is 3. The description adds meaningful value by explaining the interaction semantics between parameters: extract's decomposition behavior, scope's 'global'/None distinction and the project tag precedence ('An explicit project: tag in tags always wins'), and defer_embed's mirroring of the CLI flag with the extraction-mode exception. Parameters like title/type/auto_derive are adequately covered by schema 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 verb ('Persist `content` to memo') and resource, and explicitly distinguishes memo_save from memo_offload ('durable curated fact, decision, or preference' vs 'bulk dumps of working context'). The scope of what gets saved is precise and it differentiates from the closest 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 provides explicit usage guidance: 'Use memo_save for a durable curated fact, decision, or preference; use memo_offload for bulk dumps of working context.' It also explains mode-specific behaviors (extract vs normal) and how scope/auto_derive/defer_embed each alter behavior, giving the agent clear conditional decision-making 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?

Annotations (readOnlyHint=false) already indicate write operation. Description adds that it 'returns the saved memory id' and title is optional, providing useful behavioral context beyond 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?

Concise with front-loaded purpose 'Save a memory from text.' followed by clear details. Every sentence adds value 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?

With 2 params, high schema coverage, and presence of output schema, description explains purpose, return value, and parameter behavior adequately. Could mention that it's a simple save without conflict handling, but that is already implied by comparison with memo_save.

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

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

Schema coverage is 100%, so baseline is 3. Description adds that title is optional and auto-generated from first line, but this info is also in the schema description. No significant additional meaning beyond 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?

Description clearly states 'Save a memory from text' and 'Persists one plain note from text and returns the saved memory id.' It distinguishes from siblings by explicitly mentioning memo_save for more options and memo_idle_capture for transcripts.

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 when to use this tool: 'Use for quick client-agnostic saves when you already have the exact content to remember.' Also provides alternatives: 'Prefer memo_save when you need tags... Prefer memo_idle_capture for transcript-derived session insights.'

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 mark the tool as read-only and idempotent. The description adds value by confirming 'Read-only' and describing the return format ('raw ranked hits — source records with ids, dates, tags, and excerpts'). No contradiction 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?

Two sentences plus a list of alternatives. Every sentence is substantive and earns its place. The core purpose is front-loaded, and the alternatives are clearly enumerated. No wasted words.

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

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

Given the tool's complexity (11 parameters, no enums, has output schema), the description is fully adequate. It covers purpose, read-only nature, return type, and provides clear links to siblings. The output schema handles return value details, so the description doesn't need to.

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 description carries minimal parameter burden. It does not repeat or augment schema details, which is appropriate. Baseline score of 3 is correct.

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-resource pair ('Search durable memories') and immediately distinguishes the tool from siblings by naming three alternative tools (memo_context, memo_search_trace, memo_rerank). This meets the highest standard.

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 states when to use this tool ('for raw ranked hits') and directs the agent to three alternatives for different use cases (prompt-ready pack, diagnostics, reordering). This is exemplary 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?

Annotations already convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's job is lighter. It adds valuable context: 'Read-only. Debug variant... Returns the same style of hits as memo_search plus trace metadata that explains how candidates were selected and scored at each stage.' This enhances transparency without contradicting 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 two sentences long, front-loaded with the core purpose, and each sentence adds value. There is no fluff or redundancy. It is appropriately sized for a targeted debug tool variant.

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 (6 parameters with 100% schema coverage, output schema present, and a clear sibling relationship), the description is complete. It explains the purpose, usage context, and what distinguishes the output. No critical information is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on individual parameters beyond what the schema provides; it only mentions the output (trace metadata). No additional parameter semantics are added, so the score remains at 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 starts with 'Search memories and include retrieval trace diagnostics,' specifying the verb (search) and resource (memories) with a clear differentiator (trace diagnostics). It also explicitly distinguishes from the sibling tool memo_search by calling itself a 'debug variant' and stating its specialized use case.

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 explicit guidance: 'use it when investigating ranking, filters, or recall misses rather than for normal lookup.' This directly tells the agent when to choose this tool over memo_search, satisfying the dimension's requirement for context and exclusion.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds that the tool returns None for unknown session IDs, which is behavioral context not captured in annotations. The description also states 'Read-only', confirming the safety profile.

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

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

The description is three sentences, front-loaded with the purpose, followed by a concise usage directive. No extraneous information; every sentence adds value.

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

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

Given the presence of an output schema and 100% schema coverage, the description adequately covers the tool's purpose, usage context, and return behavior for unknown IDs. No gaps are evident.

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%, with the parameter description explaining prefix matching and null returns. The main tool description does not add new information about the parameter beyond what the schema provides, so baseline score 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 clearly states the tool fetches metadata for one memo session. It specifies the resource ('tracked memo session') and the action ('Fetch metadata'), and distinguishes from siblings by mentioning when to use it (after memo_session_list or memo_start_session).

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 explicit usage context: 'Use after memo_session_list or memo_start_session when you need the stored transcript path, project, checkpoints, or other session details.' It does not list explicit when-not-to-use scenarios, but the guidance is clear and helpful for 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds 'Read-only' and positions the tool for inspection, but this largely restates the annotation rather than adding new behavioral context.

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

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

The description is short, front-loaded with the core action, and every sentence serves a purpose: purpose, read-only nature, use case, and parameter scoping. There is no unnecessary elaboration.

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

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

For a simple read-only listing tool, this description is complete: annotations cover safety, the schema covers both parameters, and an output schema is present. The description communicates enough for an agent to select and call 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?

Input schema coverage is 100%, with both `limit` and `project` already described in detail. The description only restates that `project` narrows results and `limit` caps the count, adding no meaningful parameter meaning beyond the schema.

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

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

The description opens with 'List tracked memo sessions,' a specific verb-plus-resource statement, and clarifies it returns 'session ids, transcript paths, and project context.' This clearly distinguishes it from the various search/retrieval 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 says when to use it ('to find recent session ids, transcript paths, and project context for capture or inspection') and how to narrow results with `project` and `limit`. It does not explicitly name alternatives or say when not to use it, so it stops short of a 5.

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