Server Quality Checklist

Tool Scores

• list_category_memoriesA
  3.7/5.0
  Behavior2/5

  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 adds a useful persistence note ('The categoryId persists across conversations') but fails to reconcile the claim 'Get all memories' with the schema's limit parameter (default 20), which could mislead an agent expecting unbounded results. It also doesn't mention pagination or return format.

  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 only two sentences and immediately front-loads the action and resource. Every phrase earns its place, with no redundancy or filler.

  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?

  The tool is a simple category-based list operation, but the description omits key behavioral details like the limit default and pagination, and since there is no output schema, it doesn't explain the return shape. It covers the purpose and primary use case but leaves gaps around cardinality and response structure, making it minimally complete.

  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 schema already documents all three parameters with descriptions, so the description adds little beyond a note that categoryId persists across conversations. The baseline of 3 applies due to 100% schema coverage; the added persistence note is peripheral and doesn't clarify the semantics of the limit parameter or the relationship between bucketId and categoryId.

  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 clearly states the action ('Get all memories') and the resource ('within a specific Smart Memory category'), which distinguishes it from siblings like search_memories or list_bucket_categories. It also references list_bucket_categories as a prerequisite, reinforcing its specific role.

  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 explicitly provides a condition for use: 'Use when a category's summary (from list_bucket_categories) indicates it's relevant to the current conversation.' This gives an actionable guideline and connects to the sibling tool that provides the category summary, though it doesn't contrast with search_memories or discuss when not to use it.

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

• list_bucketsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It explains the concept of buckets but does not disclose operational behaviors such as whether the list is sorted, paginated, or whether it includes only names or also metadata. As a read-only list, the lack of side-effect disclosure is acceptable 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 two sentences, front-loaded with the primary action, and includes a helpful example. There is no wasted wording or redundancy.

  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?

  For a zero-parameter read-only list tool, the description is largely complete. It explains the domain concept and gives examples, but does not specify the exact return structure (e.g., bucket names only vs. metadata). Without an output schema, a little more detail would have been beneficial, but it's still sufficient for basic usage.

  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 tool has zero parameters, so the baseline is 4. The description adds value by clarifying the meaning of 'buckets' as organizational folders, which is useful context even though no parameter documentation is needed.

  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 clearly states the tool lists the user's memory buckets with a specific verb and resource. It also provides concrete examples ('Work', 'Personal', 'Health') and distinguishes this from sibling tools like list_bucket_categories or list_category_memories.

  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 explicit guidance is given about when to use this tool versus alternatives like get_memories_and_buckets or search_memories. The description is self-contained but provides no exclusions or contextual decision help.

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

• get_full_conversationA
  4/5.0
  Behavior3/5

  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 adds context that the tool returns all messages without summarization and requires the conversationId from a specific source. It does not explicitly state read-only behavior, side effects, or error handling, leaving some gaps.

  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 three sentences, each providing valuable information: what it does, when to use it, and the required parameter source. It is front-loaded and free of filler.

  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?

  For a simple one-parameter retrieval tool without an output schema, the description covers purpose, usage context, parameter origin, and return value ('all messages'). It could be more explicit about non-mutating behavior or failure cases, but overall it is quite complete.

  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 100%, and the parameter description already states 'Conversation ID from the recall_chat_history sources array'. The tool description repeats this requirement but adds no new syntactic or format details beyond the schema.

  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 clearly states the verb 'Get', the resource 'complete transcript of a specific past conversation', and specifies 'all messages without summarization'. This distinguishes it from siblings like get_conversation_summary and recall_chat_history.

  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?

  It explicitly says 'Use when you need the raw conversation content' and indicates the prerequisite of obtaining conversationId from recall_chat_history. However, it does not explicitly mention when not to use it or name alternative tools, though the contrast with summary is implied.

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

• get_memories_and_bucketsA
  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. The verb 'Retrieve' and phrase 'see what the user has previously saved' imply a read-only operation, which is adequate. However, it does not disclose any potential edge cases, rate limits, or effects of the optional parameters, leaving some behavioral aspects undocumented.

  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 concise, consisting of two sentences that front-load the core function and then provide usage guidance. Every word earns its place, with no unnecessary repetition.

  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 moderate complexity (5 optional parameters, no output schema), the description adequately states what is returned (memories and buckets) and when to use it. It does not describe return value structure, but the absence of an output schema makes that less critical. The schema covers parameter details, so the description is reasonably complete.

  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 coverage is 100%, so parameter descriptions are already present. The description only adds meaning for bucketId via 'filtered by bucket' but does not elaborate on all, count, query, or latest. This aligns with the baseline of 3, as the schema handles most parameter semantics.

  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 clearly states the tool retrieves the user's saved memories and available buckets, with optional filtering by bucket. This specific verb+resource phrasing distinguishes it from siblings like search_memories and list_buckets by combining both functions.

  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 clear context: 'Use to see what the user has previously saved' and suggests using it at conversation start. However, it does not explicitly mention alternatives or when not to use the tool, so it lacks exclusion criteria.

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

