Server Quality Checklist

Tool Scores

• manage_memoryD
  1.8/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 disclosing behavioral traits. It gives no information about side effects, permissions, state changes, or whether actions are destructive. The 26 possible actions include delete, archive, and project_apply, but the description provides zero detail about their consequences.

  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 only one sentence, but that brevity comes at the cost of necessary information. It is under-specified and fails to convey the tool's complexity, making it more of a placeholder than a genuinely concise explanation.

  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's complexity (39 parameters, 26 actions, no annotations), the description is extremely inadequate. Even though an output schema exists, it does not compensate for the missing action semantics, parameter relationships, or usage context, making the tool nearly impossible to use correctly from the description alone.

  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 explanation for any of the 39 parameters. It does not even mention the required 'action' parameter or its enum values, leaving the agent to guess which parameters apply to which actions.

  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 states it manages 'ordinary memory' and 'explicit project control-plane operations,' which identifies a broad resource area but lacks specificity about what actions can be performed. It does not differentiate from sibling tools like maintain_memory_lifecycle, which likely overlaps in lifecycle actions such as archive, expire, and delete.

  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 its siblings (assemble_context, maintain_memory_lifecycle). It does not mention context assembly or lifecycle maintenance as alternatives, leaving the agent to infer appropriate usage from the listed actions.

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

• maintain_memory_lifecycleD
  1.9/5.0
  Behavior1/5

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

  With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states that it 'runs explicit lifecycle maintenance' and 'recovers safe prepared card writes', but does not explain side effects, required permissions, whether actions are destructive, or what 'safe' means. This is critically opaque for an operation-oriented tool.

  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 sentence with no wasted words, which is concise in length. However, the phrasing is unclear and not front-loaded with a plain-language explanation of the tool's primary purpose, making it less effective than it could be despite its 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?

  Despite having an output schema, the description is wholly inadequate for a specialized tool. It does not explain the underlying concept of 'cards', what lifecycle maintenance entails, when recovery is needed, or what the output represents. With no annotations and no parameter guidance, this leaves the agent without essential context to use the tool correctly.

  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 tool has 0 parameters, so the baseline for this dimension is 4. The description does not need to elaborate on parameter meanings because there are none, and the empty input schema is fully consistent with this.

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

  Purpose2/5

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

  The description uses vague, domain-specific jargon ('lifecycle maintenance', 'safe prepared card writes') without explaining what these mean or what the tool actually does. It is not a tautology, but it fails to clearly identify the tool's action and resource, especially compared to siblings like assemble_context and manage_memory.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines1/5

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

  The description provides no guidance on when to use this tool versus alternatives such as assemble_context or manage_memory. There are no conditions, prerequisites, or exclusions mentioned, leaving the agent without any signal for tool selection.

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

• assemble_contextC
  2.3/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It vaguely suggests a selective role ('minimal', 'relevant') but does not state whether it modifies state, requires auth, returns specific data formats, or has side effects. This is a significant gap for a tool with 16 parameters.

  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 one sentence, making it short, but for a tool with 16 parameters and no annotations, this is under-specification rather than genuine conciseness. The single sentence does not earn its place by providing sufficient detail.

  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's complexity (16 params, no annotations, no sibling differentiation), the description is severely incomplete. It omits return behavior (despite an output schema existing), usage context, and parameter semantics, making it nearly impossible for an agent to use correctly.

  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, but it does not. The one-sentence description adds no parameter meaning beyond the raw parameter names, leaving 16 parameters (including budgets, keys, and flags) undocumented.

  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 'Assemble' and names the resources (Core Context, policy, relevant memory) for a task, which clearly distinguishes it from sibling memory-management tools. However, terms like 'Core Context' and 'effective policy' are jargon that could benefit from elaboration.

  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 no guidance on when to use this tool versus the siblings (manage_memory, maintain_memory_lifecycle), no exclusions, and no alternative recommendations. The purpose implies some context, but usage context is entirely absent.

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