Server Quality Checklist

Tool Scores

• memory_consolidateC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description alone must disclose behavior. It says the result is a durable higher-level memory, but it does not say whether source memories are kept, deleted, modified, or linked, nor whether the operation has destructive 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 one efficient sentence with the main action and result front-loaded. It is not bloated, though it sacrifices needed detail for brevity.

  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?

  With five parameters, no output schema, zero parameter coverage, and no annotations, a one-sentence description is severely incomplete. It omits parameter role, behavior on source memories, output/return behavior, and usage boundary with sibling tools.

  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. The phrase 'source memories' loosely maps to source_ids and 'one durable higher-level memory' maps to content, but context, confidence, and memory_class are completely unaddressed.

  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 states a clear action and resource: consolidate source memories into one durable higher-level memory. It implies a merge/abstraction operation that is conceptually distinct from store, recall, link, or supersede siblings, 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 about when to use this tool versus siblings like memory_store_batch, memory_link, or memory_supersede. The context is only implicit in the word 'consolidate'; the description does not state prerequisites, exclusions, or suitable scenarios.

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

• memory_suppressC
  2.9/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. It usefully states the operation is non-destructive ('without deleting it'), but it does not explain whether the inhibition is reversible, what 'inhibit' actually changes about the memory, or how the 'amount' affects the behavior.

  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 filler. It states the action, target, and a key constraint efficiently.

  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 tool with no annotations, no output schema, and a schema with undocumented parameters, this description is too sparse. An agent would know what kind of memory to target but would not understand how the amount parameter behaves, whether suppression is reversible, or what the tool returns after execution.

  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%, but the description adds no meaning for either parameter. memory_id is obvious but still undocumented, and amount is not explained at all, leaving its scale, units, and effect entirely unclear.

  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 gives a specific verb ('inhibit') and a resource ('a stale or unhelpful memory'), and clarifies that suppression does not delete the memory. It does not, however, distinguish itself from the similarly-named sibling memory_supersede, so it stops short of a 5.

  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 phrase 'stale or unhelpful memory' implies when the tool should be used, but the description gives no explicit comparison to siblings like memory_supersede or memory_feedback, and does not state when it should not be used.

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

• memory_contextB
  3/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavioral traits. It does disclose a key constraint: 'Each returned memory fits wholly within the remaining budget; budgets must be greater than zero.' However, it does not state whether the operation is read-only, what happens on insufficient budget, how activation affects results, or any ordering/pagination behavior. The single disclosed constraint is useful but incomplete.

  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 extremely concise—two sentences—with the primary purpose front-loaded. Every word adds value, and the token_budget constraint is clearly separated. No filler or 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?

  Given 4 parameters, no output schema, and no annotations, the description is incomplete. It omits meanings of limit, context, and strict_context, does not describe the output format or ordering, and gives no indication of safety or side effects. It also does not help the agent distinguish this tool from memory_recall. Significant gaps remain for correct invocation and interpretation.

  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 should compensate. It explains token_budget semantics explicitly, but leaves limit, context, and strict_context unexplained. The mention of 'activation' in the first sentence does not map directly to any parameter, leaving most inputs ambiguous. The partial coverage of one parameter is insufficient for a 4-parameter tool with zero schema based documentation.

  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 verbs and resource: 'Return a working-memory set' selected by activation and token budget. It distinguishes itself from siblings (memory_recall, memory_store) by focusing on a set selected by activation/budget, but does not explicitly contrast with them. The purpose is specific and actionable.

  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 like memory_recall or memory_store. The description explains what it does but not under what conditions an agent should choose it. There is no mention of exclusions, prerequisites, or typical use cases.

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