• create_bucketA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full behavioral burden. It discloses the core mutation behavior (creating a bucket) and the agent instruction to request a name if missing. However, it does not mention potential error cases (e.g., duplicate name) or what is returned, which is a gap for a mutation tool.

  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 two short sentences with no filler. The first sentence states the action and purpose, the second provides guidance and examples. It is front-loaded and efficient.

  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?

  The tool is low complexity (single required parameter, no output schema, no nested objects). The description covers purpose, examples, and the required parameter well. It does not specify return value or duplicate handling, but for such a simple create operation, the description is reasonably complete.

  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 100%, and the schema describes 'name' as 'Name for the new bucket.' The description adds valuable context by giving concrete examples ('Work', 'Personal', 'Health') and instructing the agent to ask the user for the name if not provided, which enriches the parameter semantics beyond the schema.

  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 clearly states the tool's function with a specific verb ('Create') and resource ('new bucket'), and distinguishes it from sibling tools like list_buckets or update_or_move_memories. The examples 'Work', 'Personal', 'Health' add clarity about what a bucket represents.

  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 implies when to use this tool (to organize memories into folders) and provides a key procedural guideline: 'Ask the user for a name if not specified.' It lacks explicit alternatives or exclusions, but the context is clear enough for the intended simple operation.

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

• get_conversation_summaryA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses key behavioral traits: the transcript-vs-summary threshold and the requirement to use conversationId from recall_chat_history. It does not mention any potential side effects or permissions, but as a read operation, the description adequately conveys its safe nature.

  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 three sentences, each earning its place: purpose, behavior, and usage context. It is front-loaded with the core action and contains no redundant information.

  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?

  Despite having no output schema, the description provides sufficient context for a single-parameter tool. It explains both possible response types (transcript or summary) and the source of the required ID. The main gap is lacking a description of the response structure, but this is not critical for tool selection and invocation.

  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 schema covers the parameter completely with a description matching the tool description. The description adds no new meaning beyond that, so it meets the baseline of 3. No ambiguity exists about the parameter's purpose or source.

  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 clearly states 'Get details of a specific past conversation' with a specific verb and resource. It distinguishes itself from siblings by explaining the length-based behavior (full transcript vs AI summary) and explicitly references recall_chat_history as the source of the ID.

  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?

  It provides explicit when-to-use guidance: 'Use when the user wants to dive deeper into a conversation returned by recall_chat_history.' It also clarifies the conditional behavior based on token count. However, it does not explicitly state when not to use it or mention alternatives like get_full_conversation, so it lacks explicit exclusion criteria.

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

• search_memoriesA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It adds valuable non-obvious context: image memories may include temporary image_urls that expire after a few hours, and the search is hybrid (semantic + keyword) with ranking by relevance. This goes beyond the bare operation and helps the agent understand potential pitfalls.

  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 concise and well-structured. It front-loads the primary purpose, then adds the image URL caveat, and finally provides context and usage guidance. Each of the three short paragraphs serves a distinct purpose without redundancy or excessive detail.

  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?

  Despite having no output schema or annotations, the description covers the essential aspects: what it searches, how results are ranked, the presence of expiring image URLs, and when to use it. It could be more complete by describing the returned memory structure or mentioning default bucket behavior, but it is sufficient for a search operation with well-documented parameters.

  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 input schema covers 100% of parameters with descriptions (query, limit, bucketId). The tool description does not introduce additional parameter-level meaning, such as accepted formats or constraints. Thus, the baseline of 3 applies; the description doesn't go beyond the schema's already adequate 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 clearly states what the tool does: 'Search the user's saved memories using hybrid semantic + keyword search.' It includes a specific verb (search), a specific resource (saved memories), and a result description (ranked by relevance). It is distinct from sibling tools like search_uploaded_files, which targets files, and store_memory, which is for saving.

  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 a clear usage context: 'Use when looking for specific saved information.' This gives the agent a clear trigger for selecting this tool. However, it does not explicitly name alternatives or exclusions, such as noting that search_uploaded_files should be used for file content, so it doesn't fully differentiate between siblings.

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

