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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that search result contents are not logged and that results are newest first, which is useful. However, it doesn't state that the operation is read-only, doesn't mention pagination or limits, and doesn't clarify what happens when filters are empty. Some transparency is present but not comprehensive.

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

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

The description is two short sentences with no redundancy. The core purpose is front-loaded, and the caveat about search contents is a useful addition. It is concise and to the point, though it could be slightly more informative without losing conciseness.

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, return values are covered. However, the description does not explain the four parameters (all optional with defaults), nor does it provide usage guidance or prerequisites. It also doesn't mention any limitations beyond the content logging caveat. For a tool with no annotations and four parameters, this is incomplete.

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 for the parameters. It does not mention 'llm', 'tool', 'limit', or 'project' at all. The phrase 'who read what and when' hints at filtering by user/tool, but it doesn't map to specific parameters or explain their effects (e.g., limit is a count, tool filters by tool name). The description adds no value for parameter comprehension.

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 clear purpose: reporting who read what and when, with newest-first ordering. It implicitly distinguishes itself from siblings like read_memory or search_memory by focusing on an audit log rather than content retrieval. However, it doesn't explicitly say 'audit log' or mention that it returns a list, though the name and phrase 'who read what and when' make the intent 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?

No guidance is given on when to use this tool versus alternatives like search_memory or recent. It doesn't state whether to use it for access history, compliance checks, or filtering by user/tool/project. The description only describes what the tool does, not the conditions that select 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?

With no annotations, the description carries the disclosure burden and it does disclose ordering ('newest first'), content ('full content'), the default limit, and the llm parameter's audit-log purpose. It stops short of describing edge cases or whether the call has side effects beyond audit logging, 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 compact and front-loaded: the key use instruction appears immediately after the one-line purpose, followed by a tight parameter legend. Every line adds information, with no filler or redundant restatement of the schema.

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-style tool with an output schema, the description covers the trigger context ('resuming work'), the required parameter, the optional parameters, and ordering/default behavior. Nothing an agent needs to decide whether and how to call this tool 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 0%, yet the description compensates for all three parameters: project is identified as the project name, limit is documented with a default and ordering, and llm is explained as the agent name for the audit log. The project explanation is minimal and mostly restates the property title, so this is not a 5.

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 line 'Newest handoff summaries for a project, with full content' clearly identifies the resource (project handoffs) and the scope (newest, full content), and it is readily distinguishable from memory/search siblings. It lacks an explicit verb and does not name a sibling it is not, so it stops short of 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?

'Call this first when resuming work' is a direct, actionable usage instruction that tells the agent when to invoke this tool. It does not spell out when to prefer alternatives or what would disqualify this tool, but it provides clear contextual guidance.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It does state the filtering behavior ('at least one memory'), which is useful, but it says nothing about ordering, pagination, performance, or how inclusive 'every' is. This is adequate but not rich.

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

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

A single sentence with no filler. The key scoping condition is front-loaded, and every word earns its place.

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

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

For a simple listing tool with an output schema, the description covers the core selection logic. However, the unexplained optional 'llm' parameter and the lack of any guidance beyond the one-liner leave the agent with a meaningful gap in understanding how to call 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?

Schema description coverage is 0%, and the description does not mention the single 'llm' parameter at all. An agent cannot tell whether, when, or how to set it. The description was responsible for compensating for the schema gap and did not.

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 ('List'), a clear resource ('projects'), and a precise inclusion criterion ('has at least one memory'). This clearly differentiates it from the memory-focused sibling tools, though it does not explicitly name any alternative.

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

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

The intended use case is implied: call this when you need an enumeration of projects that have associated memories. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are mentioned.

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

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

With no annotations, the description carries the burden of disclosing behavior. It clearly indicates a non-mutating read operation that returns full memory content, but it does not describe failure modes, response format, or any side effects. There is no contradiction with the (absent) 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 tight sentences, no filler, with the core behavior front-loaded. Every sentence adds value: the first defines the operation, the second defines the critical parameter.

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-by-path tool, the description is largely complete: it states the operation, the provenance of the required parameter, and gives an example. It would benefit from stating the return format explicitly and explaining the optional `llm` parameter, but these are minor gaps given the absence of an output 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?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains `path` by stating it is the value returned by other tools and giving an example, but it completely ignores the `llm` parameter, which has a default and is optional but still undocumented.

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 and resource: "Read one memory in full." This clearly distinguishes it from sibling search tools that return partial or multiple results, and the example path grounds exactly what the agent receives.

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

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

It gives useful context by saying `path` is the value returned by other tools, implying 'use after obtaining a path from another tool.' However, it does not explicitly say when to prefer this over search_memory or search_memory_semantic, and it offers no exclusion criteria or alternative 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?

No annotations are provided, so the description carries the full disclosure burden. It does disclose the 'newest first' ordering and the audit-log behavior of the llm parameter, which is genuinely useful. However, it omits pagination behavior beyond limit, response composition, and whether this is a pure read operation. Decent but not rich for a tool with zero annotation coverage.

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 in a single opening sentence, followed by a compact, tabular parameter list with zero filler. Every line earns its place. Slightly more could be said about ordering semantics, but the structure is appropriately efficient.

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

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

