Server Quality Checklist

Tool Scores

• memory_readB
  3.2/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 the full burden of behavioral disclosure. While 'read' implies no mutation, the description does not explicitly confirm read-only behavior, nor does it mention authentication requirements, error handling, or whether calling with a non-existent memory_id has consequences. This is a significant gap.

  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 redundant words. It efficiently communicates the core function and the optional parameter.

  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 tool with two parameters and an existing output schema, the description covers the essential purpose and the optional flag. It is complete enough for most use cases, though it could mention that memory_id is required and what happens if it is invalid.

  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 has 0% description coverage, so the description must compensate. It adds meaning by explaining that memory_id identifies a single memory and include_history retrieves 'every immutable version.' This is helpful but limited; more details on the format of history or default behavior would improve clarity.

  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 reads one memory's current state with an optional history flag. The verb 'Read' and resource 'memory's exact current state' are specific. However, it does not distinguish itself from sibling tools like memory_history or memory_search, which could have overlapping purposes.

  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 like memory_search for finding memories or memory_history for viewing versions. The description lacks context on prerequisites 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_searchB
  3.2/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 discloses basic behavior (FTS5 search, active/removed) but lacks details on permissions, side effects, or idempotency. This is minimal for a search 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 sentence with no wasted words, front-loading the core functionality. It is appropriately sized for the tool's simplicity.

  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 that an output schema exists, the description does not need to explain return values. It provides sufficient context for a search tool, though the exact meaning of 'current-memory index' is unclear.

  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 schema already includes descriptions for all parameters, so the description adds marginal value. It reiterates the include_removed default but does not enhance understanding beyond the 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 clearly states the tool searches an FTS5 index and defaults to active memories. However, it does not explicitly differentiate from siblings like memory_read or memory_history.

  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 vs alternatives. The description only explains default behavior but not scenarios or prerequisites.

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

• memory_historyB
  3.4/5.0
  Behavior3/5

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

  Discloses read-only nature and ordering, but doesn't cover edge cases (e.g., missing memory) or limitations; no annotations to shift burden.

  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, no fluff, efficiently conveys core functionality.

  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?

  Adequate for a simple history retrieval, but lacks detail on return structure (though output schema exists) and potential errors.

  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%, and description does not explain the memory_id parameter beyond implying it identifies a memory.

  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 returns every immutable version of a memory in ascending order, distinguishing it from siblings like memory_read or memory_search.

  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 vs. siblings, no prerequisites or alternative scenarios mentioned.

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

• memory_patch_readA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description must cover behavioral traits. It discloses that the operation is a read and lists what is included, but does not specify side effects, permissions, or error behavior. Since it's a read, minimal transparency is acceptable, but more detail could be added.

  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 sentence of 16 words, efficiently conveying the tool's purpose and contents with no redundancy.

  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 read tool with one parameter and an output schema, the description is mostly complete. It explains what the tool returns (patch details) without needing to detail return values. However, it could mention behavior for invalid patch IDs or uncommitted patches.

  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%. The description does not explain the single parameter 'patch_id' beyond its presence in the schema. The parameter is simple and self-explanatory, but the description adds no extra meaning.

  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 'Read a committed patch' with specific verb and resource, and lists included components (semantic operations, evidence links, etc.). This distinguishes it from sibling tools like memory_read (generic) and memory_apply.

  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 guidance on when to use this tool versus alternatives. The description implies usage for reading patch details, but does not mention when not to use it or suggest alternative tools for other scenarios.

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

• memory_record_eventA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It notes immutability and idempotency for identical external_id and data, but does not explicitly state that the tool creates a new record (a write operation) or describe failure modes, authorization needs, or 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.

  Conciseness5/5

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

  Two sentences with no redundant information. The first sentence states the core purpose, and the second adds a crucial behavioral detail about idempotency. Every word earns its place.

  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 one parameter with a rich schema and an output schema, the description is mostly complete. It covers purpose and key behavioral nuance (idempotency), but could be more explicit about the creation effect and output nature. Still, the output schema presumably handles return value documentation.

  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 tool description adds no parameter semantics beyond what the input schema provides. Since the schema already includes descriptions for each property of EventInput, baseline is 3. No additional value from the description is observed.

  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 'Record immutable evidence' uses a specific verb ('record') and resource ('immutable evidence'), clearly distinguishing this tool from its siblings (memory_read, memory_search, memory_apply, memory_history, memory_patch_read) which focus on reading, searching, or modifying existing data.

  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 implicitly indicates when to use this tool (recording new immutable events) but does not explicitly exclude alternatives such as memory_read for reading. The sibling tool names provide context, but explicit usage guidance would improve clarity.

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

• memory_applyA
  4.3/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 atomicity, return of diffs and evidence links, soft deletion for REMOVE, version checking for UPDATE/SUPERSEDE/REMOVE, and idempotency support. It does not contradict any hypothetical annotations, and the behavioral traits are clearly outlined.

  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 fairly concise and front-loaded with the primary purpose. It uses a structured paragraph split by operation types, making it scannable. A minor improvement would be to list operations in bullet points, but current structure is effective without wasted words.

  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 complexity (multiple operation types, versioning, idempotency) and the presence of an output schema (so return values need not be explained), the description covers essential use cases and constraints. It could mention operation limits or error handling for version mismatches, but overall it is sufficient for correct invocation.

  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?

  Although schema description coverage is reported as 0%, the description adds significant meaning beyond the raw schema by explaining the semantics of each operation and their required parameters (e.g., 'ADD uses subject/content,' 'UPDATE uses memory_id/expected_version/new_content'). This helps an agent properly select and populate 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 states 'Apply semantic operations atomically and return server-generated diffs and evidence links,' clearly identifying the tool as a write-oriented operation for memory modifications. It distinguishes from sibling tools like memory_read (read-only) and memory_search (query) by specifying atomic application of semantic operations with diffs and evidence links.

  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 each operation type (ADD, UPDATE, SUPERSEDE, REMOVE) and notes that default policy requires evidence IDs. It explicitly forbids raw SQL and administrative rollback, guiding the agent away from misuse. However, it could more directly state that this tool is for writing modifications, not reading.

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