Server Quality Checklist

Tool Scores

• mnemos_list_memoriesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure by itself. It does reveal that results are restricted to 'currently active' memories and that IDs are returned, but it fails to disclose the effect of the limit parameter on the 'all' claim, nor does it state ordering or pagination. 'List' implicitly signals a read-only operation.

  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?

  One sentence with no filler; the active verb and object are front-loaded, and the downstream use for mnemos_forget is appended without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Output schema exists so return values need not be spelled out, but the single input parameter is semantically undocumented and the word 'all' conflicts with an optional limit default of 50. An agent cannot tell whether it receives every active memory or only up to the limit, making the tool incompletely specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%; the sole parameter, limit, is never mentioned in the description. The agent must rely entirely on the parameter name and default value, so the description adds no meaning beyond the 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?

  Description opens with a specific verb and resource: 'List all currently active memories'. It further clarifies output (IDs) and intended downstream use (input to mnemos_forget), separating it from the sibling tools by its enumerating role.

  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?

  'For browsing or as input to mnemos_forget' gives explicit contexts in which this listing tool is appropriate. It does not explicitly say when to prefer mnemos_recall or mnemos_remember, so no exclusion is stated, but the use cases are clear enough.

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

• mnemos_recallA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It communicates the core read-only behavior through the verb Retrieve and the notion of relevance-based selection, but it does not mention whether memories are modified, how results are ranked, or what happens when no relevant memories exist. This is minimal but not misleading.

  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 a single, front-loaded sentence: the function is stated first, followed by usage context. Both parts carry meaningful information with no redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple — two parameters, one required, a default value, and an output schema — and the description covers the main purpose and timing. However, it lacks parameter-level detail (notably top_k) and does not explicitly assert non-mutating behavior, leaving minor but real gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only hints at the query parameter by saying 'relevant to a query', and it gives no guidance on composing the query or on the meaning of top_k, such as it being a limit on the number of returned memories. This is insufficient for an agent to confidently set 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 uses a specific verb (Retrieve) and a resource (memories relevant to a query), which unambiguously defines the tool's function. It also distinguishes this recall operation from the sibling tools (remember, list, forget, reflect) without requiring their schemas.

  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 gives a clear when-to-use hint: 'call this near the start of a task that might benefit from prior context about the user or their preferences/projects.' However, it does not explicitly state when not to use it or directly name alternative tools for other memory operations, relying instead on sibling names to imply the distinction.

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

• mnemos_rememberA
  4.2/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full burden. It does add useful behavioral context by stressing durability ('recalling in a future session') and by excluding content already in the codebase/CLAUDE.md. However, it does not disclose potential behaviors like dedupication, overwriting, or failure modes. For a simple store operation this is 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?

  The description is tight and front-loaded: it opens with the essential action and object, then gives examples and exclusions. There is no fluff or redundant content; every phrase earns its place. The structure makes it easy to scan.

  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 one-parameter tool with an output schema, the description covers the critical aspects: what to store, why to store it, and what not to store. It could mention whether repeated stores are idempotent or whether there are size limits, but these are not essential for basic correct invocation. Overall it is complete enough for the agent to use the 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?

  The schema provides no description for 'fact' and coverage is 0%, so the description must compensate. It does so well by defining what 'fact' should contain (stated preferences, decisions with reasoning, recurring conventions) and what to exclude. This gives the agent meaningful guidance beyond the parameter name, though no concrete example or length/format is given.

  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 ('Store') with a clear resource ('a durable fact worth recalling') and gives concrete examples ('stated preference, a decision and its reasoning, a recurring convention'). It also states what it is not for ('routine task details', 'anything already in the codebase/CLAUDE.md'), making it easily distinguishable from the sibling retrieval tools like mnemos_recall and mnemos_list_memories.

  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 provides clear inclusion criteria (durable, future-worthy, preferences/decisions/conventions) and explicit exclusion criteria ('Not routine task details, not anything already in the codebase/CLAUDE.md'). It does not name alternative tools explicitly, but the when-to-use guidance is strong enough to route an agent correctly.

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

• mnemos_reflectA
  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, and it does well by disclosing side effects (merging, decaying, archiving), the API key requirement, and the intended cadence. It could be more explicit about whether archived memories are still retrievable or if the pass is irreversible, but this is above baseline for an unannotated 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?

  Three sentences, each earning its place: the action, the prerequisite, and the usage frequency. No redundancy or filler, and key information is front-loaded.

  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 zero-parameter maintenance tool with an output schema available, the description covers behavior, prerequisites, and invocation frequency. It lacks a brief note on reversibility or what happens to archived memories, but that is not blocking given the simplicity of the tool.

  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 schema coverage is 100%, so the baseline is 4. The description adds relevant context about external dependencies (ANTHROPIC_API_KEY or GROQ_API_KEY) even though no parameters need documenting.

  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 states a specific operation: 'Run a consolidation pass' with concrete sub-actions (merge near-duplicates, decay stale ones, archive past threshold). This clearly distinguishes it from the sibling tools, which handle individual memory operations like remember, recall, list, and forget.

  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 gives explicit usage guidance: call it 'occasionally to keep memory tidy' and 'not on every turn.' It also flags a key prerequisite (LLM provider API key). It does not explicitly name alternatives or contrast them, but the guidance is clear enough for an agent to decide when to invoke it.

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

• mnemos_forgetA
  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. It clearly discloses that this is a soft-delete (archived, not erased), that the fact remains visible in the audit log, and that the operation is not reversible/dismissive. This is strong behavioral context for a mutation-like tool, though it does not specify what happens to related data or the exact response format.

  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 sentences with no wasted words. The most important usage constraint ('never call speculatively') is placed at the end but the whole description is compact. It front-loads the core action and the source of the ID.

  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 has 2 parameters, no annotations, and no output schema details beyond its existence, the description covers the key decision points: what the tool does, where the ID comes from, the soft-delete behavior, and when to call it. It could add a note about the audit-log implication more explicitly, but it essentially does. This is nearly complete for the tool's complexity.

  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 0%, so the description must compensate. The description explains that fact_id is the memory ID as shown by mnemos_list_memories, giving practical meaning. The reason parameter is not individually explained, but the default value 'user_requested' and the overall guidance about explicit user requests imply its purpose; a small gap remains.

  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 ('Forget (archive)') and resource ('a specific memory by its ID'), and even names the sibling tool mnemos_list_memories as the source of IDs, distinguishing it from other mnemos tools. It is immediately clear what this tool does.

  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 when-to-use guidance: only when the user explicitly asks to forget something, and explicitly warns against speculative calls. It also explains the soft-delete behavior and audit-log visibility, which helps an agent decide when this is appropriate.

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