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

With no annotations provided, the description carries the behavioral burden and does so well: deletion is hard and irreversible ('matching rows are gone, not hidden') and an unfiltered call is rejected. It does not cover permission requirements or response behavior, but the destructive traits that matter most are disclosed.

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

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

Three sentences with a front-loaded lead, an illustrative usage sentence, and a behavioral warning. There is no filler; the slight repetition of permanence reinforces the destructive nature rather than wasting space.

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 two-parameter tool with full schema coverage and an output schema, the description covers the key context: batch use, filter requirements, and hard deletion. The only minor gap is that the interaction between tag and age filters when both are supplied is not explicitly labeled as AND/OR, though the schema conditions imply both apply.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by stating that at least one filter is required even though the schema marks neither property as required, and it supplies concrete usage examples for both parameters.

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

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

The description names a specific verb and resource ('Permanently delete memories') and the exact filtering dimensions ('by tag and/or age'). The phrase 'prune stale facts en masse' clarifies batch scope and distinguishes it from the singular sibling tool forget_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?

It gives a clear when-to-use instruction ('Use this to prune stale facts en masse') with concrete examples (scratch tag, older than 90 days). It also states the safety precondition that at least one filter is required, though it does not explicitly name alternatives or when-not 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It clearly states the delete is permanent and irreversible ('the row is gone, not hidden'), which is essential for a destructive operation. It does not mention behavior for nonexistent IDs, but the permanence warning is strong.

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

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

Three concise, purposeful sentences: action, usage guidance, and behavioral warning. No filler or redundant information, and the most critical facts 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 one-parameter delete operation with an output schema, the description covers when to use it, what it does, the alternative, and the permanent consequence of invocation. Nothing essential 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 coverage is 100%, so the schema already documents memory_id sufficiently, including its source from previous store_memory or search_memory calls. The description adds little beyond restating 'by id', which is acceptable since the schema carries the semantic weight.

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 the exact action ('Permanently delete one memory by id') with a specific verb and resource, making the tool's function immediately clear. It is distinguishable from siblings like update_memory and search_memory based on the delete-per-id scope.

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 describes when to use the tool: when a memory is wrong beyond correction, sensitive, or no longer wanted. It also names the alternative update_memory for fixing rather than deleting, giving clear routing 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 behavioral transparency burden. It clearly states the operation is filtering and ordering only, with no embedding-based scoring, which is non-obvious and valuable. The read-only nature is implied by 'Enumerate' and 'browse', though not explicitly stated.

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

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

The description is compact and front-loaded with a clear one-line summary, followed by useful usage context and an important behavioral qualifier. Every sentence earns its place without redundancy.

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

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

Given the output schema exists and the input schema fully documents all parameters, the description provides the missing contextual pieces: when to use it, how it differs from search, and that it performs no semantic scoring. This is sufficient for an agent to select and invoke the tool correctly.

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

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

The input schema already provides 100% parameter descriptions, including defaults and semantics for tags, limit, order, and offset. The description adds high-level context about tag filtering, ordering, and pagination, but does not need to repeat schema details.

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

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

The description opens with a specific verb and resource: 'Enumerate memories with tag filtering, ordering, and pagination.' It immediately distinguishes itself from sibling search_memory by noting this is not a search query path and that no embedding model or scoring is used.

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 concrete use cases: auditing memories, paginating through tag categories, and viewing memories chronologically. It also implies the alternative (semantic search) by saying no embedding model or scoring is used, though it does not explicitly name search_memory as the alternative.

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. 'Report' strongly implies a read-only operation and the description discloses what it reports, but it does not explicitly state that it does not modify memories or mention any side effects, permissions, or freshness constraints. For a simple stats tool this is adequate but not fully transparent.

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

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

The description is a single, front-loaded sentence that covers all essential information without wasted words. Every phrase contributes 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?

For a zero-parameter read-only reporting tool with an output schema, the description is nearly complete. It tells the agent what kind of information to expect, though it could slightly improve by explicitly contrasting with list_memories or noting that this is an aggregate view.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because there are none to document, which is appropriate.

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

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

The description uses a specific verb ('Report') and resource ('memories'), and clarifies the scope by naming three concrete facets: storage location, count, and model. This distinguishes it from sibling tools like list_memories, which would return entries rather than aggregate statistics.

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 this tool is for aggregate memory statistics, but it does not explicitly state when to prefer it over list_memories or search_memory. An agent can infer the intended use from the content, but there is no direct guidance about alternatives or exclusions.

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

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

With no annotations, the description carries the behavioral burden itself. 'Re-read' makes the read-only nature clear, and 'most recent memories' conveys the ordering expectation. It does not mention error behavior or access restrictions, but for a simple read operation with an output schema, the key behavioral point is covered.

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 filler. The core operation is front-loaded, and the second sentence provides usage context and the key alternative 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?

For a simple read tool with two optional parameters and an output schema, the description covers purpose, use case, and the main alternative. It is only slightly incomplete in not contrasting with list_memories as a possible overlapping sibling for browsing memories.

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

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

