Server Quality Checklist

Tool Scores

• mnemostack_feedbackA
  4/5.0
  Behavior3/5

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

  No annotations; description mentions recording and Q-learning update but omits side effects, permissions, or idempotency. Adequate but not thorough.

  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?

  Three concise sentences, front-loaded with purpose, no fluff. Each sentence adds 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?

  Has output schema, so return values covered. Covers core usage with sibling integration, but could elaborate on parameter behavior.

  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?

  14% schema coverage; description adds meaning for signal and sources but leaves hit_id, query_type, reward, source unexplained. Partially compensates.

  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-resource pair 'Record explicit feedback' with specific use case for signal='clicked'. Distinct from siblings like search and answer.

  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 guidance on when to use (feedback recording) and how to connect with mnemostack_search. Lacks explicit exclusions but context is sufficient.

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

• mnemostack_healthA
  4.5/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. It discloses the tool is read-only, has no side effects, and requires no authentication. It also describes the return format. This goes beyond minimal requirements, though it omits potential error conditions or rate limits.

  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 purpose, and includes all essential details without any filler. Every sentence adds value.

  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 simplicity (no parameters, presence of an output schema), the description fully covers the agent's needs: purpose, behavior, return fields, and usage guidance. 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?

  The tool has zero parameters and the input schema is fully described (100% coverage). The description correctly indicates no inputs are needed. Baseline for zero parameters is 4, and the description adds no extra parameter semantics, which 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 uses a specific verb 'check' and clearly identifies the resource 'health of all mnemostack components'. It distinguishes itself from siblings by directing users to use this tool before recall queries, implying other tools (answer, feedback, search) are for different tasks.

  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 states when to use it ('before issuing recall queries') and clarifies characteristics ('Read-only, no side effects, no authentication required'). It does not explicitly state when not to use it or name alternatives, but the context makes those clear.

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

• mnemostack_resolveA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavioral traits: 'Read-only; never mutates stored memory' explicitly states safety, and 'runs outside the recall path' plus 'Resolution is confined to the corpus root recorded at ingest — there is deliberately no way for a caller to point it at another directory' provides important scope limitations. It also lists the verdict categories and mentions 'snapshot-hash comparison,' giving rich behavioral detail beyond what structured data could convey.

  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 front-loaded with the purpose in the first sentence and each subsequent sentence adds distinct value: verdict categories, read-only safety, and root-confined scope. It is concise enough at roughly 90 words and avoids 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, the description covers the core purpose, explicit safety guarantees, scope restrictions, and the nature of the return value (verdicts and optional fragment). The presence of an output schema means return details are not required in the description, and the tool's simplicity makes this fully 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 input schema already documents the sole parameter `chunk_id` with the description 'The [id:...] value from a recall result or answer citation,' achieving 100% schema coverage. The tool description adds only that it resolves the id back to a source document, which is purpose-oriented rather than parameter-specific. This meets the baseline but does not elevate it.

  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 'Verify a citation: resolve a chunk id back to its source document,' giving a specific verb ('verify'/'resolve') and resource ('chunk id back to source document'). This clearly distinguishes it from siblings like search, answer, invalidate, and health by focusing on citation resolution and verification.

  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 clearly establishes context: 'Verify a citation' and 'Re-reads the CURRENT source' imply it is for verifying existing citations against the current source. It also notes it 'runs outside the recall path,' distinguishing it from retrieval tools. However, it does not explicitly name sibling alternatives or state when not to use it, so it stops short of full usage guidance.

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

• mnemostack_invalidateA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: non-destructive, sets timestamps without deletion/re-embedding, skips non-existent points, guard logic for index_root, and return fields. 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.

  Conciseness5/5

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

  Five sentences, no filler. The first sentence states the core purpose. Every subsequent sentence adds necessary detail about behavior, edge cases, and return values. Structure is compact and well-organized.

  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 has 4 parameters (1 required) and no output schema shown, the description fully covers return values, side effects, and parameter behavior (e.g., skip logic, index_root guard). No gaps remain for an agent to misunderstand.

  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%, providing baseline 3. The description adds semantic value beyond schema by explaining the owner guard ('so one root cannot invalidate another's chunks'), the distinction between system-time and world-time stamps ('optional, separate from the system-time invalidation stamp'), and the effect on recall.

  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 'Mark memories stale by id, non-destructively,' giving a specific verb and resource. It also positions itself as a write tool parallel to a sibling, distinguishing its purpose from the other siblings (e.g., search, answer).

  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 explains when to use this tool versus alternatives: 'invalidated facts drop out of default recall but stay reachable via include_invalidated / as_of.' It also gives instructions for multi-root collections ('Pass index_root...'). However, it does not explicitly state when NOT to use this tool.

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

• mnemostack_answerA
  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 carries the burden. It states 'Read-only, no side effects, no authentication required,' and thoroughly describes return fields including the 'notes' routine signals, 'degraded' field behavior, and null token_used cases. It also discloses the default hiding of stale facts, which is a behavioral trait beyond what the schema conveys.

  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 front-loaded with the purpose and usage, followed by a detailed return-value specification. It is long but every sentence carries substantive information; the use of parentheses and semicolons keeps it structured. Not as concise as the ideal two-sentence example, but appropriately sized for the tool's 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?

  The description is comprehensive: it explains the tool's purpose, usage context, return schema, safety profile, and edge cases (e.g., stale facts, degraded flags, token reporting). Given the tool's complexity and the absence of annotations, this description covers all necessary context for an agent to invoke it 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. The description adds value by referencing 'same contract as mnemostack_search' for as_of and token_budget, clarifying filter behavior, and noting the default for include_invalidated. These cross-tool and behavioral details go beyond the schema's property 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 answers a question using retrieved memories and distinguishes it from mnemostack_search by producing a synthesized answer rather than raw matches. The verb 'answer' plus the resource ('retrieved memories') is specific, and the explicit mention of the sibling tool clarifies the 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 gives explicit usage guidance: 'Use this when you want a concise factual answer synthesized from memory search results instead of the raw matches returned by mnemostack_search.' It also notes when to use include_invalidated or as_of to see stale facts, providing clear context for this tool over alternatives.

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

• mnemostack_searchA
  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 carries the full transparency burden and meets it comprehensively. It discloses read-only/no side effects/no auth, ranking algorithm (RRF of BM25, semantic, graph, temporal), stale-fact defaults, and explains the semantics of notes and degraded fields, including deprecated back-compat 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 dense but well-organized, with every sentence adding meaningful detail. It flows from purpose to usage to return semantics to behavior, with no filler or 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?

  This is a complex tool with 7 parameters and nuanced return fields, yet the description covers when to use it, safety profile, ranking methodology, stale handling, and how to interpret notes/degraded signals. Even though an output schema exists, the description adds necessary context about deprecation and non-fault indicators, making it fully 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 description coverage is 100%, setting a baseline of 3. The description adds value beyond the schema by relating include_invalidated and as_of to stale-fact visibility and explaining how filters interact with retrievers. While not exhaustive per-parameter, it enhances understanding of 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?

  Description opens with a specific verb+resource ('Search indexed memories with hybrid recall') and explicitly differentiates from the sibling answer tool: 'raw memory matches rather than a synthesized answer.' This clearly states what it does and distinguishes it from alternatives.

  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 context ('Use this when you need raw memory matches rather than a synthesized answer') and indicates a read-only, no-authentication need. The synthesized-answer contrast implicitly names the mnemostack_answer sibling as the alternative.

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