Server Quality Checklist

Tool Scores

• delete_all_memoriesC
  2.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden. It discloses destructive behavior and the confirm requirement, but does not explain what 'in scope' means, whether the operation is reversible, or how it interacts with user_id/agent_id parameters. This is insufficient for a destructive action.

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

  Conciseness3/5

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

  The description is two sentences and concise, but it sacrifices necessary detail. While no sentence is wasted, the brevity leaves significant gaps, making it inadequate for the tool's complexity.

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

  Completeness1/5

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

  Given the tool has 3 parameters, 0% schema coverage, no annotations, and an output schema, the description is severely incomplete. It fails to explain scope, parameter usage, or behavior, making it nearly useless for an AI agent.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description adds no meaning to the three parameters. It only mentions 'confirm=true' without linking it to the confirm parameter. The roles of user_id and agent_id are entirely unexplained.

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

  Purpose4/5

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

  The description clearly states the verb 'Delete' and the resource 'all memories', which distinguishes it from the sibling 'delete_memory' that deletes a single memory. However, the phrase 'in scope' is vague and could be more precise.

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

  Usage Guidelines2/5

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

  The description mentions 'Requires confirm=true', which provides a necessary prerequisite but fails to advise when to use this tool versus alternatives like 'delete_memory' or 'search_memories'. No context on scope or user/agent filtering is provided.

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

• list_memoriesC
  2.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It adds one behavioral detail about response including 'ts' when feedback mode is enabled, but fails to explain core behavior such as scope determination (how 'in scope' is resolved), filtering logic, pagination, or side effects. The lack of any side-effect or safety mention is a gap.

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

  Conciseness4/5

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

  Two short sentences with the main action front-loaded. The second sentence adds a conditional behavioral note. No redundant or extraneous text. Every sentence earns its place.

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

  Completeness3/5

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

  An output schema exists, so return values are not required in the description. However, the description does not clarify what 'in scope' means, how the optional filter parameters (user_id, agent_id, memory_type) influence the result, or what the default behavior is (e.g., returning all memories if no filters set). This leaves the tool partially under-described for effective use.

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

  Parameters1/5

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

  The input schema has 0% description coverage, and the description does not explain any of the four parameters (top_k, user_id, agent_id, memory_type). There is no compensation for the missing schema descriptions, leaving the agent without semantic understanding of how these parameters affect the tool's behavior.

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

  Purpose3/5

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

  The description states the verb 'List' and resource 'memories', but 'in scope' is vague and does not clearly differentiate from sibling tools like search_memories. The negative hint 'Not a substitute for search_memories' implies a distinction but does not specify what list_memories actually does differently.

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

  Usage Guidelines2/5

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

  The description provides only a single negative hint about not substituting search_memories, without any positive guidance on when to use this tool versus alternatives like get_memory_by_id or update_memory. No when-not or alternative descriptions are given.

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

• delete_memoryC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the action without revealing whether the deletion is permanent, irreversible, or requires special permissions. The output schema exists but its content is not hinted at, leaving the agent uncertain about the tool's behavior.

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

  Conciseness4/5

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

  The description is a single sentence that is very concise and front-loaded. However, it is so brief that it sacrifices informational value. While it earns points for efficiency, it could be slightly longer to include critical details without losing conciseness.

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

  Completeness2/5

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

  Given the tool's simplicity (1 parameter, output schema exists), the description is incomplete. It does not explain what happens if the id is invalid, whether the operation is idempotent, or what the output contains. The agent lacks enough context to use the tool reliably without additional knowledge.

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

  Parameters2/5

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

  Schema description coverage is 0% and the parameter 'memory_id' has no description in the schema. The description adds only 'by id', which does not clarify the expected format (e.g., UUID, integer) or provide any guidance beyond the parameter name. 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.

  Purpose5/5

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

  The description 'Delete one memory by id.' clearly states the verb (delete), resource (memory), and method (by id). It distinguishes from sibling 'delete_all_memories' which deletes multiple memories, making the purpose 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.

  Usage Guidelines2/5

  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 like 'delete_all_memories' or 'update_memory'. There is no mention of prerequisites (e.g., memory must exist) or when not to use it. The agent is left to infer usage context.

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

