Server Quality Checklist

Tool Scores

• memory_storeC
  2.4/5.0
  Behavior1/5

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

  No annotations are provided, and the description fails to disclose any behavioral traits. It does not mention idempotency, side effects, persistence guarantees, or error behavior (e.g., handling invalid 'kind'). This leaves the agent unaware of critical operational characteristics.

  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 very concise at two sentences, with no superfluous words. However, it leans toward under-specification rather than optimal conciseness, as key details are omitted. Despite this, it is well-structured and front-loaded with the core action.

  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 6 parameters (2 required), zero schema coverage, and no annotations, the description is severely incomplete. It does not cover the behavior of optional parameters, nor does it hint at the output schema (though one exists). The agent would lack sufficient context to use the tool correctly in diverse scenarios.

  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?

  With 0% schema description coverage, the description adds limited parameter meaning. It clarifies that 'kind' has a set of allowed values, which is helpful. However, it does not explain the purpose or expected format of 'content,' 'tags,' 'source,' 'project,' or 'priority,' leaving the agent to infer from parameter names alone.

  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 tool's purpose: 'Store a memory.' It specifies that 'kind' must be one of the listed values, which clarifies the resource type. However, it does not explicitly differentiate from sibling tools like 'memory_update,' which could cause confusion about additive vs. updative behavior.

  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?

  The description provides a list of valid 'kind' values but offers no guidance on when to use this tool versus alternatives (e.g., memory_update, memory_delete). It lacks context on prerequisites, common use cases, or scenarios where this tool is preferred.

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

• memory_deleteC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It does not mention if deletion is irreversible, requires confirmation, or has any side effects.

  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 extremely concise (5 words) and front-loaded. While it could benefit from more detail, it contains no unnecessary content.

  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?

  Despite having an output schema and only one parameter, the description lacks essential context for a destructive operation, such as consequences or prerequisites.

  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 coverage is 0%, but the description adds no meaning beyond the parameter name. It does not explain how to obtain the memory_id or any constraints.

  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 (delete) and resource (memory) with the method (by ID). It is distinct from siblings like memory_list or memory_store.

  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 on when to use this tool versus alternatives such as memory_update or memory_store. No when-not-to-use conditions.

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

• memory_listB
  3.2/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 full burden. It mentions ordering but does not disclose pagination behavior (limit/offset), filter matching semantics, or any rate limits. For a query tool, this is adequate but could be improved.

  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?

  Two sentences, efficient and front-loaded with purpose. However, it could integrate parameter descriptions without adding bulk.

  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 4 parameters and an output schema, the description fails to explain filter fields, pagination, or return structure. It lacks context needed for a complete understanding.

  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?

  With 0% schema description coverage, the description must explain parameters. It only mentions 'optional filters' without naming or describing kind, project, limit, offset, leaving the agent to infer from parameter names alone.

  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 verb 'list' and resource 'memories', with additional details about optional filters and ordering by creation date descending. This distinguishes it from sibling tools like memory_store, memory_delete, etc.

  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 use for listing with filters but does not explicitly state when to use this tool over siblings like memory_search. It provides no exclusion criteria or alternative recommendations.

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

• memory_updateB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It indicates a mutation but does not disclose behavior for missing memory_id, partial vs full update, or side effects. The optional fields in schema suggest partial update, but description omits this.

  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?

  Single sentence of 8 words, front-loaded with action and resource. No unnecessary words or repetition.

  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 but is not shown; still, description needn't explain return values. However, with 4 parameters, 0% schema coverage, and no annotations, the description is too brief. It fails to clarify partial update behavior, error handling, or required format of fields.

  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 description must compensate. It lists the field names (content, tags, priority) but adds no extra meaning about format, constraints, or relationships. The schema provides basic type info, but description adds no semantic value.

  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 (update), resource (existing memory), and fields (content, tags, priority). It distinguishes from siblings like memory_store (create) and memory_delete (delete).

  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 usage for modifying existing memories but does not explicitly state when to use this over alternatives. It lacks guidance on prerequisites (e.g., requires existing memory_id) or exclusions.

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

• memory_searchA
  3.6/5.0
  Behavior3/5

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

  Description mentions returning ranked results, indicating behavioral detail. However, with no annotations provided, it fails to disclose aspects like side effects (e.g., read-only), authentication needs, 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?

  Two sentences, no unnecessary words. Front-loaded with action and key details, allowing quick understanding.

  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?

  While output schema exists (so return values are optional), the description omits important context like search scope (e.g., filtering by kind/project) and default limit behavior. Adequate for basic understanding but not fully complete for a mutation tool with 4 params.

  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?

  With 0% schema description coverage, the description does not elaborate on parameters like 'kind', 'project', or 'limit'. The mention of 'semantic similarity and keywords' partially explains 'query', but overall insufficient to compensate for missing parameter documentation.

  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 clearly states it searches memories by semantic similarity and keywords, returning ranked results. This distinguishes it from sibling tools like memory_list (which likely lists all) and memory_store.

  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?

  Implicitly suggests use for search with semantic and keyword capabilities, but no explicit guidance on when to use vs alternatives or when not to use. Lacks context for exclusion.

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

• memory_statsA
  4.3/5.0
  Behavior4/5

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

  No annotations, but the description clearly indicates a read-only, non-destructive operation. Behavioral traits like authentication or response format are not detailed, but the presence of an output schema partially compensates.

  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?

  Single, concise sentence that front-loads the core purpose with no extraneous information.

  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?

  Complete for a parameterless stats tool with an output schema; clearly communicates what statistics are returned and the breakdown dimensions.

  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?

  No parameters exist (0 params), so schema coverage is effectively 100%. Baseline is 4 for zero parameters; description adds no further parameter info, which is acceptable.

  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 retrieves memory system statistics including total count and breakdown by kind and project, distinguishing it from sibling CRUD tools like memory_delete and memory_store.

  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?

  No explicit when-to-use or when-not-to-use, but the context of zero parameters and being a stats tool implies it's for global aggregation. Sibling names imply alternatives for specific operations, but no direct guidance.

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