• memory_storeB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description itself carries the burden of disclosing runtime behavior. It adds the useful detail that memory is 'durable,' but it does not say whether the call creates or updates an existing memory, whether it may overwrite previous data, what will be returned or persisted, or any notable side effects. That is a significant transparency 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 brief, front-loaded with the primary purpose, and contains no filler or repetition. Every line contributes either to the core verb/resource definition or to the distinction among memory classes needed for correct invocation.

  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?

  With six parameters, no output schema, no annotations, and a large sibling toolset, the description leaves important context unstated. An agent cannot determine what the tool returns, how this differs from batch storage or recall, whether context is mandatory, or how memory behaves when stored again.

  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?

  This description is the only documentation for parameters since schema description coverage is 0%. It valuably explains the memory_class enum values and advises about the context parameter. Still, metadata, confidence, and provenance receive no meaningful explanation, so it only partially 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 opens with a specific verb and resource: 'Store durable project memory.' This clearly communicates the tool's core function. However, it does not differentiate itself from sibling tools like memory_store_batch or memory_recall, so it falls short of a 5.

  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 provides solid guidance for the memory_class parameter, mapping procedural, semantic, episodic, and entity memory types to concrete usage patterns. However, it does not say when to choose this tool over related siblings such as memory_store_batch, memory_recall, or memory_suppress, and it offers no explicit exclusions.

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

• memory_threadB
  3.2/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 burden of behavioral disclosure. It does reveal useful behavioral traits: traversal happens in both directions along RESPONDS_TO edges and results are sorted chronologically. It does not mention output shape, errors, or edge-case behavior, but the core runtime behavior is transparent.

  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, giving the essential operation in the first sentence and then enriching it with directional and ordering details in the second. There is minor redundancy between 'return the thread' and 'returning them sorted chronologically', but the overall structure is efficient and readable.

  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 has no output schema and no annotations, so the description carries significant responsibility. It conveys the main purpose, starting point, traversal direction, and sort order, but it leaves max_depth semantics and the exact shape of the returned thread unstated, which leaves room for an agent to misread the tool's limits.

  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 both parameters. It clarifies 'start_id' as the starting memory ID, but it never explains 'max_depth', such as whether it limits the number of hops or nodes. Given that one of the two parameters is effectively undocumented, the parameter semantics are incomplete.

  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 that the tool walks the RESPONDS_TO chain starting from a memory ID and returns the thread, which is a specific verb and resource. It also adds detail about bidirectional traversal and chronological ordering, but it does not explicitly distinguish itself from siblings like memory_context or graph_query.

  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 implies usage when a thread of connected memories is needed, but it provides no explicit when-to-use guidance, exclusions, or references to alternative tools. An agent must infer the appropriate use case solely from the tool name and the word 'thread'.

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

• graph_queryB
  3.4/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure. It does add useful semantic facts such as 'RESPONDS_TO graph edges are authoritative' and that diagnostics identifies legacy provenance-only relationships, but it never clarifies that add_edge mutates the graph, whether it requires special permissions, or what happens on unsupported/malformed operations.

  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 purpose. Every sentence earns its place: the scope, the sibling alternative, and the important authoritative-vs-legacy distinction. It could be slightly more structured, but it has no filler.

  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?

  This is a multi-purpose tool with five parameters, no output schema, no parameter documentation in the schema, and no annotations. The description tells which operations exist but not which fields are required or used for each operation, nor what the return shape or behavior is per operation. An agent would still need to guess several important details.

  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 helps only for 'operation' by naming valid values at a high level, but the meaning and relationship of id, type, source, and target remain entirely unexplained. This is a substantial 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 says specific verbs and resources ('Inspect graph neighbors/schema' or 'perform an advanced edge operation') and distinguishes itself from memory_link for normal relationships. It lists concrete operations, so an agent knows what this tool covers without opening a sibling.

  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 guidance on when not to use it: prefer memory_link for normal memory relationships. It also enumerates supported operations, making alternative choices clear. It does not give full conditional guidance for each operation, but the main alternative is clearly identified.

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

