Server Quality Checklist

Tool Scores

• vrm_listC
  2.1/5.0
  Behavior1/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It provides none: no mention of side effects, read-only nature, required permissions, pagination behavior, or the effect of the 'verify' parameter. The description adds no behavioral context beyond the action itself.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

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

  The description is a single short sentence, which is front-loaded and free of fluff. However, it is under-specified, omitting essential information about parameters and behavior. It reads as a vague label rather than a concise, complete description.

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

  Completeness1/5

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

  Given the tool has 3 parameters (limit, status, verify), no annotations, and no output schema, the description is severely inadequate. It does not explain the meaning of statuses, the behavior of 'verify', or default limits. An AI agent would lack enough context to invoke the tool accurately.

  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%, so the description must compensate for the lack of parameter explanations. It only mentions 'status' without explaining its enum values (all, valid, stale, missing) or the purpose of 'limit' and 'verify'. The description adds minimal meaning beyond the schema field names.

  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 'List memories by status' clearly identifies the action (list) and resource (memories), with status as a filter. It is not a tautology and distinguishes from siblings like vrm_retrieve (which likely fetches a single memory) and vrm_search (which likely searches by content), though it does not explicitly name alternatives.

  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?

  There is no guidance on when to use this tool versus alternatives. The description does not mention contexts in which listing by status is appropriate, nor does it contrast with vrm_search or vrm_retrieve. No exclusions or prerequisites are provided.

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

• vrm_retrieveC
  2.2/5.0
  Behavior2/5

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

  With no annotations, the description must fully disclose behavioral traits. It mentions 'JIT-verify' and 'valid memories' but does not state whether the operation is read-only, whether it has side effects (e.g., the 'touch' parameter suggests updating last access time), or what happens to invalid candidates. This is a significant transparency gap for a tool that may mutate state.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

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

  The description is a single concise sentence with no wasted words. However, it is under-specified, sacrificing necessary context for brevity. It could be expanded with relevant behavioral details while still remaining concise.

  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?

  Given the tool has four parameters, no annotations, and no output schema, the description is insufficiently complete. It does not cover return value format, error behavior, side effects, or the meaning of key terms like 'candidates' and 'valid'. It leaves the agent with significant uncertainty.

  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%, and the description adds no information about any of the four parameters (query, limit, touch, includeStale). It does not explain what 'candidates' refers to or how parameters influence the JIT verification. The description is entirely unhelpful for parameter understanding.

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

  Purpose3/5

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

  The description uses a specific verb 'verify' and resource 'memories', suggesting a retrieval/validation operation. However, 'candidates' is undefined and the purpose is vague, lacking clarity on what inputs are expected or how verification works. It does not clearly distinguish from siblings like vrm_search or vrm_list, as 'retrieve' with 'verify' is ambiguous.

  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 on when to use this tool versus alternatives. There are no exclusions, prerequisites, or mentions of sibling tools. The context is entirely implied by the tool name, which is insufficient for correct selection.

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

• vrm_searchC
  2.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the disclosure burden. It does reveal a meaningful behavioral trait: no JIT verification, implying results may be cached/stale but fast. However, it doesn't explain what JIT verification means for result freshness or mention any other side effects or requirements.

  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?

  A single concise sentence with the core action front-loaded. The phrase 'no JIT verification, fast' is efficient but somewhat cryptic; no filler, though the jargon could be clearer.

  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?

  For a 3-parameter search tool with no annotations and no output schema, the description is too sparse. It leaves out expected result format, default behaviors (limit=20, includeExpired=false), and what distinguishes a verified vs unverified search. The qualifier adds some color but not enough context for confident invocation.

  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%, and the description adds no parameter-specific explanation. It doesn't mention that limit controls result count, includeExpired includes expired candidates, or how query is matched, so it fails to compensate for the undocumented schema.

  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 uses the specific verb+resource 'search for candidates,' which clearly tells the agent what the tool does. It doesn't explicitly contrast with sibling tools like vrm_list, but the operation is unambiguous.

  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 explicit when-to-use guidance or alternatives are mentioned. The parenthetical '(no JIT verification, fast)' hints at a performance trade-off but does not tell the agent when to prefer this over vrm_list or other siblings.

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

• vrm_storeB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description must disclose all behavioral traits. It adds one useful detail (snippets are auto-extracted) but does not mention permissions, irreversibility, TTL behavior, conflict handling, or what the function returns. For a mutation tool with 6 parameters, this is insufficient.

  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?

  Two short sentences, front-loaded with the action and key feature. No wasted words; every word earns its place.

  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?

  The tool has 6 parameters, no annotations, and no output schema, yet the description provides almost no context about what a memory is, how citations work, what snippet extraction means, or what the caller should expect. This level of sparsity is inadequate for an agent to invoke the tool intelligently.

  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 parameter meanings. It only vaguely references 'file citations' but does not explain subject, fact, tags, reason, or ttlDays. The raw schema provides types and constraints but no semantic guidance, leaving a significant gap.

  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 action (store), the resource (a memory), and the key differentiator (file citations with auto-extracted snippets). It stands apart from sibling tools like vrm_search and vrm_list which are read operations, and vrm_forget which is a delete operation.

  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 verb 'store' and the context of sibling tools imply that this is the write operation vs. read/search operations, but the description does not explicitly state when to use this tool or when to prefer alternatives. There are no exclusions or prerequisites mentioned.

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

• vrm_forgetA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full behavioral burden. It only states 'delete' without disclosing implications such as whether deletion is permanent, what 'hardDelete' means, whether deletion is reversible, or what happens to associated memory. This is a significant transparency gap for a mutation 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?

  The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action and target resource.

  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?

  Given no annotations, no output schema, and an unexplained 'hardDelete' parameter, the description is too brief to fully prepare an agent. It does not mention return values, deletion permanence, or any side effects, leaving important gaps for a deletion tool.

  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. It explains 'memoryId' via 'by ID' but completely ignores the 'hardDelete' parameter, which is crucial for understanding whether deletion is soft or permanent. Half the parameters are semantically unexplained.

  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 uses the specific verb 'delete' with the resource 'memory' and identifies the key mechanism ('by ID'). It effectively distinguishes this tool from its siblings (store, search, retrieve, list) by centering on deletion.

  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 word 'Manually' provides context that this tool is for user-initiated deletion, likely contrasting with automatic memory management. However, it does not explicitly mention when not to use this tool or alternatives, so it lacks full exclusionary guidance.

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