Mem0 Cloud

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

With no annotations, the description carries the full burden and does well: it discloses the extraction behavior, dedup rule ('Identical facts are stored once'), the auth requirement for memory_key, the privacy model, the 365-day retention, and the per-call price. It stops short of describing failure/edge behavior or limits beyond what the schema already states.

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?

It is a single dense but well-ordered paragraph: purpose first, then storage behavior, the entity-id precondition, retention, return shape, and price. Appropriately sized for a 12-parameter tool, though some parameter detail overlaps the schema and could be trimmed.

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

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

Given 12 parameters, no annotations, and no output schema, the description covers purpose, preconditions, behavioral traits, and even the return structure ({event_id, status, results:[...]}), compensating for the missing output schema. Minor gaps around error conditions keep it from being 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?

Schema coverage is 100%, so the baseline is 3, but the description adds a cross-parameter constraint the schema cannot express: at least one of the four entity IDs must be supplied. It also reinforces the secret nature of memory_key. Most other parameter detail (infer, expiration, includes/excludes) duplicates 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 states a specific verb and resource ('Store memories from a conversation') and its scope (durable facts extracted from messages, or verbatim with infer=false). It is clearly the write counterpart to the delete/get/search siblings, though it never names them for explicit contrast.

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 the prerequisite 'Needs at least one of user_id, agent_id, app_id, run_id' and explains the infer=false mode, which implies when to use it. However, it gives no explicit when-not-to-use guidance or routing to alternative tools such as search_memories or get_memories.

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 and does so: it discloses the 404 on foreign memory_id, the 200-item batch cap with a signal for remaining items, the memory_key authorization requirement ('other keys cannot delete your memories'), and a per-call price of $0.002. These are exactly the non-obvious traits an agent needs before invoking an irreversible operation.

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?

Front-loaded with the core action and then the two modes, cost last. Every sentence carries information, though the opening 'like mem0's delete memory and delete all memories' restates the title and is marginally redundant.

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 exists, and the description compensates by explaining what the call reports back ('says if more remain'), the destructive scope cap, the auth requirement and the cost. Nothing needed to call this correctly appears to be 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 baseline is 3, but the description adds real value beyond the schema: the cross-parameter constraint that at least one of user_id/agent_id/app_id/run_id is required for the bulk path, which is not expressible in the required list (only memory_key is required). It also clarifies the memory_id-vs-entity mutual exclusivity.

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 specific verb+resource ('Delete your stored memories') and immediately splits the tool into its two distinct operating modes (single memory_id vs. entity-scoped bulk delete). An agent can distinguish it from add_memory, get_memories and search_memories purely from the description.

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?

Gives explicit branching guidance: 'With memory_id: deletes that one memory... Without it: deletes up to 200... matching user_id, agent_id, app_id or run_id (at least one)'. The trigger conditions are clear, though it never names the sibling tools as the alternative for read/retrieve operations.

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 and does well: it discloses the auth model ('Requires your memory_key... a different key sees nothing'), error behavior ('404 if it is not yours'), result ordering ('newest first'), the page shape, and even cost ($0.002 a call). It omits the matching semantics across entity filters and the fields inside each memory, so it is strong but not complete.

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?

Dense but well ordered: purpose first, then the two modes, then the auth/price caveats. Every sentence carries information relevant to invocation. It is slightly long, but not padded, and the price/auth notes earn their 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 9-parameter tool with no annotations and no output schema, the description supplies the return page structure, auth requirement, ordering and error behavior. Remaining gaps are the internal fields of each returned memory and the exact semantics when multiple entity filters are combined.

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 genuine meaning on top: memory_id's 404-on-mismatch, the 'at least one of user_id/agent_id/app_id/run_id' requirement, and the '*' wildcard convention. The memory_key secrecy explanation also enriches the schema's text.

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 specific verb and resource ('Read your stored memories') and defines the two modes (single memory by memory_id vs a filtered page). The mem0 analogy in the title aids recognition. It does not explicitly distinguish itself from the sibling search_memories, which is the one gap keeping it off a 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?

Gives clear conditional context for each mode ('With memory_id... Without it...') and states the constraint that at least one entity filter must be supplied. It stops short of explicit when-not guidance or naming search_memories as the alternative for text-based retrieval.

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 and does well: it discloses the embedding-based mechanism, the 0-1 relevance scoring, the memory_key isolation guarantee ('only memories stored under the same memory_key are searched'), the response shape, and per-call cost ($0.004). It omits rate limits, error behavior, and pagination beyond top_k.

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?

Front-loads the purpose and mechanism, then constraints, then return shape, then price, in a few dense sentences with no filler. Every clause (scoping, filters rule, response shape, cost) 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 6-parameter nested-filter tool with no output schema and no annotations, the description covers the essential unknowns: auth/secret semantics, filter requirements, return structure, scoring range, and cost. An agent has enough 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?

Schema description coverage is 100%, so the schema already documents query, top_k, filters, threshold, memory_key, and show_expired in detail. The description restates the filters constraint and memory_key requirement rather than adding new semantics, so the baseline 3 applies.

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

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

States a specific verb (search), resource (your stored memories), and mechanism (by meaning: embeds the query and returns closest memories with relevance score 0-1). This semantic-search framing clearly separates it from get_memories (exact retrieval) and add_memory/delete_memories without needing to name them.

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

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

The description implies usage (semantic lookup) and states hard prerequisites — memory_key is required, filters must name at least one of user_id/agent_id/app_id/run_id. However, it never explicitly routes the agent between this tool and its siblings (e.g., when to use search_memories vs get_memories), so usage is inferred rather than prescribed.

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