Server Quality Checklist

Tool Scores

• inspect_dangling_refsA
  3.8/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint, and the description repeats 'Read-only.' It adds the scope of audit findings but no additional behavioral context such as error behavior, performance implications, or what the tool does not inspect. With the safety profile already covered by annotations, this is adequate but not rich.

  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 short sentences totaling 19 words. It front-loads the verb, resource, and primary finding types, and 'Read-only' is a harmless, minimal redundancy with the annotation. Every word contributes to understanding what the tool does.

  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?

  The tool has 4 parameters, 2 siblings, and subtle optional-parameter interactions, but the input schema is exceptionally detailed and an output schema exists, so the short description is sufficient for invocation. The main completeness gap is the lack of an explicit decision rule versus diagnose_cache_graph, preventing a 5.

  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 100%, with detailed parameter documentation for cache, rootIds, includeUnreachable, and includeNormalizationGaps, including defaults and effects on findings. The description itself adds no parameter-level detail beyond the cache.extract() context, so the baseline of 3 applies.

  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 the specific verb 'Audit' and names the exact resource: a serialized Apollo InMemoryCache from cache.extract(). It then enumerates the three distinct finding categories (dangling __refs, unreachable entities, normalization gaps), which makes the tool's scope precise and differentiates it from the write-oriented patch_cache and the broader-sounding diagnose_cache_graph.

  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?

  Usage is implied: use this when you have cache.extract() output and need to audit for ref/reachability/normalization issues. However, there is no explicit when-to-use versus alternatives, no exclusions, and no routing to sibling tools such as diagnose_cache_graph. The context is clear but the guidance is not explicit.

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

• patch_cacheA
  3.8/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false and idempotentHint=true, and the description adds meaningful behavioral context beyond those flags: it explicitly states that dryRun validates without mutating the cache, that the modified store is returned, and that gc is optional. This goes beyond what the annotations alone convey, while not contradicting them.

  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 with no filler. The core action is front-loaded, and the dryRun safety note earns its place as a critical usage caveat. It is appropriately sized for the tool's complexity.

  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 very rich input and output schemas, the description only needs to establish the operation intent, the mutating nature, and the dryRun flow, which it does. The main missing element is explicit guidance on when to choose this tool over the siblings, but the schema and annotations cover most invocation 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 100%, so the schema already thoroughly documents each parameter and nested operation shape. The description mentions modify/evict and dryRun, but it does not add parameter-level meaning beyond what the schema provides. The baseline of 3 applies because the schema carries the heavy lifting.

  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 applies declarative repairs (modify/evict, optional gc) to a serialized cache and returns the patched store. The specific verb 'apply' plus the resource 'serialized cache' and operation types distinguish it from the sibling tools inspect_dangling_refs and diagnose_cache_graph, which are non-mutating inspection tools.

  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 this tool is for mutating a serialized cache and mentions dryRun for validation, but it gives no explicit guidance on when to use patch_cache versus the sibling tools. No exclusion criteria or alternative routing is provided, so an agent must infer the appropriate context from the tool name and sibling names alone.

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

• diagnose_cache_graphA
  4.3/5.0
  Behavior4/5

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

  The annotations already declare readOnlyHint=true, and the description reinforces this with 'Plans only; never mutates.' It adds useful behavioral context about what the tool does not do and how its output should be consumed, going beyond the structured annotation without contradicting it.

  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 dense sentences deliver the pipeline, the return value, the downstream consumer, and the side-effect guarantee. Every phrase earns its place and the most important behavioral constraint is front-loaded.

  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?

  For a single-parameter tool with a fully documented schema and an output schema, the description is complete: it names the inputs, outputs, downstream action, and non-mutating behavior. Nothing an agent needs to invoke it correctly is missing.

  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 already provides 100% coverage, including a detailed description of the cache object and its structure. The tool description does not need to restate parameter details; the schema carries the semantic weight, so the baseline score of 3 is appropriate.

  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 names a specific verb and resource ('Run the full inspect -> reason -> plan graph over a serialized cache') and clearly differentiates itself from the sibling tools by describing its broader pipeline. It also states what it returns, making its role 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 provides clear context for when this tool fits: it produces patch operations that should be fed to patch_cache, and it is a planning-only step. It does not explicitly state when to prefer it over inspect_dangling_refs, but the pipeline framing and output-to-patch_cache relationship make the usage context clear.

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