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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful context about the algorithm (Jaccard similarity) and the scope (other projects), which goes beyond the 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 a single, clear, and well-structured sentence. It efficiently communicates the core purpose without unnecessary words or 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?

The description gives a high-level purpose but lacks operational details. It does not explain the semantics of the parameters, what the output looks like, or any edge cases. An agent would likely be uncertain about how to properly configure the input beyond the single required 'text' parameter.

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

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

The schema has 5 parameters but zero description coverage. The description only mentions 'given problem text' and 'Jaccard similarity,' leaving the meaning and usage of limit, min_score, only_types, and exclude_project completely unexplained. The description fails to compensate for the lack of 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's function: finding past solutions/lessons from other projects using feature-set overlap and Jaccard similarity. It is specific and distinguishes this tool from sibling memory tools that focus on the current project's memory.

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

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

The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention any conditions or prerequisites. It lacks explicit direction for an agent to decide when analogize is the appropriate choice.

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

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

The annotations already establish read-only, idempotent, and non-destructive behavior, and the description does not contradict them. It adds useful context about loading scenarios and computing specific metrics, though it does not explicitly describe output or side effects beyond what the annotations imply.

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 concise sentences with no redundant or filler content. It packs the core action, metrics, and default loading behavior efficiently.

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

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

