Server Quality Checklist

Tool Scores

• list_memoriesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral transparency burden. The verb 'List' reasonably implies a read-only operation, and 'recent' hints at ordering, but the description does not disclose sorting semantics, pagination behavior beyond the skip parameter, or what exactly is returned. It is adequate for a simple list operation but not rich.

  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 very short, front-loaded with the tool's purpose, and every sentence adds value. The parameter documentation is compact and immediately useful. There is no redundant or filler content.

  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?

  For a simple two-optional-parameter listing tool, the description is mostly complete: purpose, parameters, and defaults are covered, and an output schema exists so return values need not be described. However, it lacks any guidance on choosing between list_memories and the sibling search tool, and it does not clarify what 'recent' means in terms of ordering.

  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 document the parameters. It does so concisely: 'limit' is described as the number of memories to return and 'skip' as offset for pagination, adding practical meaning beyond the schema's bare types and defaults. This largely compensates for the missing schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('List') and the resource ('recent memories and notes from your Memwyre vault'). It is specific enough to understand the tool's core function, but it does not explicitly differentiate itself from the sibling tool search_memwyre, leaving some ambiguity about when listing is preferred over searching.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use list_memories versus search_memwyre, save_memory, or get_document. The description implies a simple listing use case but offers no exclusions, prerequisites, or conditions that would help an agent choose between this and alternatives.

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

• get_documentA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It does disclose a read-like behavior through 'Retrieve' and sets return expectations with 'full content'. It does not mention error behavior, not-found cases, or permission requirements, but for a simple get-by-ID tool this is minimally adequate.

  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 compact and front-loaded with the core action, followed by a brief Args listing. The Args section is slightly redundant with the schema property name, but it earns its place by adding semantic context that the schema lacks. No wasted words.

  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?

  Given the tool's simplicity—one required parameter and an output schema that can communicate return structure—the description is nearly sufficient. Missing context includes explicit guidance on where the ID comes from (e.g., list_memories) and what happens for invalid IDs. These are minor but real gaps.

  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 define document_id. It does so clearly: 'The integer ID of the document to retrieve.' This adds meaning beyond the schema's bare type/title by explaining that the parameter is the identifier of the target resource.

  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 action and resource: 'Retrieve the full content of a specific document or memory by its ID.' It also uses a retrieval-by-ID mechanism that clearly distinguishes it from sibling tools like search_memwyre, list_memories, and save_memory.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The usage context is implied: the agent should call this when it has an ID and needs the full content, rather than searching, listing, or saving. However, the description does not explicitly name alternatives or state when not to use this tool, so the guidance remains implicit.

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

• search_memwyreA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It does convey that the tool performs hybrid semantic search and returns up to 'limit' relevant memories, but it does not explicitly state side-effect-free behavior, result ordering, or any access constraints. For a read-oriented search tool this is adequate but thin.

  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 compact and well-organized: a single purpose statement followed by a minimal Args block. Every sentence contributes meaning, and the core action is stated first. No filler or redundant text is present.

  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?

  The tool is simple with two parameters and an output schema, so extensive return-value documentation is not required. The description covers the core purpose and both parameters adequately. It lacks explicit routing to sibling tools or note about behavioral nuances, but for a lightweight search operation it is largely 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 0%, so the description is the only source of parameter meaning. It explains 'query' as a natural language search query or topic, and 'limit' as the maximum number of memories to return, including its default. This adds real value beyond the raw schema, though it could provide more detail on constraints or examples.

  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 a clear verb and resource: 'Search your Memwyre knowledge base and persistent memories using hybrid semantic search.' This explicitly distinguishes the tool from siblings like save_memory, list_memories, and get_document by indicating query-based retrieval rather than saving, listing, or fetching a specific document.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: when a natural-language query is needed to find relevant memories. However, it offers no explicit comparison to alternatives, such as using list_memories to browse all memories or get_document to retrieve a known document. Usage context is present but not elaborated, so it falls at 'implied usage' rather than clear exclusions.

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

• save_memoryA
  4.2/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. It clearly indicates a persistent write operation ('Save ... to your vault') and describes the types of content to store. It does not disclose potential side effects, idempotency, or permission requirements, but for a simple create operation the essential behavior is conveyed.

  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 concise and well-structured. The purpose is front-loaded in the first sentence, followed by a compact Args section that lists each parameter with a brief explanation. No redundant words or markdown overhead.

  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 simple write tool with one required parameter and an output schema, the description covers the purpose, target vault, and all parameters. The sibling tools are clearly distinct, and nothing else is needed for an agent to invoke this tool correctly.

  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 0%, so the description must compensate. It explains all three parameters meaningfully: content ('technical content, note, pattern, or decision'), tags ('Optional list of tags for organization' with an example), and title ('Optional title for the memory note'). This adds substantial value beyond the raw 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?

  The description states a specific verb ('Save') and a concrete resource ('memory snippet, note, bug fix, or architecture decision') with a clear destination ('Memwyre knowledge vault'). This clearly differentiates it from the sibling tools, which are all read/search operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage guidance is implied through the verb 'Save' and the obvious contrast with sibling names (search_memwyre, list_memories, get_document), but the description does not explicitly state when to use this tool over alternatives or include any exclusions. The intent is inferable but not spelled out.

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