Server Quality Checklist

Tool Scores

• healthA
  4.9/5.0
  Behavior5/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the non-destructive nature, the JSON envelope fields (status/services/components/queue), and the auth failure behavior. No contradiction with annotations.

  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 four sentences, each serving a clear purpose: stating the tool's nature, providing usage guidance, describing the return format, and noting an edge case. It is front-loaded and concise.

  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 health check tool with no parameters and an existing output schema, the description explains the return format and distinguishes the auth failure case. It fully covers the necessary context given the tool's simplicity and the annotations.

  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 schema description coverage is 100%. The description does not need to add parameter meaning. Baseline 4 for 0 parameters 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 performs a non-destructive runtime health check, specifically for use before memory tool calls. It distinguishes itself from sibling tools (memory.search, memory.write) by focusing on readiness and connection validation.

  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 specifies when to use: when a connection fails, startup seems incomplete, or readiness evidence is needed before writes. Also describes the auth failure scenario, indicating when not to expect a successful health check.

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

• memory.searchA
  4.9/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds: read-only nature, lifecycle handling (result_state with ready/pending/degraded/empty), grounding behavior (strict numeric copy), debug payload size impact, auth failure returns isError. 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 sections (parameter interactions, lifecycle handling). May be slightly verbose but every sentence adds value. Front-loaded with purpose and constraints.

  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 output schema exists, description explains return states and error handling. Covers all parameter interactions, lifecycle, and failure modes. Complete for a complex retrieval tool.

  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 description coverage is 100%. Description adds significant context beyond schema: topic_path for scoped retrieval with retry guidance, include_grounding strict copy behavior, include_retrieval_debug diagnostic value and payload cost, agent_id for profile consistency. Greatly enhances parameter understanding.

  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?

  Clear verb 'retrieval', specific resource 'memory', read-only nature stated upfront. Explicitly distinguishes from siblings: 'Do not use this tool for writes or health checks: use memory.write for persistence and health for startup/readiness checks.'

  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 (pre-inference recall) and when-not-to-use (writes/health). Offers detailed guidance on parameter usage: aligning project with prior writes, retry logic for topic_path, agent_id stability. Directly names alternative tools.

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

• memory.writeA
  5/5.0
  Behavior5/5

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

  Annotations are sparse (only false hints), so the description carries the burden. It discloses asynchronous side effects (fanout/indexing/rollup), acceptance semantics (ok=true with event_id but pending fanout), and error behavior (isError=true with structured payload). This far exceeds the minimal annotation information.

  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 structured into purpose, parameter interactions, side effects, usage exclusions, and error behavior. Every sentence contributes essential context, with no fluff or repetition. It is appropriately sized for a tool with async side effects and parameter interdependencies.

  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 complexity (state change, async fanout, error handling), the description covers purpose, parameters, side effects, when-not-to-use, and return semantics even though an output schema exists. It fully complements the structured information and leaves no significant gaps.

  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 meaningful context: projectName must match memory.search project, fileName is the lineage key for continuity/dedupe, topicPath controls partitioning and derivation, and content should be concise/factual. This enriches the raw schema with actionable 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 opens with 'State-changing durable memory write used for checkpoints, implementation decisions, and compact recall artifacts,' which clearly states the action (write), resource (durable memory), and intended use cases. It also distinguishes from siblings by explicitly directing to memory.search for reads and health for diagnostics.

  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 guidance for checkpoints, implementation decisions, and recall artifacts. It also gives clear when-not-to-use instructions: 'Do not use this for retrieval or diagnostics: use memory.search for reads and health for readiness checks.'

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