With an output schema present, the description needn't explain return values, and complexity is low (3 optional params). It covers purpose, sorting, filtering, and limits. Minor gaps like pagination beyond limit and tie-breaking on equal timestamps exist, but the tool is simple enough that the current description is largely sufficient.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. Each parameter is explained: project (restrict to one; empty means all), limit (max results, default 10), and llm (name for audit log). This adds real meaning beyond the bare schema titles and defaults, fully compensating for the coverage gap.

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 line states a specific verb and resource: 'Latest memories of any type, newest first.' This is clear about what it does and implies ordering. It doesn't explicitly name the sibling alternatives it differs from, but the read-oriented listing purpose is distinguishable from search_memory and read_memory by the word 'Latest'.

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?

Usage is implied: the tool lists recent memories, which an agent would infer for 'what happened recently' queries. However, it gives no explicit when-to-use versus alternatives, no exclusions, and no mention of search_memory or search_memory_semantic for finding specific items. Acceptable but relies on inference.

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

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

With no annotations provided, the description carries the behavioral burden. It indicates a persistent write action, notes that 'type' is configurable via AI_MEMORY_TYPES, and recommends the llm parameter, but it does not disclose return behavior, error conditions, or side effects beyond saving.

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 sentence is front-loaded, followed by a compact, scannable per-parameter list. Every line adds necessary information with 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?

For a 6-parameter mutation tool with no schema coverage and no output schema, the description covers all inputs, required fields, formatting, and one configuration dependency. It could add what happens on save or any duplicate-handling behavior, but nothing essential is missing for invoking the tool.

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

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

Schema description coverage is 0%, so the description fully compensates: every parameter gets a concrete explanation, format constraints for project, allowed type values, Markdown support for content, and examples. This is far above typical parameter 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 opens with 'Save one memory' and enumerates the content kinds (decision, progress update, failure, handoff summary), giving a specific verb, resource, and scope. It is clearly distinct from the read/search-oriented 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 context is clear: this is the write-side tool among read/search siblings, so an agent can infer when to use it. It does not explicitly state when not to use it or name alternatives, but the sibling list makes the distinction nearly self-evident.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that all space-separated words must appear, that quotes and operators are treated as plain text (not FTS), and that it works with CJK substrings. It also mentions the llm parameter is for the usage audit log, adding operational context. It does not discuss result format or potential side effects, but for a read-only search this is sufficient.

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 efficient and well-structured: a two-sentence behavioral summary followed by a compact parameter list. It front-loads the key matching semantics and then documents each parameter without redundancy. It is slightly longer than strictly necessary but 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 tool has an output schema (not shown but present), the description need not explain return values. It covers the search behavior, language support, syntax limitations, and all parameter semantics. An agent has everything needed to call the tool correctly, including the audit log requirement for llm.

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%, meaning the schema provides no field-level guidance. The description compensates fully by explaining each parameter in the bulleted list: query, project, type, limit, and llm. It adds concrete semantics (e.g., 'restrict to one project', 'max results', 'your name for the usage audit log') that the schema alone does not convey.

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, specific verb-resource statement: 'Keyword search over titles, content and tags.' It explicitly distinguishes itself from semantic search by noting it is not FTS syntax and that every word must appear, which differentiates it from the sibling search_memory_semantic without needing to inspect the 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 explains when to use this tool by defining its exact matching behavior and noting it handles CJK substrings. It does not explicitly name alternative tools or state when NOT to use it (e.g., for fuzzy/meaning-based search), but the contrast with semantic search is implied. The behavior is clear enough for an agent to infer the appropriate context.

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

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

With no annotations available, the description carries the full behavioral burden and does it well: it discloses the external dependency on Ollama and nomic-embed-text, the failure mode when unavailable, the semantic behavior ('no keywords'), and the audit-log purpose of the llm parameter. This is substantial non-obvious context beyond the tool name.

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

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

The description is compact and well-structured: the core behavior and prerequisite are front-loaded, the fallback is stated immediately, and the parameter list is scannable. No sentences are wasted; each earns its place.

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

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

For a 4-parameter tool with no annotations, the description covers prerequisites, failure behavior, fallback, parameter semantics, and scope handling. Since an output schema exists, the lack of explicit return-format details is not a gap. The description leaves an agent with everything needed 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?

Even though the JSON schema has no property descriptions (0% coverage), the tool description fully documents all four parameters: query as a natural-language description, project as an optional scope with empty meaning all, limit as a max-results count with default 5, and llm as the audit-log name. This fully compensates for the missing 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 defines the tool as a meaning-based semantic search over notes, explicitly distinguishing it from keyword search by stating it 'finds related notes that share no keywords.' This makes it easy to differentiate from siblings like search_memory and read_memory without inspecting schemas.

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

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

It gives explicit when-to-use guidance: semantic search is appropriate when a natural-language query is needed, and if Ollama/model prerequisites are not met, the description directly instructs to 'use search_memory instead.' This is a clear, actionable fallback with no ambiguity.

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