Schema coverage is 100%, so the parameters are already documented, giving a baseline of 3. The description adds value by explaining where memory_id comes from (previous store_memory or search_memory) and tying the limit parameter to the 'catch up on recent memories' use case.

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 ('re-read') and resource ('memory'), and clearly distinguishes the two access modes: by id or by recent memories. It also differentiates from search_memory by explicitly reserving meaning-based lookup for that 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 gives explicit when-to-use guidance: use it when you already know the memory id from a previous store_memory or search_memory call, or to catch up on recent entries. It also states when not to use it by directing meaning-based lookups to search_memory.

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 transparency burden. It discloses that results are ranked by similarity, that ranking is stable for pagination, that pages don't overlap or skip, and that offset past the last match returns no results. This is meaningful behavioral detail beyond the schema. It doesn't explicitly say the operation is read-only, but 'search' strongly implies no mutation.

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

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

The description is tightly written in three short paragraphs. The core purpose is front-loaded, the example earns its place, and the pagination notes add essential operational detail without fluff. Every sentence contributes something actionable.

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

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

The tool has an output schema, so there is no need to restate return values. The description covers what the tool searches, how results are ranked, how to page reliably, and what happens at the end of results — all an agent needs to call it correctly. Combined with full schema coverage, this is complete for a search tool.

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

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

The schema already documents all five parameters with 100% coverage, so the baseline is 3. The description adds value by explaining the offset/limit relationship ('advance offset by limit — ranking is stable'), clarifying query semantics with a natural-language example, and noting edge behavior for out-of-range offsets. This goes beyond the schema's minimal field 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 opens with 'Find memories by meaning' and clarifies this is semantic search over everything stored, with a concrete example ('what database did we pick?' → 'we went with SQLite'). This clearly distinguishes it from siblings like recall_memory or list_memories, which likely operate on exact identifiers or literal listings.

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 a clear usage context: use it when you want to find memories by meaning rather than exact wording, and it explains pagination behavior. It does not explicitly name alternatives or state when not to use it, but the semantic-search framing makes the primary use case obvious enough.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the text is embedded locally and can later be found by meaning rather than exact words, which adds real behavioral context beyond the schema. It does not cover failure modes, overwrite behavior, or permissions, but for a simple store operation the key behavior—persistence and semantic retrieval—is clearly disclosed.

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

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

The description is compact and efficient: it opens with the core purpose, then provides selection guidance, and closes with a notable behavioral detail about embedding. No sentence is wasted, and the structure is well front-loaded for an agent scanning the definition.

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 only three parameters, full schema coverage, and an output schema, the description provides sufficient context: what to store, what not to store, and how storage works. It does not mention sibling alternatives explicitly, but the guidance is strong enough that an agent can invoke store_memory correctly without additional 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?

Schema coverage is 100%, so the schema already documents all three parameters clearly. The description adds general guidance about what content is appropriate ('durable facts... not transient chatter') but does not provide parameter-level detail beyond what the schema already offers. This matches the baseline for fully covered schemas.

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 names a specific action ('Save something worth remembering across sessions') and identifies the resource ('memory') with clear scoping: durable facts, decisions, preferences, and project context. It distinguishes itself from retrieval or management siblings by focusing on the act of persisting new information, and the 'not transient chatter' qualifier sharpens the boundary.

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

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

The description gives clear usage criteria: store durable facts, decisions, preferences, and project context, and avoid transient chatter. It implies this tool is for creation/persistence rather than retrieval or modification, but it does not explicitly name alternatives like search_memory or update_memory, so it stops short of full when-to-use-versus-alternatives 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 provided, the description carries full responsibility for behavioral disclosure. It clearly communicates that the tool mutates the original record, re-embeds changed text so search reflects the correction, and only modifies explicitly passed fields. This provides substantial behavioral context, though it does not mention reversibility or failure modes.

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, well-structured, and front-loaded with the core purpose. The first sentence states the action, and the second sentence provides targeted context without unnecessary detail. Every sentence earns its place.

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

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

Given the tool's moderate complexity, the presence of an output schema, and the description covering when to use it, what it does, and its side effects, the description is complete for selecting and invoking the tool correctly. The schema fully documents parameters, and the description handles behavioral 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic value beyond the schema by clarifying partial-update behavior: 'Only the fields you pass are changed.' This directly helps an agent understand that omitted nullable parameters preserve existing values rather than clearing them.

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 immediately identifies the specific operation: 'Correct an existing memory in place.' It clearly distinguishes itself from store_memory by stating it 'edits the original record rather than adding a related one,' making the tool's role unambiguous among the memory-related siblings.

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

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

Explicit usage guidance is provided: 'Use this when a stored memory is wrong — a misremembered decision, a misspelled name, a fact that has since changed.' It also explains what this tool is not for by contrasting with 'adding a related one,' effectively steering an agent toward store_memory for new information.

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