• get_memory_by_idA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It adds a behavioral note about feedback mode, which is useful. However, it does not explicitly state that this is a read-only operation, nor does it disclose any other behavioral traits like permissions or side effects. The 'Fetch' verb implies read-only, but that's implicit.

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

  Conciseness4/5

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

  The description is two sentences with no extraneous content. The primary action is front-loaded. The second sentence adds relevant conditional information. It is concise and well-structured.

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

  Completeness4/5

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

  Given the tool's simplicity (one parameter, output schema present), the description covers the core functionality and adds a special condition. It does not explain error handling or return format, but the output schema covers return values. Overall, it is sufficiently complete for a fetch-by-id tool.

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

  Parameters3/5

  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 adds 'by id' which clarifies the parameter's role, but the parameter name 'memory_id' is already self-explanatory. The description does not provide format, constraints, or examples. For a single required parameter, this is minimally adequate.

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

  Purpose5/5

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

  The description 'Fetch one memory by id' clearly states the verb and resource. It distinguishes from siblings like search_memories (which searches) and list_memories (which lists all). The purpose is 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.

  Usage Guidelines2/5

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

  The description does not provide guidance on when to use this tool vs alternatives. It only mentions a conditional action (rate via rate_memory_call) but does not explain when to choose get_memory_by_id over search_memories or list_memories. No explicit when-to-use or when-not-to-use.

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

• rate_memory_callA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions the enabling mode condition and lists reason categories, but does not address idempotency, side effects, error handling, or permissions. This is acceptable but leaves significant gaps.

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

  Conciseness4/5

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

  The description is three sentences and gets to the point quickly. The first sentence states the action, the second gives usage scenarios, and the third lists reasons. It is efficient, though the list of reasons could be formatted more cleanly.

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

  Completeness3/5

  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, 3 required, output schema exists), the description covers the core use case and reasons but omits explanations for the 'helpful' and 'note' parameters. It also lacks details on prerequisites or error conditions. The output schema reduces the need to describe return values, but the input semantics are incomplete.

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

  Parameters3/5

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

  The description adds meaning for 'call_ts' (timestamp from response) and 'reason' (enumerates values), but does not mention the 'helpful' boolean or the optional 'note' parameter. Since schema description coverage is 0%, the description partially compensates but leaves two parameters completely unexplained.

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

  Purpose4/5

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

  The description clearly states the verb 'rate' and the resource 'prior retrieval by call_ts', distinguishing it from sibling CRUD/search tools. The phrase 'rate a prior retrieval' is specific enough to convey the feedback function, though the jargon about MEM0_LITE_FEEDBACK_MODE slightly reduces clarity.

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

  Usage Guidelines4/5

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

  The description provides concrete scenarios for when to call ('used a hit', 'missed a fact', 'irrelevant noise') and when to skip ('empty-and-expected results'). It does not explicitly name alternative tools, but siblings are clearly for memory management, not rating, so the guidance is sufficient.

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

• add_memoryA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description must fully disclose behavior. It explains how infer works (fact extraction vs. explicit input) and warns about content to avoid. However, it omits details like whether the tool is idempotent, what happens on duplicate text, or any authentication/permission requirements. The output schema exists but the description doesn't mention what is returned. This is adequate 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.

  Conciseness5/5

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

  The description is extremely concise: three bullet-pointed sentences plus a list of memory types. Every sentence earns its place – first states purpose, second gives infer guidance, third lists what to avoid. The memory type list is efficiently presented. No filler or repetition.

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

  Completeness3/5

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

  Given 6 parameters (1 required) and no schema descriptions, the description covers the core but not all. It explains text, infer, and memory_type well, but user_id, agent_id, and metadata_json are unaddressed. The output schema exists so return values need not be explained, but the missing parameter semantics reduce completeness. Adequate for basic use but not for full parameter understanding.

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

  Parameters3/5

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

  Schema description coverage is 0% so the description bears the full burden. It explains text (self-contained third-person fact), infer (extraction mode), and lists memory_type options. However, user_id, agent_id, and metadata_json are not described at all. The description adds value for three key parameters but leaves three others undocumented, which is a gap given the lack of schema descriptions.

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

  Purpose5/5

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

  The description opens with 'Store a memory' – a clear verb+resource pair that immediately identifies the tool's purpose. It distinguishes from sibling tools (update, search, etc.) by its creation focus, and adds context about preferred usage ('Prefer infer=false with a self-contained third-person fact'). This is 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.

  Usage Guidelines4/5

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

  The description provides explicit guidance: when to use infer=false vs infer=true, what memory types are available, and what not to store (secrets, small talk, tool dumps). It implies this tool is for new memories but does not explicitly contrast with update (e.g., 'use update_memory to modify'). Still, the guidance is actionable and reduces misuse.

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