• memory_feedbackB
  3.4/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states that feedback is recorded and when, but it does not explain whether the feedback modifies future retrievals, whether repeated feedback for the same memory_id overwrites prior feedback, or whether this action is reversible. These are meaningful gaps for a memory-system 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 exceptionally concise: two short sentences with no filler. It front-loads the core action and then adds the practical timing/condition in the second sentence. Every sentence 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?

  While the tool is simple, there is no output schema and no annotations, so the description must fully support invocation and behavior expectations. It omits the meaning of agent_id, whether feedback is appended or overwrites, and what the tool does after being called. Given these gaps, the definition is not complete enough on its own.

  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 needs to compensate for the parameter definitions, but it only mentions a 'retrieved memory' and 'useful or misleading'. It does not explain what memory_id refers to, how the 'useful' boolean maps to those outcomes, or what agent_id and its default mean. The agent must largely guess the parameter semantics.

  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 verb 'Record' and the resource: whether a retrieved memory helped the task. It further clarifies its purpose by specifying the timing 'after using a recalled memory when it was useful or misleading', which distinguishes it from siblings like memory_store and memory_recall without explicitly naming them. The small deduction is for lacking an explicit sibling contrast, but the overall purpose 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 Guidelines4/5

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

  The description gives an explicit condition: 'Call this after using a recalled memory when it was useful or misleading.' This tells the agent when to use the tool but not when not to use it or when to choose an alternative, leaving a minor gap for an otherwise simple operation.

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

• memory_link_batchB
  3.4/5.0
  Behavior2/5

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

  Since annotations are absent, the description must disclose operational details, but it only says relationships are created. It does not state whether existing links are replaced, failed pairs rollback the whole batch, or what happens if memories are missing. The default 'RESPONDS_TO' is useful but not enough.

  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 extremely focused: first sentence states purpose and scope, second sentence explains the required shape of each list item. Every sentence earns its place, and the most important usage details are front-loaded.

  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 one-parameter batch tool, the description explains how to structure a valid call, but does not cover failure modes, idempotency, or allowed relationship values. Since there is no output schema and no annotations, the definition leaves room for guesswork about return values and partial failures.

  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 only declares an opaque list with `additionalProperties: true`, so the description is the only source of parameter meaning. It clearly documents `source_memory_id`, `target_memory_id`, the optional `relationship`, and its default value. It lacks valid relationship values and exact ID types, but this is a solid compensatory description.

  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 a specific verb ('Connect'), a resource ('multiple pairs of memories'), and a clear scope ('in a single batch'). It distinguishes from the singular memory_link tool by emphasizing batch processing, though it does not explicitly name the alternative.

  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 phrase 'in a single batch' implies that this tool is for linking many memory pairs at once, but it does not explicitly state when to prefer it over memory_link or when not to use it. The usage context is reasonable but left largely to inference.

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

• memory_supersedeA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining behavior. It does reveal an important trait: the old fact is not wiped but retained in history. It does not clarify the resulting status of the old memory, whether the new memory must already exist, or whether the operation is reversible.

  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 short sentence states both the primary operation and the most valuable behavioral consequence with no filler. Every word is functional.

  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 two-parameter memory operation, the description is minimally viable: it communicates the main action and the history-preserving behavior. It stops short of guiding the agent on prerequisites, expected outcomes, or return values, which matters because no output schema or annotations are available.

  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%, and the description does not explicitly map the two required IDs to 'new memory' and 'old memory'. The parameter names carry most of the meaning, and the description adds only indirect context by referring to an outdated fact and retaining history.

  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 action ('Replace') and a clear object ('an outdated fact'), and the qualifier 'while retaining its history' differentiates this from related memory operations such as memory_suppress or memory_store. The purpose is immediately identifiable.

  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 phrase 'outdated fact' implies the appropriate use case: to exchange a stale memory for a current one. However, the description does not give explicit when-not-to-use guidance or name an alternative tool for the comparison, leaving the usage context mostly inferred.

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

