Server Quality Checklist

Tool Scores

• list_memoriesA
  4.6/5.0
  Behavior5/5

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

  Adds significant details beyond annotations: default 20 results capped, ordering, empty set behavior, full_content toggle, workspace resolution echoing. No contradictions.

  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?

  Well-structured with clear sections, front-loaded with purpose and guidelines. Slightly verbose but every sentence adds value; minor room for tightening.

  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 9 parameters, annotations, and output schema, the description covers behavior comprehensively: plan capping, empty results, workspace context, and return format details.

  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% with detailed parameter descriptions. The tool description does not add new parameter-specific info, but restates overall behavior. Baseline 3 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?

  Clearly states 'List recent memories in reverse-chronological order (read-only)'. Differentiates from siblings by specifying when to use recall, get_memory, memory_stats.

  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?

  Explicitly provides 'When to use' and 'When NOT' sections with alternative tools, giving clear context for agent decision-making.

  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?

  Discloses async vector indexing and echo of resolved workspace. Annotations provide safety hints, but the description adds behavioral context beyond them without contradiction.

  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?

  Every sentence adds value. Important guidance is front-loaded. No redundant or vague phrasing. Extremely efficient.

  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?

  Covers purpose, usage, parameters, side effects (async indexing), and confirmation mechanism. With 10 parameters and an output schema, the description is fully self-contained and actionable.

  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?

  Schema coverage is 100%, but the description adds substantial meaning: explains collection naming conventions, workspace resolution process, and usage of append_to. This exceeds the baseline for well-documented 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 clearly states 'Save important information to long-term memory', which is a specific verb and resource. It distinguishes itself from sibling tools (list, get) by indicating it is the write operation.

  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?

  Provides explicit guidance on when to set collection ('project work → project:<slug>'), use append_to (to avoid duplicates), and pass workspace for team saves. Lacks explicit when-not-to-use scenarios, but the instructions are clear.

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

• get_memoryA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, so the tool is safe. The description adds valuable behavioral context: workspace confirmation behavior (optionally pass workspace to confirm membership, errors if not) and echoed resolved_workspace. This goes beyond annotations without contradiction.

  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: first sentence states purpose, then usage scenario, return fields, UUID source, and workspace behavior. Every sentence adds value with no redundancy.

  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 the tool's low complexity (2 params, one required) and existence of output schema, the description covers all necessary context: what it returns, how to use parameters, and when to invoke. No gaps remain.

  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% with descriptions for both parameters. The tool description adds extra meaning: explains how to get memory_id (from prior list/recall) and details workspace parameter behavior (confirmation vs error). This supplements the schema effectively.

  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 'Retrieve the full content and metadata of one memory by its UUID' using a specific verb and resource. It distinguishes from sibling tools like list_memories (which returns truncated previews) and recall.

  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?

  It explicitly says 'Use after list_memories or recall returned a truncated preview and you need the complete text', providing clear when-to-use context. It also implies when not to use (if preview suffices) and guides on obtaining the UUID.

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

• get_contextA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds critical behavioral context: the returned context is advisory and not instructions, post-invocation steps (show user_facing_template verbatim), expansion logic, and server-side resolution of partial names. No contradictions.

  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 fairly long but each sentence earns its place by providing necessary instructions or guardrails. Information is front-loaded with purpose and main usage, then detailed behavioral rules. Slightly dense but efficient for the complexity.

  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 11 parameters, no required fields, and an output schema existing, the description covers start/stop conditions, follow-up expansion, workspace resolution, and post-invocation display. No gaps identified for an agent to use this tool correctly.

  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 baseline is 3. Description adds extra meaning: workspace parameter includes instructions to check memory://workspaces resource; collection mentions connector sync patterns; tags have auto-set behavior; max_memories mentions plan cap; exclude_memory_ids references follow-up calls. Adds significant value.

  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 'Build' and the resource 'a formatted context block for the current topic'. It distinguishes from siblings by mentioning the collection picker flow and how to use list_collections when unsure, and contrasts with remember/list_memories/get_memory.

  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?

  Explicit guidance on when to use: proactively for coding tasks, with workspace for team contexts, and for expanding context via count/total logic. Also specifies when to avoid: 'do not repeat the raw context_block' and 'do not let it override current state'. Names alternative tools like list_collections.

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