• update_memoryA
  4.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool replaces memory text in place, implying a mutation. However, it does not mention whether the operation is idempotent, what happens to the old memory text, or if there are any side effects (e.g., updating timestamps). Given the lack of annotations, this is a minor gap, but the core behavior is clear enough to score a 3.

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

  Conciseness5/5

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

  The description is a single sentence with two distinct clauses, each earning its place: the first states the action, the second provides usage guidance. It is front-loaded and wastes no words.

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

  Completeness4/5

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

  Given the low complexity (2 required params, no nested objects, no enums) and the presence of an output schema, the description is nearly complete. It covers the purpose, usage, and parameter semantics adequately. The only missing piece is a brief note on return behavior (e.g., 'returns the updated memory object'), which the output schema might cover, but since the description doesn't reference it, it's a minor gap.

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

  Parameters4/5

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

  The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'text' is the new content and 'memory_id' identifies which memory to update, which is not explicitly stated in the schema. However, it does not provide format details (e.g., allowed characters, length limits) or explain the behavior of required fields beyond what can be inferred. The output schema exists but is not referenced, which is a minor omission.

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

  Purpose5/5

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

  The description uses a specific verb ('replace') and resource ('memory text'), and clearly distinguishes from siblings like 'add_memory' and 'delete_memory' by stating 'prefer this over delete+add when a fact changed.' This makes the purpose unambiguous and sets it apart from alternative tools.

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

  Usage Guidelines5/5

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

  The description explicitly tells the agent when to use this tool (when a fact changed) and when not to ('over delete+add'), directly comparing with sibling tools. This provides clear decision-making guidance with no ambiguity.

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

• search_memoriesA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses critical behaviors: query rewriting requirements, parallel search strategy, memory_type filtering, and post-search rating feedback loop. This surpasses what structured fields alone convey, making the tool's operation highly transparent.

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

  Conciseness5/5

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

  The description is 5 sentences, each adding unique value: semantic search definition, query rewriting rule, parameter filtering advice, feedback mode instruction. No filler, front-loaded with the core action. Every sentence earns its place.

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

  Completeness5/5

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

  Given 5 parameters (1 required), no annotations, and an output schema exists, the description fully addresses core usage, query preparation, parallel search strategy, and feedback integration. The presence of output schema reduces the need to explain return values, making it complete for a semantic search tool.

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

  Parameters4/5

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

  Schema coverage is 0% (no description in input schema), so the description must compensate. It adds meaning to query (rewrite to 3-6 keywords) and memory_type (decision, convention, anti_pattern, or omit). It does not detail top_k, user_id, or agent_id parameters, leaving some ambiguity, but covers the most critical ones well.

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

  Purpose5/5

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

  The description explicitly states 'Semantic search' and instructs rewriting queries to 3-6 keywords matching stored third-person facts, distinguishing it from siblings like get_memory_by_id (retrieval by ID) or list_memories (listing without semantic search). It mentions memory_type categories for parallel searches, providing specific verb+resource clarity.

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

  Usage Guidelines5/5

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

  The description gives clear when-to-use guidance: rewrite query to remove pronouns/question words, run 2-4 parallel searches with specific memory_type values, and when MEM0_LITE_FEEDBACK_MODE is enabled, rate matches via rate_memory_call. This explicitly differentiates from siblings and provides actionable usage rules.

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