Server Quality Checklist

Tool Scores

• forgetA
  4.3/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 does so well. It discloses key behavioral traits: performs a high-threshold semantic search (0.7), deletes up to 3 results, and returns a list of deleted memories or a message if nothing matched. It also clarifies the permanent nature of deletion ('permanently delete'). However, it doesn't mention potential side effects like error handling or confirmation prompts.

  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 well-structured and appropriately sized. It front-loads the core purpose, then provides usage guidelines, and finally details internal behavior. Every sentence adds value, though it could be slightly more concise by integrating some details (e.g., the 0.7 threshold is mentioned twice).

  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 (destructive operation with semantic search), no annotations, and no output schema, the description is quite complete. It covers purpose, usage, behavior, and parameter context. However, it lacks details on error cases, authentication needs, or rate limits, which would be helpful for a destructive 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 100% for the single parameter 'query', so the baseline is 3. The description adds some context by reinforcing the semantic search aspect and giving examples ('old database URL', etc.), but doesn't provide significant additional meaning beyond what's already in the schema description (which already explains semantic search and gives examples).

  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 purpose with specific verbs ('search for memories' and 'permanently delete the top matches') and distinguishes it from siblings (recall, remember, inject_context) by emphasizing deletion rather than retrieval or storage. It explicitly mentions what resource it operates on (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 provides explicit guidance on when to use this tool: 'when the user explicitly asks to forget something' or 'when you detect that a stored memory is no longer accurate.' It gives concrete examples (e.g., dependency upgraded, decision reversed, team member left), clearly differentiating it from recall/remember tools which are for retrieval/storage.

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

• recallA
  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 of behavioral disclosure. It explains key behavioral traits: the search is semantic (not keyword-based), returns ranked results with confidence scores, and returns empty results if no memories exceed the similarity threshold. It doesn't mention rate limits, authentication needs, or error conditions, but covers the core operational behavior well.

  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 efficiently structured with three focused paragraphs: purpose, usage guidelines, and return behavior. Each sentence adds distinct value - no repetition or wasted words. The information is front-loaded with the core functionality stated first.

  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 tool with no annotations and no output schema, the description provides good coverage of what the tool does, when to use it, and what it returns. It explains the confidence scoring mechanism and empty result behavior. It could benefit from mentioning the memory types available or error conditions, but overall provides sufficient context for effective use.

  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%, so the schema already fully documents both parameters. The description adds minimal value beyond the schema - it mentions 'semantic similarity' which relates to the query parameter, but doesn't provide additional parameter semantics. The baseline of 3 is appropriate when the schema does the heavy lifting.

  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 purpose with specific verbs ('search long-term memory', 'return the most relevant stored memories') and distinguishes it from siblings by mentioning semantic similarity and confidence scoring. It explicitly identifies what makes this tool unique compared to tools like 'forget', 'inject_context', and 'remember'.

  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 provides explicit guidance on when to use this tool: 'before starting a task, when the user references something from a past session, or when you need project-specific context.' This gives clear situational triggers and distinguishes it from alternative memory-related tools without being misleading.

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

• inject_contextA
  4.6/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 of behavioral disclosure. It effectively describes what the tool does (retrieves relevant memories, formats them into a block, returns count), what happens when no memories are relevant (returns empty), and the output format. However, it doesn't mention potential limitations like rate limits, memory constraints, or semantic matching accuracy.

  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 front-loaded with the core purpose, followed by usage guidelines and return behavior. Every sentence adds value without redundancy, and the three paragraphs efficiently cover purpose, usage, and output without unnecessary elaboration.

  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 tool with no annotations and no output schema, the description does an excellent job covering the essential aspects: purpose, usage context, parameter semantics, and return behavior. However, it doesn't detail the exact format of the 'formatted text block' or potential error conditions, leaving some ambiguity about the output structure.

  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 100%, so the schema already documents the single 'query' parameter. The description adds value by explaining the semantic nature of the retrieval ('retrieves memories semantically related to this description') and providing context about how the query should be formulated ('Describe the current task or topic in plain language'), which goes beyond the schema's technical specification.

  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 purpose with specific verbs ('retrieve', 'return') and resources ('memories'), distinguishing it from siblings by specifying it returns a 'single formatted context block' rather than individual memories. It explicitly contrasts with the 'recall' sibling tool, providing clear differentiation.

  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 provides explicit guidance on when to use this tool ('at the start of a complex or multi-step task') and when not to use it ('Prefer this over recall when you want a single ready-to-use block rather than a list of individual memories'). It names the alternative tool ('recall') and specifies the context where this tool is preferred.

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

• rememberA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It effectively describes key behaviors: the tool persists information across sessions, returns a confirmation message with preview, and provides concrete examples of appropriate content. However, it doesn't mention potential limitations like storage capacity, retention policies, or error conditions that might be relevant for a memory 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 front-loaded with the core purpose in the first sentence. Each subsequent section (when to call, return value, examples) adds specific value without redundancy. The examples are concrete and illustrative, earning their place by clarifying appropriate usage. No sentence is wasted or repetitive.

  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 tool with 2 parameters, 100% schema coverage, and no output schema, the description provides strong contextual completeness. It covers purpose, usage guidelines, behavioral expectations, and practical examples. The main gap is the lack of output schema, but the description compensates by explicitly stating what the tool returns ('confirmation message with stored content preview'). A perfect score would require more detail about potential edge cases or limitations.

  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 description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by providing concrete examples of good memory content ('User prefers TypeScript strict mode...') and explaining the practical application of memory types through usage examples. This helps the agent understand how to format content appropriately, though it doesn't provide additional technical details about parameters.

  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 purpose with specific verbs ('persist', 'recalled') and resource ('piece of information to long-term memory'). It distinguishes from sibling tools by focusing on storage rather than retrieval (recall), removal (forget), or injection (inject_context). The first sentence provides a complete, unambiguous statement of function.

  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 provides explicit guidance on when to use this tool: 'whenever the user states a preference, makes a decision, or shares context that should survive beyond the current conversation.' It offers specific examples of appropriate contexts (tech stack, coding conventions, project constraints, etc.) and distinguishes from alternatives by focusing on persistence for future sessions rather than immediate recall or context injection.

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