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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that mem0 performs server-side extraction ('not every call creates a stored entry') and that the memory bucket is auto-derived from identity, with no way to specify the target. This is valuable non-obvious behavior. It does not mention potential side effects like overwrites or deduplication, but the disclosure is solid.

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 the main action. Each sentence adds value: purpose, when to use, the extraction caveat, and identity-based bucket. No redundant phrases or filler. It is appropriately sized for the tool's complexity.

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

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

The description covers the tool's purpose, invocation triggers, behavioral caveats, and identity constraints. With an output schema available, explaining return values is unnecessary. Sibling tools are easily distinguishable, and the edge case of extraction means the description is complete for an AI agent to select and 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?

Schema description coverage is 100%, so the baseline is 3. The description adds context about the overall purpose but does not elaborate on parameter-specific semantics beyond what the schema already provides (e.g., the 'role' default). It does not clarify how role affects extraction or storage, but the schema is sufficient for basic usage.

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 action ('Store a new memory... in long-term memory'), specifies the types of content (fact, preference, exchange), and distinguishes it from siblings by being the write operation (vs search/list/delete). It also adds nuance about server-side extraction, making the purpose fully concrete.

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 tells when to use it ('when you learn something durable... or on explicit request'), which is strong usage guidance. However, it does not explicitly mention when not to use it or name alternatives (though siblings are obvious). This is clear context but not a full when/when-not comparison.

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

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

With no annotations, the description carries the transparency burden. It discloses the critical behavioral trait that deletion is not scoped to a user ('mem0 deletes by id without a user filter'), which is a potential hazard. It also implies an identity/bucket context, adding value beyond the schema.

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

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

Two sentences, front-loaded with the core action, followed by a relevant caveat. No filler; every sentence contributes essential information.

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

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

For a single-parameter delete operation with an output schema, the description covers the action, parameter provenance, and a critical behavioral nuance. It is sufficiently complete for an agent to invoke the tool correctly without additional details.

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

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

The schema already documents memory_id as 'The id of the memory to forget (from search/list results)' with 100% coverage. The description reinforces this by explaining why ids must come from this identity's own results, adding meaningful context to the parameter's safe usage.

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

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

The description opens with a clear verb and object: 'Delete a single memory by its id.' This precisely states the tool's function and distinguishes it from siblings like search_memory, add_memory, and list_memories, which involve other operations.

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

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

The note 'ids should only be obtained from this identity's own search_memory / list_memories results' gives concrete usage guidance, explaining how to safely source the id and why (deletes without a user filter). It does not explicitly mention alternatives, but the scoping caution serves as effective when-to-use 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 provided, the description carries the full burden. It explicitly discloses that it lists all memories for the authenticated identity's bucket and describes the return structure (ids and remembered text). It does not mention ordering or pagination, but for a read-only list operation, this is sufficient contextual detail.

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

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

The description is two concise sentences, front-loaded with the specific action ('List all stored memories'), and includes a clear return value statement. Every sentence contributes value with no redundancy or fluff.

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

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

For a simple, no-parameter list tool with an output schema, the description fully covers purpose, scope, and return type. It mentions the authenticated identity's bucket and the returned fields, making it complete for this tool's complexity.

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

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

The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter-specific details because none are needed; the schema fully accounts for the empty parameter list.

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') and clearly identifies the resource ('all stored memories for your authenticated identity's bucket'). It distinguishes itself from sibling tools like search_memory by emphasizing 'all' and 'authenticated identity's bucket', leaving no ambiguity about what it does.

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

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

The description implies the tool is for retrieving all memories, but it does not explicitly state when to use it over alternatives like search_memory or add_memory. There is no mention of exclusions or alternative tool names, leaving the agent to infer usage from the word 'all' versus the sibling tool names.

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. It discloses that memory bucket is auto-determined from authenticated identity and cannot be specified, adding important behavioral context. It implies a read-only operation through the verb 'search', though it does not explicitly state that no modifications occur. This is sufficient for a search tool.

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

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

Three concise, well-structured sentences. The purpose is front-loaded, usage guidance follows, and the identity constraint is clearly stated. No verbose or redundant language.

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

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

The tool is simple with full schema coverage and an output schema, so the description need not explain return values. It covers purpose, usage timing, and a key identity constraint. It could have briefly mentioned strategies for effective queries, but overall it is complete for the tool's complexity.

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

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

Schema description coverage is 100%, with query and limit already described in the schema. The description adds no additional parameter-level detail, so the baseline of 3 is appropriate. The auto-bucket note clarifies that no identity parameter is needed, but that is a behavioral clarification rather than parameter semantics.

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

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

The description opens with a clear verb+resource statement: 'Search long-term memory for entries relevant to a query.' It specifically focuses on recall from earlier sessions, distinguishing it from sibling tools like add_memory, list_memories, and delete_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?

Explicitly states when to use: 'Call this at the start of a task (or whenever prior context would help) to recall what was learned in earlier sessions.' It provides clear context but does not explicitly name alternatives or when-not-to-use scenarios, such as using list_memories for browsing without a query.

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