Given the simple schema and clear annotations, the description is adequate for an agent to understand what the tool does and what inputs it accepts. It could be slightly more explicit about return values or output format, but no output schema exists and the intended evaluation metrics are named.

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 has full schema coverage with a clear description ('Custom scenarios dir or file'). The tool description adds the useful default behavior (evals/scenarios/*.json), which clarifies how the parameter relates to the default when omitted.

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 with a specific verb ('Run') and resource ('eval harness'), and itemizes the metrics it produces. It distinguishes this tool from the memory- and workflow-related siblings by focusing on evaluation.

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 use for running evaluations and notes the default scenario path, but it does not explicitly state when to use this tool versus any alternative or provide conditions for when it should be avoided. There is no direct competing eval tool among siblings, but guidance is still minimal.

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, idempotent, non-destructive behavior, so the description does not need to restate these. It adds no additional side-effect information, but also does not contradict the 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 and contains no irrelevant information. Every word adds meaning.

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

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

There is no output schema, no parameter explanations, and no usage context. The description is too sparse to allow a user to confidently invoke the tool correctly.

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

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

Schema provides no parameter descriptions and the tool description does not explain the meaning or expected format of 'project' or 'description'. Essential parameter semantics are entirely absent.

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 (classify), the object (task), and the output (L1-L4 complexity plus suggested phases). However, it does not explicitly distinguish itself from sibling tools that might also handle task-related 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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context for invoking 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 indicate read-only, idempotent, non-destructive behavior. The description adds useful behavioral detail about surfacing past errors, lessons, related rules, and returning a risk score, with 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?

One compact sentence conveys the action, timing, content returned, and risk score. No filler or redundancy.

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

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

With no output schema, the description partially compensates by mentioning risk_score and the categories of returned information, but it does not describe the full return structure. Adequate for basic invocation, but not fully complete.

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

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

The schema has no field descriptions, and the description only clarifies 'path'. The 'limit' and 'project' parameters are left unexplained, so the description provides only partial compensation for the missing schema documentation.

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

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

Description states a specific action and resource: call to surface past errors, lessons, and related rules for a file path, and returns a risk score. This clearly distinguishes it from generic memory recall tools and ties it to a pre-edit workflow.

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 'BEFORE editing a file', giving a clear trigger for use. It does not name alternative tools or say when not to use it, but the primary use case is unambiguous.

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 readOnlyHint=false and destructiveHint=false, but the description does not disclose any side effects (e.g., whether it writes to a database or modifies files). It only mentions parsing and returning data, leaving behavioral traits ambiguous and not adding clarity beyond the minimal annotations.

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

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

The description is concise, using two clear sentences without redundant information. It efficiently conveys the core action and output, maintaining a clean structure that is easy to parse.

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

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

Given the tool's simplicity and lack of an output schema, the description provides a basic understanding of the return (chunk count + sample) but omits details like the exact output format or error conditions. This is a gap for an agent that needs to interpret results reliably, so completeness is only moderate.

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

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

The schema has three parameters (path, include, sample_limit), but only 'include' has a description. The description does not elaborate on any parameter meanings, and with schema coverage at only 33% (low), the description fails to compensate, leaving the required 'path' and 'sample_limit' under-specified.

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: parsing files or directories into semantic AST chunks across 8 languages, and it explicitly mentions what it returns (chunk count + sample). This distinguishes it from sibling tools, which are memory-related, making the purpose unmistakable.

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

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

The description implies usage for code parsing but does not explicitly state when to use this tool versus alternatives. Since all siblings are memory/workflow tools, the context makes usage obvious, but no explicit guidance on when not to use it is provided.

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

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

The description openly discloses the crucial side effect: adding a fact with the same subject-predicate but a different object supersedes the prior assertion, yet the full history is preserved. It also notes the temporal nature, aligning with the non-destructive annotation (destructiveHint false).

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

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

The description is concise and well-structured, using two clear sentences. It front-loads the primary action and then explains the key behavior and use case without unnecessary verbosity.

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

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

The description gives the core purpose and main side effect, which is adequate for a simple add-fact operation. However, given the low parameter coverage and lack of output schema details, it leaves gaps regarding parameter semantics and expected return behavior, making it only partially complete for an agent to use confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions only the three required parameters (subject, predicate, object) but leaves the other four (context, project, confidence, invalidate_previous) unexplained. The description does not clarify the role of these additional parameters, making it insufficient for full 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 the tool's purpose: to record a temporal fact assertion with subject, predicate, and object. It also specifies the context of use ('evolving architectural decisions') and the key behavior of superseding prior assertions while preserving 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?

The description provides a specific use case ('Use for evolving architectural decisions') and explains the supersede-and-preserve behavior, which helps distinguish it from other memory/knowledge graph operations. However, it does not explicitly name sibling tools or contrast with alternatives like kg_invalidate_fact.

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 and idempotentHint, so safety is covered. The description adds the key behavioral nuance of timestamp filtering, which is useful. However, it does not describe the return format, potential limits, or error conditions. Given that annotations cover the safety aspects, this is adequate but not exceptional.

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

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

The description is two sentences with no redundant words. It directly states the purpose and the optional behavior of the timestamp parameter. Every word serves a purpose, making it highly concise and well-structured.

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 query tool in a knowledge graph context, the description sufficiently explains how to use it: specify a timestamp for point-in-time valid facts, or omit for current ones. It distinguishes itself from timeline tools by focusing on a single time point. The unmentioned parameters are standard in such domains (subject, predicate, object) and likely understandable. A small deduction for not specifying the output shape, but overall it is complete enough for an agent to call 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?

Only the timestamp parameter is described in the schema and referenced in the description. The other five parameters (limit, object, project, subject, predicate) have no descriptions and are not mentioned. With schema coverage at only 17%, the description fails to compensate for the missing parameter documentation, leaving most of the parameters underspecified.

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 fact assertions valid at a specific timestamp, or current facts if timestamp is omitted. This makes the core purpose unambiguous without needing to inspect the schema. However, it does not explicitly distinguish itself from sibling tools like kg_timeline, so it loses a point.

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 a clear condition for usage: include timestamp for point-in-time queries, omit for current facts. This gives practical guidance, but it does not mention when to prefer this over other query tools or mention any limitations (e.g., pagination, ordering). The guidance is implicit rather than explicit.

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

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

The annotation marks the tool as destructive, and the description adds clarifying context by saying 'History is retained,' which indicates this is not a hard delete. It does not fully describe downstream query effects or how reason and project are used, but the core behavior is transparent.

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

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

The description is very short, front-loaded with the main action, and followed by a relevant retention note. It is concise and free of filler, though it is too terse to cover parameter semantics or usage alternatives.

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

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

With no output schema, no parameter descriptions, and no mention of return values, errors, or optional arguments, the description is not complete enough for an agent to confidently invoke the tool beyond knowing that it closes a currently valid fact and preserves history.

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 0%, and the description does not explain subject, predicate, object, reason, or project. The parameters are only listed as bare string fields, leaving an agent with no guidance about what values are expected or how they relate to the fact being invalidated.

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

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

The description identifies a specific action ('Close') and a specific resource ('currently-valid fact assertion'), and it adds the useful behavior that history is retained. It is distinguishable from sibling tools like kg_add_fact and kg_timeline, though it relies on 'close' rather than the tool's 'invalidate' wording.

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

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

The phrase 'currently-valid' implies the precondition that the fact must be active before invalidation. However, the description does not explicitly name alternatives or state when to prefer this over other KG tools, leaving usage mostly implied rather than directly guided.

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 that results are full and chronological, but it does not disclose the default limit, whether invalidated assertions are included, or how predicate/project filters affect results. Read-only and idempotent behavior are covered by 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?

A single concise sentence with no redundant or extraneous content; the core action and resource are 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?

For a tool with no output schema, the description conveys that a chronological history is returned, but omits filtering semantics and default limits, leaving some operational context implicit.

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?

With zero parameter descriptions in the schema, the text only adds meaning to 'subject' (the entity whose assertions are returned). limit, predicate, and project remain unexplained.

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

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

The description identifies the resource (chronological assertions for a subject) and implies retrieval via 'full history', distinguishing it from a point-in-time lookup like kg_at. It lacks an explicit verb but is clear in context.

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

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

No guidance is given on when to prefer this tool over siblings such as kg_at or kg_add_fact, nor any mention of use cases 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?

The description discloses the key side effect of auto-synthesizing a prevention rule into the rules table, which aligns with the readOnlyHint=false annotation. However, it does not clarify whether repeated calls with the same pattern create duplicate rules or are deduplicated, and it omits any mention of idempotency or potential side effects on existing data.

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 efficiently communicates the core functionality and the auto-synthesis behavior. It avoids unnecessary detail, though it could be slightly more structured by separating the parameter list from the side-effect explanation.

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 (8 parameters, side effects, pattern detection), the description provides insufficient context. It does not explain how the pattern is determined, what the rules table looks like, or the relationship with sibling tools like self_error_log or workflow_learn. The absence of an output schema and lack of examples further reduces completeness.

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

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

The description lists the required parameters (file, error, root_cause, fix, pattern) but does not explain their meaning or relationships, and the schema has no descriptions. Optional parameters like project, category, and severity are not mentioned at all, leaving their semantics unclear. The parameter names are self-explanatory but not fully defined, especially 'pattern' and how it differs from 'error'.

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 'Structured error capture' and lists the key parameters, making the tool's purpose apparent. However, it does not explicitly name the verb 'record' or 'log', relying on the phrase 'error capture' to imply the action, which is a minor gap.

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 after N errors with the same pattern, a prevention rule is auto-synthesized, hinting at when the tool's output becomes useful. But it does not explicitly state when to use this tool versus alternatives (e.g., self_error_log) or when not to use it, leaving usage guidance vague.

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, covering safety. The description adds useful behavioral details: ordering (newest first) and a row cap (Max 500 rows). It also clarifies the data source (intents table). No contradictions with annotations, and the added traits are relevant to invocation expectations.

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, compact sentence that front-loads the primary purpose (List recent user prompts) and then efficiently adds ordering, filters, and a limit. Every word contributes value; there is 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?

For a simple list tool with no output schema and annotations covering safety, the description is quite complete. It states the action, data source, sorting, filters, and a row limit. It does not describe the return format (e.g., fields of each prompt), but that is not critical for a straightforward read-only list. The absence of pagination details is mitigated by the limit parameter. Overall, an agent can call it correctly with the given information.

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?

With schema description coverage at 0%, the description must explain parameters. It explicitly covers 'project' and 'session_id' via 'Filter by project and/or session', giving meaning to those string fields. However, the 'limit' parameter is not clearly explained; the mention of 'Max 500 rows' appears to be a cap, but the relationship to the limit parameter (which defaults to 50) is ambiguous. Partial compensation for missing schema descriptions, but not complete.

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 (List), the resource (recent user prompts from the intents table), ordering (newest first), and optional filters. It is specific enough to distinguish from siblings like search_intents, which implies a search-oriented purpose. No ambiguity in what the tool does.

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

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

The description provides filtering options (by project and/or session) but does not explain when to choose this tool over alternatives such as search_intents, memory_timeline, or save_intent. There is no mention of when not to use it or any conditions that would make another tool more appropriate. Usage context is only implied by the action of listing recent prompts.

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 declare readOnlyHint=false, indicating the tool may have side effects, but the description frames it as a recall operation, which implies read-only behavior. It does not disclose any potential state modifications, performance implications, or other behavioral traits. The description adds no transparency beyond the functional modes, and the mismatch with the readOnlyHint is not directly contradictory but leaves the agent uncertain about side effects.

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

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

The description is two sentences, front-loaded with the core concept. Every clause adds value: the mechanism, the contrast with keyword search, and the special mode. No filler or redundancy.

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

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

While the description covers the tool's purpose and modes, it does not describe the return format or output structure. Since there is no output schema, the description should indicate what the tool returns (e.g., a list of memories, scores, or a composition result). It also omits any mention of parameter interactions or edge cases, such as how max_results and min_coverage behave together. These gaps leave the agent guessing about the response shape.

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 80%, so most parameters are already documented. The description adds meaningful context for the 'mode' parameter by explaining the composition mode's goal (minimum set of memories covering concepts). It also clarifies that 'query' is natural language for concept resonance rather than keywords. This goes beyond the schema's brief 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 performs associative recall through a knowledge graph, explicitly contrasting it with keyword search. It also distinguishes the two modes (recall and composition), which differentiates it from siblings like memory_search_by_tag and memory_timeline. The verb 'finds' and resource 'memories' are 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 explains that this is for associative recall rather than keyword search, implying when to use it. It also describes the composition mode for building solutions from parts. However, it does not explicitly name alternative tools or provide clear when-not-to-use scenarios, only a general contrast with keyword search.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. However, the description adds no additional behavioral context (e.g., that it returns a list without side effects), which is acceptable but not enhancing.

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 with no redundancy or fluff. It is efficiently structured, though it could benefit from a bit more detail without becoming verbose.

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 large number of sibling tools (many memory-related), the description is too sparse to provide adequate context. It does not hint at what 'concepts' specifically means, how this differs from other search tools, or any special behavior like returning linked memories when include_memories is true.

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

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

The schema provides descriptions for 3 of 4 parameters (type, query, include_memories), but the 'limit' parameter has no description, resulting in 75% coverage, below the 80% threshold. The description does not compensate by explaining any parameters, leaving the behavior of 'limit' ambiguous.

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 specific verbs 'List or search' and a clear resource 'concepts in the knowledge graph,' which distinguishes it from most sibling tools. However, it does not fully differentiate from other search-related tools like memory_search_by_tag or memory_recall, so it is not a perfect 5.

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

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

No guidance is provided on when to use this tool versus alternatives such as memory_recall, memory_search_by_tag, or memory_timeline. The description lacks any contextual cues to help an agent decide when to invoke this specific 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?

The description transparently states that records are merged, the longest version is kept, and shorter duplicates are superseded. This clearly implies a mutating operation even without an explicit warning about side effects.

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

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

The description is concise and well-structured, covering the action, strategy, and benefit in three short sentences without any redundant wording.

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

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

The description is complete enough for a tool of this complexity, covering the operation, the merge strategy, and the result. It does not describe return values, but no output schema is expected and the dry_run parameter helps imply preview behavior.

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

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

The input schema already provides complete parameter descriptions, including defaults and ranges. The description adds no further parameter-level meaning, so it meets the baseline but does not exceed it.

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

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

The description clearly states the operation: finding and merging duplicate or similar knowledge records. It also explains the merging strategy and the overall benefit, leaving no ambiguity about what the tool does.

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

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

The description explains the purpose and benefit, but it does not explicitly say when to use this tool versus alternatives like memory_delete or memory_search. Usage guidance is implied rather than directly 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?

Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false. Description aligns with these by saying it 'reports' and checks progress 'without interfering with active work,' adding useful behavioral context beyond the 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 two short sentences with the main action front-loaded. It includes only essential detail and no filler, making it easy to parse quickly.

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

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

Given the simple zero-parameter read-only nature of the tool, the description sufficiently covers what state is reported and why it is used. No output schema is present, so the listed output aspects (last-run, locks, recent activity) are enough context.

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

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

Tool has no parameters, and the empty parameter schema fully documents this. There is nothing additional for the description to explain, so parameter semantics are complete.

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 uses a clear verb ('report') and specifies the object (consolidation daemon state) plus concrete details like per-project last-run, active locks, and recent activity. It also states the intended purpose of verifying idle-project worker progress, making the tool's role 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?

Description explicitly says 'Use to verify the idle-project worker is making progress,' giving a clear use case. It does not explicitly name alternative tools or when-not-to-use conditions, but the context is sufficiently clear for this read-only status check.

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 read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds that it combines retrieval mechanisms, but does not explain actual processing steps, output format, or potential costs.

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

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

The description is short and front-loaded, with only minor filler in the 'brain thinking' metaphor. It could be more informative, but it does not waste 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 large sibling set and no output schema, the description leaves ambiguity about the return value, the meaning of 'context', parameter details, and how this differs from other memory tools. It is not complete enough for reliable selection.

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

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

Schema coverage is only 33% (1 of 3 parameters described). 'query' has a terse description, while 'project' and 'max_tokens' are undocumented, and the description does not compensate for these gaps.

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

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

States a verb and resource ('build optimal context for a query') and hints at internal mechanisms, but 'optimal context' and 'brain thinking' are vague. With many similar memory/context sibling tools, it does not clearly define what distinct artifact it produces.

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

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

No guidance on when to use this tool versus memory_recall, memory_search_by_tag, memory_context, or other siblings. No conditions, alternatives, or situational examples are provided.

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

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

Discloses that it performs a soft-delete and removes from search results and ChromaDB, aligning with the destructiveHint annotation. It does not explain whether the record is recoverable or how it interacts with related knowledge, but the soft-delete term implies reversible behavior. 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?

The description is concise and directly to the point, using only two sentences to convey purpose, effect, and usage condition. No unnecessary fluff or redundant details.

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

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

Given the simplicity of the tool with one parameter and no output schema, the description provides all necessary context: what it does, when to use it, and its effect. It is fully self-contained and does not leave the agent guessing about behavior or prerequisites.

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

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

The schema has full coverage (100%) with a single 'id' parameter described as 'Knowledge record ID to delete'. The description repeats the same information without adding extra context, such as how to obtain the ID or validation rules, so it adds no new 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 (delete), the resource (knowledge record), and the effect (soft-delete, removes from search and ChromaDB). It also gives a usage context ('when knowledge is wrong or no longer relevant'), distinguishing it from other memory tools that might retrieve or update.

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

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

Explicitly states when to use the tool ('Use when knowledge is wrong or no longer relevant'). It does not mention alternative tools, but the sibling list includes memory_forget and kg_invalidate_fact, so a brief comparison would have been helpful; however, the provided condition is sufficient for basic usage 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 indicate readOnlyHint=false and idempotentHint=true, and the description adds some context about pronoun behavior and matched_via. However, it does not disclose the potential side effect of creating a new entity when create_if_missing is true, which is a significant behavioral aspect not covered by annotations alone.

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 mostly concise and well-structured, packing method, behavior, and return values into a short paragraph. The inclusion of 'v11.0 W1-F' at the start is extraneous and could confuse, but does not significantly harm 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 moderate complexity (5 parameters, one required) and no output schema, the description provides sufficient high-level context (return values, special behavior) but lacks detail on parameter semantics and side effects. It is adequate for a basic use case but not comprehensive for edge cases.

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 only 40% (type and threshold have descriptions), and the description text does not elaborate on the undocumented parameters (mention, project, create_if_missing). Without additional explanation, an agent may not understand the full meaning of these parameters, especially 'mention' and 'create_if_missing' behavior.

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: resolving a mention to a canonical entity within a project+type, using cross-session coreference via name/alias index and embedding cosine. It also specifies the return values (canonical_id, matched_via, is_new) and the special case for pronouns returning -1, leaving no ambiguity about purpose.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It only explains the basic operation without context on ideal scenarios, prerequisites, or when another tool (e.g., memory_save or memory_search_by_tag) would be more appropriate.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context such as result ordering, pagination, or what constitutes an 'episode'. It is consistent with annotations but provides no extra value beyond 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?

A single, front-loaded sentence that states the purpose and search dimensions with zero waste. It is appropriately concise for a straightforward search tool.

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

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

With 6 parameters, no output schema, and no parameter descriptions, the description is too sparse. It fails to clarify what an 'episode' is, how impact is measured, what the default limit means, or what the return structure looks like. An agent calling this tool would lack critical information 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 only 17% (only the query parameter has a description). The tool description lists the searchable fields (concepts, outcome, project, impact) but does not explain their semantics or how they interact. Parameters like min_impact and limit are not elaborated, leaving agents to infer meaning from names alone.

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

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

The description clearly states the tool finds past episodes and lists the search dimensions (concepts, outcome, project, impact). It distinguishes from many sibling memory tools by focusing on episodes, though it does not explicitly name an alternative to differentiate from, leaving some ambiguity against memory_recall or memory_timeline.

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

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

No guidance on when to use this tool versus alternatives. It does not mention when to prefer it over memory_recall, memory_timeline, or memory_search_by_tag, nor any exclusions or prerequisites. The usage context is implied but not explicit.

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

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

The annotations already indicate this is not read-only, not idempotent, and not destructive, so the behavioral profile is partially known. The description adds that it saves an episode, but does not specify side effects like whether it updates an existing episode or always creates a new one. It does not contradict the 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 concise sentences, front-loading the action and then elaborating on the nuance. Every word contributes to the purpose, with no fluff or irrelevant detail. It is appropriately sized for a tool of this 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?

The description gives the core purpose and hints at the type of content to include, but it does not explain the required parameters or the meaning of the outcome enum, nor does it address potential side effects or return values. Given the moderate complexity of 8 parameters, this leaves gaps for an agent trying to call it correctly. It is not fully 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 description coverage is 50%, with outcome, project, approaches_tried, and frustration_signals lacking descriptions. The description does not clarify any of these parameters, instead focusing on the overall narrative concept. It fails to compensate for the missing schema details, so parameter semantics are weak.

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 (save) and the object (an episode) with a specific definition of what an episode is (narrative of what happened and how). It contrasts with just saving facts, which distinguishes it from memory_save. This is a clear, specific purpose.

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 for recording narrative journeys, including what was tried, failed, and worked, which gives a clear use case. It contrasts with facts, suggesting use when a richer account is needed, but it does not explicitly name alternatives or conditions. This provides moderate guidance but falls short of explicit when-to-use instructions.

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/non-destructive, and the description adds useful behavioral details: it requires balanced/deep mode and returns {status: 'not_implemented', ...} if unavailable. 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?

The description is one sentence, but the leading 'v11.0 Phase 8:' is unnecessary metadata that does not help an agent decide to invoke the tool. The rest is reasonably concise.

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 explains purpose and a failure condition, but it omits what a successful run returns, leaves fixture_path unexplained, and does not clarify mode values beyond the contradictory requirement. It is not complete enough for reliable 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 coverage is 0%, and the description does not explain fixture_path. It mentions mode must be balanced/deep, which actually contradicts the schema default of 'fast', making mode semantics confusing rather than helpful.

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 runs contradiction_detector against a labelled fixture, which distinguishes it from other memory_eval_* siblings. The version/phase prefix adds some noise, but the core purpose is 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?

It states a prerequisite ('Requires balanced/deep mode') and a fallback behavior for missing module, but it does not explicitly explain when to choose this over the many sibling eval tools or how it fits among them.

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

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

The annotations already indicate read-only, idempotent, and non-destructive behavior, so the bar is lower. The description's 'verifies' aligns with these annotations, but it does not add context about what happens on failure, whether a report is returned, or any side effects beyond the 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 sentence with no extraneous words, and the main verb 'verifies' is front-loaded. It is compact and to the point, though the density of technical terms slightly reduces clarity.

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

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

No output schema or return value is described, which is important for an evaluation tool. The description also lacks context about how this fits into the broader memory evaluation workflow or what 'canonicalization stability' means in practice, making it incomplete for an agent operating in a complex domain.

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 fully documents the 'mode' parameter with an enum (fast/balanced/deep) and a default value, so coverage is high. The description adds no additional meaning or usage detail for the parameter, leaving the baseline score of 3 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 a specific verb ('verifies') and a specific resource ('entity_dedup canonicalization'), and the phrase 'across repeated saves of variant tag spellings' narrows the scope. It is distinct from sibling evaluation tools by focusing on entity consistency, though the jargon is dense and not fully explained.

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

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

No guidance is provided on when to use this tool versus the many sibling evaluation tools (e.g., memory_eval_long_context, memory_eval_temporal). There is no mention of use cases, prerequisites, or alternative selection criteria, leaving the agent without direction on 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?

The description discloses the key behavioral detail of forcing MEMORY_MODE=fast, which is not covered by the annotations. Since the annotations already indicate read-only, idempotent, and non-destructive behavior, the description adds useful context 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 a single, well-structured sentence that concisely conveys the action, input source, default behavior, and return fields. There is no extraneous information, making it highly efficient.

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

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

Given the tool's moderate complexity (4 parameters, no output schema), the description provides the return fields and default mode, which is helpful. However, it omits details about scenario format or output interpretation, leaving minor gaps for a fully autonomous 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?

The schema description coverage is 50% (only limit and scenarios_path have descriptions). The tool description does not clarify the meaning of mode or top_k, nor does it explain the return field semantics beyond listing them. This leaves significant ambiguity for the agent.

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: running a LongMemEval-style recall+prevention scenario suite against the live store. It differentiates from sibling eval tools by specifying the scenario type, though it does not explicitly name the alternative 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 gives no explicit guidance on when to use this tool versus the many sibling eval tools (e.g., memory_eval_recall, memory_eval_temporal). It implies usage for LongMemEval-style scenarios but doesn't state conditions or alternatives directly.

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 states that the tool 'Saves N records', which implies write/create behavior, but the annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. This is a direct contradiction and could mislead an agent about side effects.

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

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

The description is brief and mostly to the point, but the opening 'v11.0 Phase 8' is version/phase noise that does not help an agent. The remaining sentences are functional but somewhat vague.

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 lacks enough context for an agent to confidently invoke the tool: it does not define what 'large-context recall' means in practice, what output to expect, how mode affects behavior, or how this evaluation relates to the many sibling evaluation 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?

The schema provides no parameter descriptions, and the description only loosely maps 'N records' to n_records and 'queries them at the tail' to the evaluation behavior. The meanings of mode and top_k, and the effect of their defaults, are not explained.

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

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

The description identifies a large-context recall scenario and states that it saves N records and queries them at the tail, which makes the core evaluation behavior clear. It is reasonably distinguishable from sibling memory_eval_* tools by the explicit 'long_context' tag mention.

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 only a subtle hint about reusing eval_harness scenarios tagged 'long_context', but does not explicitly say when to choose this tool over sibling evaluation tools such as memory_eval_recall or memory_eval_locomo. No clear use-case boundaries are provided.

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

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

The description adds little beyond the annotations. It mentions accepting a dataset path or built-in fixture but does not disclose expected side effects, return behavior, or how the benchmark is executed.

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 brief and to the point, with no redundant information. It efficiently conveys the core purpose in two sentences.

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 is incomplete for a benchmark tool. It does not explain what the benchmark measures, what output to expect, how to interpret results, or any additional context needed to use the tool effectively.

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?

Only dataset_path is implicitly referenced via 'dataset path or built-in fixture'. The parameters mode, limit, and top_k are not explained, and the schema provides no descriptions, leaving most parameters ambiguous.

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 indicates a generic recall benchmark and distinguishes it from memory_eval_locomo by referencing the same payload shape. It names the resource (recall) and implies evaluation, though it could be more explicit about the exact 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 guidance is provided on when to use this tool over alternatives. The reference to memory_eval_locomo is helpful but does not explain selection criteria or use cases.

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

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

The description discloses that it returns a 'not_implemented' status when modules are missing, which is a useful behavioral detail. However, it does not describe any other side effects, return formats, or error conditions beyond that, and the read-only and idempotent annotations already cover safety.

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

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

The description is a single sentence that directly states the purpose and a key behavior. It is concise and avoids unnecessary fluff, though it does include version and phase information that might be considered extraneous.

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

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

Given the simple schema and lack of output schema, the description provides minimal context. It does not explain what the tool actually returns (beyond the not_implemented case), how mode or limit influence results, or what temporal recall entails. This leaves significant gaps for an agent trying to decide whether to invoke it.

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

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

The input schema defines 'mode' with an enum and a default, and 'limit' as an integer, but the description does not explain their meanings or how they affect the operation. The enum values are self-explanatory to some degree, but 'limit' is left completely undefined.

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 it performs 'temporal recall using temporal_kg + temporal_filter', which gives a general sense of the operation, but the verb 'temporal recall' is vague and it does not clearly distinguish from sibling memory_eval_* tools. It also mentions a version and phase, which adds context but not clarity.

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

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

No explicit guidance is provided on when to use this tool versus alternatives. The mention of 'Phase 8' hints at a workflow, but there is no direct comparison to other memory_eval_* tools or any clear usage conditions.

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

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

The description discloses the key output behaviors: per-tier breakdown with raw scores, merged RRF list, rerank_applied flag, and embedding_space. It does not contradict the read-only, idempotent, and non-destructive annotations, and adds meaningful detail about what the tool returns beyond what annotations imply.

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, efficient sentence that immediately conveys the relationship to memory_search_fast, the added output details, and the intended use case. No unnecessary words or repetition.

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

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

The description explains the output structure and use case, which are important for a debugging tool. However, it lacks any explanation of the parameter semantics (especially type and project) and does not describe the expected behavior when parameters are omitted. Given the moderate complexity of the tool (5 parameters, no output schema), the description is only partially complete.

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

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

The schema provides zero parameter descriptions (0% coverage). The description only mentions embedding_space, leaving query, type, limit, and project unexplained. The parameter names are somewhat self-explanatory, but the enum values for type and the role of project are not described, so the description fails to compensate for the lack of schema documentation.

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

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

The description clearly states the tool's purpose: it is a variant of memory_search_fast that returns a per-tier breakdown for debugging search results. It explicitly names the sibling tool and the specific use case, leaving no ambiguity.

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

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

The description explicitly says to use it 'to debug why a record did or didn't surface for a query,' which provides clear usage guidance. However, it does not explicitly state when not to use it (e.g., for normal search use memory_search_fast), though this is strongly implied by the 'same as' phrasing.

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 read-only, idempotent, non-destructive behavior; description adds context by noting the export includes knowledge, sessions, and relations, and that save_to_file defaults to persisting to a backups directory.

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 deliver action, scope, format, and purpose with no filler or redundancy.

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

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

For a simple two-parameter tool with no output schema, the description adequately covers what is exported and why; it could be slightly more explicit about the return shape when save_to_file is false.

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 descriptions; the tool description does not add much beyond the schema, so baseline 3 is appropriate.

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

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

Description states a specific action (Export), a specific resource (all knowledge), a format (JSON), and a clear purpose (backup or migration), which distinguishes it from narrower memory retrieval 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?

Explicitly frames the tool for backup or migration scenarios, giving an agent clear context for when to choose it; no explicit alternative comparisons are needed given the broad export scope.

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

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

The description discloses that sessions are auto-captured on exit and that 'complete' marks them as processed, which are side effects. This is consistent with readOnlyHint=false. It doesn't mention any destructive actions, aligning with destructiveHint=false, but doesn't elaborate on state changes beyond marking processed.

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 concise sentences. The first states the purpose, the second gives the workflow. There is no redundancy or unnecessary detail, making it easy to parse and act on.

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

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

For a tool with 3 parameters and no output schema, the description covers the primary workflow and parameter usage. It doesn't mention output format, error handling, or chunking details, but given the simplicity and the presence of schema descriptions, it is sufficiently complete for an agent to invoke 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 covers parameter meanings (action enum, session_id required for get/complete, chunk for large transcripts). The description adds value by explaining the workflow order and how the parameters are used together, which goes beyond simple definitions. This is helpful, though not essential.

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: retrieving pending session transcripts for knowledge extraction, with a specific verb and resource. It also mentions automatic capture on exit, providing context. However, it does not explicitly differentiate from sibling tools like memory_get or memory_recall, so it's not a perfect 5.

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

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

The description provides a clear workflow: use action='list' to see pending, 'get' to read, then save via memory_save, and 'complete' to mark processed. It mentions a subsequent step (memory_save) which gives usage context. It doesn't explicitly state when not to use this tool or compare it to alternatives, but the workflow is helpful.

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 tool is marked destructiveHint=true, and the description mentions 'purge', which implies deletion. However, it does not explicitly state that purged records are permanently removed, that archived records are moved to a different location, or that the operation might affect linked data. The annotations cover the core destructive nature, but the description adds limited behavioral detail beyond the obvious archive/purge actions.

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

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

The description is concise and well-structured, using exactly two sentences. The first states the primary action and conditions, the second summarizes the benefit. No unnecessary words or redundant explanations are present; every part contributes to understanding the tool's function.

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