• memory_linkA
  3.7/5.0
  Behavior3/5

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

  The description states the action ('Connect two memories') and implies a persistent graph update, but it does not disclose side effects, safety, validation, idempotency, or response behavior. With no annotations provided, the description carries the full burden, so this is only 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.

  Conciseness5/5

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

  The description is three short, front-loaded sentences with no filler. The core action is stated first, followed by practical guidance on the relationship type and a retrieval entry point.

  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 description covers the core linking intent and points to how to retrieve linked memories. But it leaves out parameter-to-role mapping, return values, and behaviors around missing/invalid IDs. Given no output schema and no annotations, an agent would still have to infer several operational details.

  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?

  Schema description coverage is 0%, and the fields have only titles and types. The description explains the semantic of RESPONDS_TO as 'a new handoff, verification, or fix addresses an earlier memory,' which helps, but it does not explicitly map source_memory_id to the new memory and target_memory_id to the earlier memory. The description only partially compensates for the schema gap.

  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 opens with 'Connect two memories with an explicit graph relationship,' which names a specific verb, resource, and purpose. It is clear and distinct from sibling tools like memory_store or memory_recall, though it does not explicitly position itself against memory_link_batch.

  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?

  It gives clear guidance on when to use the RESPONDS_TO relationship and explicitly points to memory_recall(include_neighbors=true) for retrieving linked memories. It could be stronger by mentioning memory_link_batch for bulk linking, but the direction is clear.

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

• memory_store_batchA
  4/5.0
  Behavior2/5

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

  Without annotations, the description carries the full burden of behavioral disclosure, but only says the memories are 'durable' and stored as a batch. It does not mention whether writes overwrite existing memories, what happens on partial failure, whether any permissions are required, or what is returned to the caller.

  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 two sentences, front-loads the purpose, and then gives the necessary item-shape guidance without unnecessary padding. Every sentence 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 single-parameter schema and no output schema, the description covers the main operational need: what to pass in each memory item. It is not fully complete because the semantics and types of optional fields like memory_class, confidence, provenance, and context are left undefined, but the core invocation detail is covered.

  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 only an array of untyped objects, so the description compensates by specifying that each item must be a dict with 'content' and optional keys like 'confidence' and 'metadata'. This is useful, though it does not explain the meaning or expected type of each optional key.

  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 the specific verb 'store' with the resource 'durable project memories' and the qualifier 'in a single batch'. This clearly distinguishes it from sibling memory_store by emphasizing batch operation, making the tool's purpose immediately identifiable.

  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 phrase 'multiple ... in a single batch' provides clear context for when this tool should be used, i.e., when storing several memories at once. However, it does not explicitly mention memory_store as the single-item alternative or state when not to use this tool, so it lacks explicit exclusions.

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

• memory_recallA
  4.5/5.0
  Behavior4/5

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

  Even though no annotations are provided, the description discloses important behavior: context is soft by default, strict_context=true isolates the query, include_neighbors hydrates graph neighbors, neighbor_limit bounds hydrations, and metadata reports when more neighbors were available. It does not explicitly state read-only behavior or broader response shape, but it covers the core operational traits clearly.

  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, front-loaded with the core purpose, and every sentence adds a distinct operational fact. It avoids restating the schema and packs useful behavioral detail into a short, scannable paragraph.

  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 description covers most invocation-critical behavior and even mentions metadata availability. However, the agent has no output schema to lean on, and depth and token_budget remain unexplained. The phrase 'Search memories by text, context, activation, and confidence' also introduces activation and confidence without mapping them to schema parameters, leaving some ambiguity in how to leverage those signals.

  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 provide meaning for parameters. It does so for context, strict_context, include_neighbors, neighbor_limit, limit, and edge_types, even giving an example edge type 'RESPONDS_TO'. However, depth and token_budget are present in the schema but left unexplained, so the compensation is not complete.

  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 specific verb-resource pairing: 'Search memories by text, context, activation, and confidence.' It clearly distinguishes this tool from sibling memory_context by saying, 'Use memory_context to assemble working context.' An agent can reliably identify memory_recall as the targeted-memory-search tool.

  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?

  'Use this for a targeted question. Use memory_context to assemble working context' explicitly tells the agent when memory_recall is appropriate and when the sibling is better. It also explains when to set strict_context, include_neighbors, and edge_types, so selection and invocation conditions are directly actionable.

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