• store_memoryA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral transparency. It explains that the tool saves to a persistent memory store and introduces buckets as organizational folders. However, it does not disclose potential side effects such as duplicate saves, overwrite behavior, authentication requirements, or what the response/return value looks like. This is adequate but not deeply 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 well-structured and appropriately sized: it opens with a one-sentence purpose, includes a clearly labeled 'WHEN TO USE' section with actionable guidance, and ends with a brief explanation of buckets. Every sentence adds useful context, with no filler or redundancy.

  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 (2 parameters, no output schema, no annotations), the description covers the essential aspects: what it does, why to use it, and the key concept of buckets. It lacks details about return values, error conditions, or behavior when a bucketId is invalid, but for a basic save operation it is reasonably complete.

  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 100%, so the baseline is 3. The description adds value by explaining that buckets are 'organizational folders' with examples, and by advising the agent to ask the user which bucket to use when unclear. This gives additional semantic guidance for the optional bucketId parameter beyond the schema's simple 'Optional bucket ID to store the memory in.'

  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 leads with a specific verb and resource: 'Save information to the user's MemoryPlugin account.' It clearly distinguishes this as a write operation compared to sibling tools like search_memories or list_buckets. The MemoryPlugin context and the 'WHEN TO USE' section further clarify its purpose of building persistent memory.

  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 'WHEN TO USE' section provides explicit context: 'Proactively save anything that might be useful for future context' and 'Err on the side of saving.' It also advises asking the user which bucket to use when unclear. However, it does not explicitly state when not to use the tool or mention alternative tools for retrieval, so it stops short of a full 5.

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

• recall_chat_historyA
  4.3/5.0
  Behavior4/5

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

  With no annotations supplied, the description carries the full burden and discloses return format (synthesized summaries with source metadata), date bound semantics (inclusive UTC), mode behavior (quality vs speed), and token consumption. It does not discuss failure modes or rate limits, but covers the most relevant behaviors.

  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 longer than average but well-structured with WHEN TO USE, HOW TO USE, and output-format note. Most lines earn their place, though the alias sentence adds little functional value.

  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?

  The description covers purpose, when to use, how to use key parameters, and return behavior, which is sufficient for a 9-parameter tool with no output schema. It omits edge cases like the 15-query parallel cap or failure behavior, but those are minor for selection/invocation.

  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?

  Although schema coverage is 100%, the description adds practical value by suggesting maxTokens range (300-1000), giving ISO 8601 date examples, and explaining parallel queries for complex topics. This goes beyond the schema's field descriptions without fully clarifying every parameter interaction.

  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 opening sentence 'Search and synthesize context from the user's past AI conversations' states a specific verb and resource, and the later note 'Returns synthesized summaries (not raw conversation logs)' distinguishes it from raw-log retrieval tools like get_full_conversation. The alias 'MemoryPlugin inject tool' reinforces its role in injecting recall context.

  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 WHEN TO USE section explicitly lists situations (past decisions, patterns, preferences, relationships, projects) and even suggests proactive use. It lacks explicit when-not-to-use instructions or named alternatives, so it stops short of a 5.

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

• update_or_move_memoriesA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context, such as 'If a name is given and no bucket exists with that name, one is created automatically,' and explains the single vs bulk operational modes. However, it omits details about side effects (e.g., what happens to the previous bucket/text) or whether the operation is reversible, which would be valuable for a mutating tool.

  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 well-structured and appropriately sized. It opens with a clear one-sentence summary, then provides a usage directive, followed by concise mode-specific instructions. Every sentence adds value, and the formatting makes it easy to scan.

  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 complexity (two modes, five optional parameters, no output schema), the description covers the essential operational context: when to use it, how to specify buckets by ID or name, and the auto-creation side-effect. It could be more complete by explicitly stating that memoryId or memoryIds is effectively required, and by mentioning the max 100 limit for bulk moves (though it appears in the schema). Overall, it is quite complete.

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

  Parameters5/5

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

  Despite full schema coverage, the description adds significant semantic value beyond the schema. It explains the relationship between parameters: 'Single memory: provide memoryId with optional text and/or bucketId/bucketName. Bulk move: provide memoryIds array with bucketId or bucketName.' This clarifies the valid combinations and mutual exclusivity, which the schema alone does not convey.

  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 clearly states the tool's function: 'Edit a single memory's text or bucket, or move multiple memories to a different bucket.' This uses specific verbs (edit, move) and resources (memories, bucket), making it easy to distinguish from siblings like store_memory or create_bucket.

  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 includes an explicit 'WHEN TO USE' section and clearly differentiates single-memory vs bulk-move scenarios. It does not explicitly name alternatives or state when not to use the tool, but the context is clear enough for an agent to decide.

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

