Server Quality Checklist

Tool Scores

• list_image_tagsA
  3.9/5.0
  Behavior3/5

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

  No annotations provided, so description fully responsible. Discloses read-only behavior, sorting, and filtering. Lacks details on error cases or pagination, but adequate for basic understanding.

  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?

  Three sentences, each informative and front-loaded. Efficiently conveys purpose and usage without excess.

  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?

  No output schema, but description explains return values (sorted tags) and filtering. Could be more explicit about output format, but overall covers key aspects for a list tool.

  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 coverage is 100%, so baseline is 3. Description adds context about semantic version tags and regex filtering, adding some value beyond schema, but not significantly compensating.

  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?

  Clearly states 'List available tags for a container image' with specific verb and resource. Differentiates from siblings like get_latest_image_tag by emphasizing it returns all tags sorted newest to oldest.

  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?

  Provides context: 'Useful when you need to see what versions are available or find a specific version pattern.' Mentions filtering by regex. Does not explicitly exclude or compare to alternatives, but context is sufficient.

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

• check_image_updateA
  4.2/5.0
  Behavior3/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 the main behavior (comparison and update type) but lacks details on error handling, authentication needs, or whether the operation is read-only. The transparency is adequate for a simple check 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?

  Three sentences with no superfluous information. The first sentence directly states the purpose, followed by a brief mechanism and a use case. Minimally sufficient 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 low complexity (2 simple params, no output schema), the description covers purpose, use case, and output nature (update type). It omits exact return format, but the mention of 'tells you' and 'major, minor, or patch' provides enough context for agent selection.

  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 100% with both parameters described. The description adds value by implying semantic versioning (major/minor/patch) and the context of comparing to 'latest available version,' which goes beyond the schema's examples.

  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 checks if a newer version of a container image is available by comparing a current tag to the latest version, and reports the update type (major, minor, patch). This distinct purpose is differentiated from sibling tools like get_latest_image_tag and search_images.

  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 a clear usage scenario: auditing Dockerfiles or Kubernetes manifests for outdated images. However, it does not explicitly state when not to use this tool or mention alternatives for comparison.

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

• get_latest_image_tagA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description must carry the transparency burden. It explains the tool returns a stable semantic version tag and gives examples, but doesn't clarify the ordering mechanism for 'latest' or behavior when no semver tag exists. Slight gap, but still good.

  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 well-structured: concise first sentence, followed by usage guidance, warning block, and examples. Every sentence adds value, no fluff. Front-loaded with the main action.

  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?

  No output schema, but the description implies the return type (a version string, used in Dockerfiles/Kubernetes). The examples illustrate the mapping from input to output, though they show full image:tag format which may cause slight confusion about the exact return value. Overall fairly complete given the tool's simplicity.

  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 coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema; 'major_version' and 'include_prerelease' are only documented in the schema, not in the description. No added value.

  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 gets the latest semantic version tag for a container image, specifying the output 'latest stable semantic version tag' and providing concrete examples. It distinguishes itself from siblings by noting when to use alternatives like search_images or find_image.

  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?

  Explicitly says 'Use this when you KNOW the exact image path' and provides clear alternatives for when the path is unknown (search_images, find_image, checking GitHub). This leaves no ambiguity about usage context.

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

• search_imagesA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses that the tool searches Docker Hub, returns full names, and cannot search GHCR. It does not mention rate limits or read-only nature, but these are less critical 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.

  Conciseness4/5

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

  Well-structured with clear sections, emoji for emphasis, and examples. Every sentence adds value, though the content could be slightly more concise without losing clarity.

  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 no output schema, the description adequately explains that results include full image names. It covers the essential context for tool selection and usage. Missing details like pagination or result fields, but sufficient for typical use.

  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 100% with descriptions and defaults. The description adds value through concrete examples showing how queries are interpreted (e.g., 'radarr' finds linuxserver/radarr, hotio/radarr), which aids understanding beyond the schema.

  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 it searches for container images by name, provides examples, and distinguishes from sibling tools like find_image and get_latest_image_tag. The emoji warning and explanation of when to use it make the purpose unambiguous.

  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?

  Explicit guidance to 'USE THIS FIRST' when image path is unknown, and to use find_image or get_latest_image_tag after obtaining the full name. Also warns about GHCR's lack of search API, directing to alternative approaches.

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

• find_imageA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: tries Docker Hub, GHCR, Quay.io; explains trial order; and clearly states limitation about GHCR org names. No surprises.

  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?

  Well-structured with bold sections and bullet points. Slightly long but every sentence adds value. Front-loads purpose and key guidance.

  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 simple tool with one parameter and no output schema, the description covers purpose, usage, limitations, and examples comprehensively. No gaps given the context.

  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 already describes the 'name' parameter well (100% coverage). The description adds extra value with format advice ('org/repo'), best practices, and concrete examples, exceeding schema info.

  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 finds an image by name across multiple registries, with specific verb 'Find' and resource 'image'. It distinguishes from siblings by focusing on discovery, not updates or tag listing.

  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?

  Provides best practices (e.g., use org/repo format, check project website) and explicit limitation about GHCR. Lacks explicit when-not-to-use vs sibling tools, but guidance is still strong.

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