Server Quality Checklist

Tool Scores

• memory_repairC
  2.8/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 burden. It does disclose that semantic notices are advisory and imposes read-both-memories and do-not-forward constraints, which is useful. But it never states whether operations like history cleanup or backup replay are destructive, reversible, or permission-gated, leaving the tool's overall side effects opaque.

  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 first sentence packs an exhaustive comma-separated list of operations into a dense, ambiguous clause, while the second sentence contains essential usage and safety details. It is not overly long, but the structure buries actionability in a pile of items; a clearer mapping of task values to operations would be more effective.

  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 two generic parameters, no annotations, and zero schema descriptions, the description alone is insufficient for a multi-purpose maintenance tool. It points to a help topic but omits concrete argument semantics, side effects, and sibling differentiation needed to invoke it correctly.

  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 schema only shows generic task and data fields. The description demonstrates task="help" for notice handling but never enumerates valid task values or explains the data object at all, so an agent cannot reliably construct arguments for the listed operations.

  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 frames the tool as a broad maintenance umbrella, listing many operations (evidence rebuild, conflict scans, duplicate sweeps, history cleanup, backup replay, notices, semantic runtime control) rather than a single specific verb+resource. It does not differentiate from sibling tools memory_review, memory_govern, or memory, so an agent would struggle to know exactly when this is the right tool.

  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?

  There is explicit guidance to use memory_repair(task="help") for notice handling and semantic_control actions, plus a caution to read both memories before dismissing or resolving and never pass a notice to judge or resolve_conflict. However, no guidance is given for the other listed maintenance tasks, and there is no 'when not to use' or comparison with sibling tools.

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

• memory_governB
  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 full burden of behavioral disclosure. It does disclose that actions are state-changing and gated on explicit user authorization, which is important safety-relevant context. But it doesn't detail what gets retired, merged, or changed, and it defers impact notes and confirmation semantics to the help action rather than providing them up front.

  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 concise and front-loaded with the tool's governing purpose, then moves to the authorization guardrail and the help-first instruction. It contains no filler and each sentence contributes useful guidance. It could be slightly more structured, but it is appropriately sized.

  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 gives enough to know this is a governance tool and warns that authorization is required, but it deliberately defers exact actions, fields, impact notes, and confirmation semantics to a runtime help call. That is a reasonable pattern for a dispatcher-style tool, but it leaves an agent without full context until that help call is made.

  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 only mentions action="help" and does not explain the data parameter or enumerate the accepted action values. The agent would have to call the tool with action="help" before it can meaningfully understand the parameters.

  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 names concrete governance operations: retire, merge near-duplicates, apply/replan/resolve conflicts, confirm, and manage workspaces. This is clear enough to identify the tool as the management/curation surface among siblings like memory_review and memory_repair. It lacks a single precise verb+resource phrasing, but it is not vague or tautological.

  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 explicitly states a key precondition: every state-changing action requires explicit user authorization for that action, with authorized=true. It also directs the agent to call memory_govern(action="help") to learn exact actions and confirmation semantics. However, it does not discuss when to prefer this tool over memory_review or memory_repair, so sibling routing guidance is incomplete.

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

• memory_reviewA
  3.7/5.0
  Behavior4/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 explicitly states the operation is read-only and adds a useful behavioral caveat about inspecting conflict_detail before judging a conflict. While it does not address rate limits or auth, those are less critical for a read-only inspection tool, and the description provides the key behavioral context.

  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, front-loading the core purpose in the first sentence and immediately providing actionable usage guidance. Every sentence earns its place, and there is no redundant filler. The structure makes it easy for an agent to quickly extract the essential information.

  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 is reasonably complete for a simple review tool: it lists the available views, points to help for accepted fields, and warns about conflict_detail. However, the `data` parameter remains completely unexplained, and there is no explicit guidance about when not to use this tool relative to siblings. The output schema mitigates some return-value ambiguity, but the parameter gap keeps this from being fully complete.

  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, but it only partially explains the `view` parameter by pointing to view="help" for accepted fields. The `data` parameter is never mentioned, leaving a significant gap in understanding. This makes the description insufficient for fully correct parameter use.

  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 labels the tool as 'Read-only inspection' and enumerates the specific views it exposes (overview, doctor, conflicts, conflict_detail, etc.), making the tool's intent evident. It differentiates from siblings like memory_govern and memory_repair by emphasizing inspection rather than governance or repair. The 'doctor' view is slightly ambiguous without further explanation, but the overall purpose is clear.

  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 usage directives: 'Use memory_review(view="help") for accepted fields' and 'Inspect conflict_detail before judging a conflict.' These are concrete, actionable instructions for when and how to use the tool. It does not explicitly contrast with alternatives like memory_govern or memory_repair, but the 'Read-only' framing implies when this tool is appropriate.

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

• memoryA
  3.8/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, and it adds real behavioral detail for find: index-page semantics, include_content=true for full text, page-scoped scoring, and a size block. However, it does not disclose side effects, permissions, or outcome implications for remember, update, judge, or status, so behavioral coverage is incomplete across the tool's surface.

  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 front-loaded with the action list and uses three compact paragraphs, each with a distinct job: overview, help-first advice, and find semantics. There is no filler or repetition; every sentence adds information.

  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 fully details only the find action and points to help for the rest; remember, read, update, judge, and status semantics are left undisclosed. Sibling tool boundaries are not addressed, so an agent still needs extra discovery before confidently using all operations.

  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 coverage is 0%, so the description must compensate. It lists the accepted action values, mentions action='help', and names concrete data fields such as include_content and tags_filter. The full data object shape is left to the help action, but this partial enumeration is meaningful.

  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 'Daily memory operations' and enumerates the supported verbs (remember, find, read, update, judge, status, help), making the dispatch role clear. It does not fully explain what each operation does, and 'memory operations' is somewhat generic, but it is enough to distinguish this tool from the memory_review/govern/repair siblings.

  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 explicit guidance to call action='help' before relying on results, and advises rewording the query or adding tags_filter instead of deep paging. It does not name sibling tools or state when memory_review/govern/repair should be chosen instead, so exclusions/alternatives are missing.

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