Server Quality Checklist

Tool Scores

• memory_importA
  4.8/5.0
  Behavior5/5

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

  Thoroughly describes mutation, atomic writes, security (path traversal guards), failure modes, dedup, idempotency, and latency. No annotations provided, so full burden is carried.

  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, lists, and examples. Slightly verbose but each part justifies its length. Not overly terse.

  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 mutation tool with 2 parameters and an output schema (mentioned), description covers behavior, usage, failure modes, return format, and example. Very complete given context signals.

  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 covers 100% of parameters with descriptions. Description adds context on source_path formats, scope_id default, and examples, going beyond 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?

  Clearly states bulk import from file/directory/chat export. Distinguishes from sibling memory_save for single items and notes for incremental saves.

  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 lists when to use (initial bootstrap, absorbing decision logs, batch captures) and when not to use (incremental saves, session log mining). Names alternatives: memory_save and background miner.

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

• memory_saveA
  4.8/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 mutation behavior, security scan, dedup process, error handling, local-only data flow, atomic writes, and typical latency. It covers all important behavioral traits an agent needs to anticipate outcomes.

  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 well-structured with sections (Behaviour, Use for, Do NOT use for, Returns, Example). Every sentence adds value, though a few details could be tighter. Front-loaded with purpose, which is good for scanning.

  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 (4 parameters, multiple behavioral aspects, return values), the description covers everything an agent needs: input constraints, processing steps, output format, error messages, and a complete example. 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%, but description adds meaning beyond the schema: explains tags are used for filtering and recall scoring, suggests title format and character limits, describes content as atomic prose with rationale, and clarifies scope_id semantics. This exceeds the baseline of 3.

  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 begins with a clear verb+resource pair: 'Save a durable lesson, decision, or convention to persistent memory.' It distinguishes from siblings like 'transcript_search' and provides concrete examples, leaving no ambiguity about the tool's purpose.

  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 lists when to use (decisions, preferences, invariants, gotchas) and when NOT to use (session logs, trivial facts, speculative claims, duplicates). It also names an alternative (transcript_search) and explains what happens with duplicates, giving the agent clear selection criteria.

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

• transcript_searchA
  4.8/5.0
  Behavior5/5

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

  No annotations provided, so description fully covers behavior: read-only, no auth required, no rate limits, data access scope (reads ~/.claude/projects/**), idempotent, failure modes, retention window. 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.

  Conciseness4/5

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

  Well-structured with clear sections, but somewhat lengthy. Could be slightly more concise without losing clarity, but overall effective.

  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 and lack of annotations, description covers all necessary aspects: purpose, usage, behavior, parameters, return format, and failure modes. Output schema exists but description still adequately describes return format.

  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 useful context beyond schema: explains that query matches against raw session files, and limit controls number of excerpts returned. Provides example usage.

  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 it searches raw Claude Code session transcripts for conversation excerpts. Distinguishes from sibling tool memory_recall by specifying it searches raw JSONL files, not the mined memory corpus.

  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 lists when to use (e.g., recalling past conversations, verifying memory sources) and when not to use (e.g., durable knowledge lookup, listing memories), with specific alternative tool names.

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

• context_assembleA
  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 behavioral traits: read-only nature, telemetry bumps, authentication details, rate limits, data access scope, latency, idempotency, failure modes. This level of detail exceeds what annotations would typically provide.

  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 with sections, bullet points, and an example. It is front-loaded with a clear one-sentence summary. Every sentence adds essential information, matching the tool's complexity without unnecessary verbosity.

  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?

  The description covers all essential aspects: purpose, usage guidelines, behavioral details, parameters with example, return value specification, failure modes, and degraded mode. An output schema exists, but the description still provides necessary context on return format and typical content length.

  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?

  Input schema has 100% coverage with clear descriptions for both parameters. The description adds value by providing usage context, an example call, and clarifying the 'project' parameter's default behavior. However, the schema already does most of the work, so a 4 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's purpose: 'Assemble a query-tailored context briefing from all available knowledge.' It distinguishes from sibling tools by explaining it gathers memories, playbook, and transcripts, then synthesizes with Haiku. The verb 'assemble' and resource 'context briefing' are specific and unique.

  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 (starting a session, onboarding, decision-making) and when not to use (simple keyword lookups → memory_recall, listing memories → memory_list, finding past conversation → transcript_search). Also mentions degraded mode behavior, ensuring the agent knows the tool always returns something useful.

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

• memory_listA
  4.9/5.0
  Behavior5/5

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

  Provides extensive behavioral details: read-only, no auth, no rate limits, linear latency, filesystem access scope, idempotency, failure modes. No annotations provided, so description carries full burden and exceeds it.

  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?

  Well-structured with clear sections. Front-loaded with purpose and usage. Every sentence adds value. Appropriate length 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?

  Covers all aspects: purpose, usage guidance, behavioral transparency, parameter semantics, output format with example. Complete for a simple tool with one optional parameter.

  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 description adds meaning: clarifies default scope lists all projects, specific project name filters. The extra context elevates beyond baseline.

  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 the tool lists memories in a scope with counts and source breakdown. Differentiates from siblings like memory_recall and context_assemble. Describes specific use cases.

  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 states when to use (audit, check existence, preflight for cleanup) and when not to (searching, context briefing) with alternative tool names. Provides clear guidance.

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

• memory_recallA
  4.9/5.0
  Behavior5/5

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

  Even without annotations, the description thoroughly covers behavior: read-only, no auth, no rate limits, idempotence, data scope, failure modes, and the minor side effect of access-count telemetry. It fully discloses all behavioral traits an agent needs.

  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 with clear sections and an example. It is fairly long but every sentence adds value. Minor redundancy could be trimmed, but overall it is efficient and front-loaded.

  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 moderate complexity (3 parameters, output schema implied), the description covers purpose, usage, behavior, return value, failure mode, and an example. No gaps remain for an agent to infer.

  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 significant value: explains the ranking formula for 'limit', fuzzy matching and synonym expansion for 'query', and project narrowing for 'scope_id'. This goes well beyond the 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 clearly states the tool searches Cortex memories for relevant knowledge, with a specific verb 'Search' and a precise resource 'Cortex memories'. It differentiates from siblings by listing concrete use cases and explicitly naming alternative tools for different scenarios.

  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 includes explicit guidance on when to use (specific facts, prior context, debugging) and when not to use, with clear references to sibling tools 'transcript_search', 'context_assemble', and 'memory_list'. This helps the agent choose correctly.

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