• list_bucket_categoriesA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden—and it delivers. It details the return structure (fields, meaning, memory count), notes that recentMemories returns the 30 most recent memories, and explains how summaries serve as previews. It does not discuss edge cases like empty categories or missing bucket IDs, but overall it is transparent about behavior.

  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 well-structured: a one-sentence summary, clear bullet points for return fields, a line for recentMemories, and a final usage tip. It is appropriately sized and every sentence provides value without redundancy.

  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 only one parameter, no output schema, and no annotations, the description is remarkably complete. It explains the purpose, return data semantics, recentMemories behavior, and decision workflow. The only minor gap is the lack of explicit mention of behavior when Smart Memory is inactive or a bucket has no categories, but the description already implies these conditions.

  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 input schema already fully describes bucketId with 100% coverage. The description does not add new constraints or special semantics for the parameter itself, though it helps clarify the bucket context and what categories are. This aligns with the baseline of 3 when schema coverage is high.

  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 'List AI-generated categories within a bucket', which clearly states the action (list), the resource (categories), and the scope (within a bucket). It also distinguishes itself from the sibling tool list_category_memories by explaining when to load full memories.

  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 context on when to use this tool: when Smart Memory is active and memories are auto-categorized. It also explicitly directs the agent to 'Use the summary and additionalInfo to decide if/when to load full memories via list_category_memories', providing an alternative tool and decision heuristic.

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

• search_uploaded_filesA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral transparency burden. It discloses that MemoryPlugin file buckets persist across AI chats, and that the tool returns text passages with source file and page info. It doesn't mention potential errors or rate limits, but covers the main behavioral aspects.

  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 well-structured and concise: purpose statement, output summary, and a bulleted 'Use when' list. All sentences earn their place with no redundancy.

  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?

  The description fully explains what the tool does, what it returns, and when to use it, including a caveat for ambiguity. It lacks an output schema, so the description's mention of text passages with source/page info fills that gap. Minor omissions like empty-result behavior prevent a 5.

  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 coverage is 100%, so each parameter is described in the schema. The description adds context that file buckets persist across chats, which gives meaning to bucketId, but overall the schema does the heavy lifting. Baseline 3 is appropriate.

  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 clearly states the tool searches documents in the user's MemoryPlugin document library, explicitly excluding files uploaded directly to the conversation. This distinguishes it from sibling tools like search_memories and clarifies the exact resource being searched.

  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 'Use when' section provides explicit conditions: user mentions MemoryPlugin documents, or asks about 'my files' with no conversation files, and instructs to clarify if unsure. This gives clear guidance on when to choose this tool over alternatives and when to ask for clarification.

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

• export_conversationA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries the full transparency burden and does so thoroughly. It discloses that the tool returns a temporary URL (15-minute expiry), requires no auth to fetch, and that the agent must fetch the URL itself to obtain structured message data with role, content, and timestamp. This provides clear behavioral expectations 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.

  Conciseness5/5

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

  The description is concise and well-structured: the first sentence front-loads the core action and result, the second paragraph provides contextual usage guidance. Every sentence adds value, with no redundancy or filler.

  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?

  For a single-parameter tool with no output schema, the description fully compensates by describing the return flow (temporary URL, expiry, fetch action, message structure). It also explains where to obtain the required input and how this tool relates to siblings, making it complete for agent decision-making.

  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 input schema already fully describes the single parameter (conversationId) with the source from recall_chat_history. Since schema coverage is 100%, the description adds no additional semantic detail about the parameter format or behavior beyond what the schema provides, matching the baseline for well-covered schemas.

  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 ('Download the complete transcript') and clearly identifies the resource (past conversation as JSON). It distinguishes from sibling tools by explicitly referencing get_full_conversation for short transcripts, and sets scope ('complete transcript', 'machine-readable JSON file').

  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?

  Provides explicit when-to-use criteria: when transcript is too long to read inline or when a file is needed for analysis/scripting. Also states when not to use it and names the alternative, get_full_conversation, and gives the source of the required conversationId from recall_chat_history.

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