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

readOnlyHint=true already tells the agent this is a safe read. The description adds a real behavioral constraint beyond the annotation: it only covers *current* catalog images and tags, not historical or released ones. It does not disclose whether results are scoped to a user/workspace or how results are ordered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

One sentence, front-loaded with the verb and resource, no filler. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the single parameter is fully documented. The description is nearly sufficient, though a brief note on how this differs from the sibling vulnerability-lookup tools would close the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single cve_id parameter, and the schema already documents the accepted advisory ID formats. The description adds nothing about parameter semantics, so the baseline 3 applies.

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

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

States a specific verb ('Find') and a precise resource/scope ('which current catalog images and tags a CVE affects'), which is the reverse direction of siblings like get_tag_vulnerabilities_tool and get_catalog_vulnerabilities_tool. It does not name those siblings, so the differentiation is implied rather than stated.

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

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

There is no when-to-use guidance, no exclusions, and no named alternative (e.g., when to prefer get_catalog_vulnerabilities_tool instead). The only usage signal is the implicit 'current catalog' scoping.

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

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

readOnlyHint=true already establishes this as a safe read, so the bar is lower. The description adds a useful nuance: catalog_summary is unfiltered while images/matched/cves honor the filters. It does not disclose pagination/limit behavior or how many tags are aggregated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short paragraphs, front-loaded with the scope and followed by the one non-obvious field-semantics point. No filler or restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return structure need not be explained, and all three optional parameters are schema-documented. The description covers scope and filter semantics adequately; only minor details like default limit behavior (50) are left to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds filter-application semantics beyond the schema: it tells the agent which output fields reflect image and min_severity (and, implicitly, that catalog_summary does not). That is genuine value over the per-parameter descriptions.

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

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

States a specific verb and resource ('Get catalog-wide CVE stats') plus scope ('across every current tag, with per-image counts'), which distinguishes it in practice from get_tag_vulnerabilities_tool and get_release_vulnerabilities_tool. It does not name those siblings explicitly, so the differentiation is inferential rather than stated.

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

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

The catalog-wide scope implies when this tool applies (aggregate view rather than single tag/release), and the second paragraph clarifies how the filters affect results. There is no explicit when-to-use-vs-alternative statement naming get_tag_vulnerabilities_tool or find_cve_tool.

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

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

readOnlyHint=true already declares this a safe read, and the description adds what fields come back (status, dates, public status note, deep_link) plus the dual key/title lookup. It omits notable behavior such as what happens when the title is ambiguous or the request is not found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences, front-loaded with the purpose and lookup keys. The enumerated return fields are slightly redundant given an output schema exists, but the text is efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values do not need spelling out, and one required parameter is fully specified. The only real gap is failure/ambiguity behavior for title-based lookups, which is minor for this simple read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents the request parameter with example formats for both HUM key and title. The description adds nothing beyond restating those accepted forms, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get one image request') and names the two lookup keys, so it is clearly the single-record counterpart to list_image_requests_tool. It never explicitly names that sibling, though, which keeps it just 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.

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

The description implies the usage condition — you must already have a HUM key or image title — but never says when to prefer this over list_image_requests_tool or find_cve_tool, nor what to do if the key is unknown. Usage is inferred rather than stated.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the enumerated fields (summary, streams, variants, licenses, architectures) duplicate what the output schema almost certainly exposes. No additional behavioral context is offered — no pagination, size, cost, or auth notes. Beyond the annotation, the description adds little.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single front-loaded sentence with no wasted words; the verb and resource lead. It is perhaps too terse to carry the routing or parameter nuance, but strictly on conciseness it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 100% parameter coverage, the description needn't explain returns or params, and annotations cover safety. The one real gap is selection guidance among the many sibling tools, which leaves it merely adequate rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so 'name', 'include_readme', and 'readme_max_chars' are fully documented in the schema including examples and defaults. The description adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get an image's metadata') and enumerates the categories returned (summary, streams, variants, licenses, architectures). It implicitly separates itself from tag-level and list-level siblings, though it never names list_images_tool or get_tag_details_tool to make the distinction explicit.

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

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

There is no guidance on when to call this versus get_tag_details_tool, list_images_tool, or the SBOM/vulnerability siblings. The agent must infer that this is the image-level (not tag-level) lookup without any stated condition or exclusion.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read. The description adds that it returns container config and provenance, but discloses no additional behavioral traits such as permission requirements or quirks beyond what annotations and the output schema provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single tight sentence with zero filler; the resource and its identifying key (digest) are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a simple read-only lookup with full schema descriptions and an output schema covering return values. The description adequately frames what is fetched (config and provenance) and by what key, leaving little for the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all three parameters (name, digest, arch) are already documented in the schema. The phrase 'by digest' highlights the key identifier but adds no syntax or format meaning beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (Get) and resource (container config and provenance of a historical release) keyed by digest. An agent can distinguish it from list/get_image tools, though it does not explicitly name siblings like get_release_history or get_release_sbom.

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

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

Usage is implied: it operates on a past release identified by a digest, and the schema notes the digest comes from get_release_history. However, there is no explicit when-to-use/when-not statement or alternate-tool routing, so the agent must infer.

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

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

readOnlyHint=true already declares this as a safe read, so the safety bar is covered by annotations. The description adds the returned fields (digest, date, source commit), but that information overlaps with the existing output schema, and it says nothing about pagination or ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single sentence with no filler, and the resource scope is front-loaded so the reader gets the key constraint immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only listing tool with a full output schema and complete parameter descriptions, this is nearly sufficient. The only real gap is disambiguation from the sibling release tools, which is not needed for correct invocation itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so name, stream, variant, and limit are already fully documented in the schema. The phrase 'of a stream and variant' loosely maps to two params but adds no format or default detail beyond what the schema provides.

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

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

Clear verb+resource+scope: 'List past releases ... of a stream and variant' tells the agent it is a historical listing narrowed by stream and variant. However, it never differentiates itself from the closely-named sibling get_release_details_tool, so the agent must infer which to call.

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

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

No when-to-use, when-not-to-use, or alternative is stated. There is an obvious ambiguity with get_release_details_tool (details vs history) that the description leaves entirely unresolved, so guidance is only implicitly available.

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

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

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description's only added behavioral fact is that the lookup targets a historical release rather than a current one. It says nothing about pagination limits (default 100, max 1000) or arch defaults, though those are documented in the schema rather than needed here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single front-loaded sentence with zero filler and no repetition of the title. It is arguably too terse for a six-parameter tool, but nothing in it is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and annotations plus full schema coverage handle safety and parameters. The remaining gap is the missing relationship to get_release_history_tool (digest provenance) and get_sbom_tool, which the agent must infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: name, digest, arch, limit, category, and package_query all carry their own descriptions with examples, defaults, and enum values. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource (get the SBOM) plus a scoping qualifier (of a historical release by digest), which separates it from the sibling get_sbom_tool that presumably serves current tags. It never names an alternative sibling explicitly, so the differentiation is inferable rather than stated.

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

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

There is no when-to-use guidance, no prerequisite that a digest from get_release_history_tool must be obtained first (that hint lives only in the schema), and no routing between this tool, get_sbom_tool, and get_release_vulnerabilities_tool. The phrase 'by digest' hints at the required input but does not tell the agent when this tool is the right choice.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It confirms the payload is a CVE scan of an archived release, but says nothing about result size, default limiting behavior, or that severity filtering is available — all of which live only in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single lean sentence with the resource and key scope front-loaded; nothing is wasted. It is arguably too terse to carry structure, but there is no filler to cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return values and annotations cover safety, so the remaining burden is disambiguation among the three vulnerability tools, which this description only partially handles. Adequate but with a clear gap for a tool sitting in a dense sibling cluster.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters (name, digest, limit, min_severity) are already documented in structured form; the baseline of 3 applies. The description reinforces 'by digest' as the lookup key but adds no formatting, default, or usage detail beyond the schema.

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

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

States a specific verb and resource ('Get the CVE scan') plus the scope that separates it from the sibling tag/catalog vulnerability tools: a historical release identified by digest. It does not name those siblings explicitly, so an agent must infer the distinction, but the noun phrase 'historical release by digest' is a real differentiator.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative is named even though get_tag_vulnerabilities_tool and get_catalog_vulnerabilities_tool are close siblings. The only routing hint ('by digest') appears in the schema's digest description, not in the tool description.

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

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

readOnlyHint=true already establishes this as a safe read. The description adds real context beyond that: counts span all architectures while the package list is architecture-filtered and filterable. It says nothing about result size, truncation, or the limit default, though the output schema carries those details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

One sentence, front-loaded with the verb and resource, then the payoff. Nothing is redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't describe return values, and the schema fully covers the inputs. It is complete enough to call correctly, falling short only on sibling routing against get_release_sbom_tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are documented in the schema with defaults, patterns, and enum values. The description only gestures at 'filterable' and adds no syntax or constraint detail beyond it, so the baseline 3 applies.

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

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

The description gives a specific verb ('Get') and resource ('a tag's SBOM') and even previews the payload shape (counts per arch, filterable package list). The word 'tag's' implicitly separates it from the sibling get_release_sbom_tool, but that routing is left for the agent to infer rather than stated.

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

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

No when-to-use, when-not-to-use, or alternative guidance is given. With get_release_sbom_tool in the sibling list, an explicit statement that this covers image tags rather than releases would have resolved the obvious ambiguity; nothing here does that.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's remaining job is lighter. It does add useful behavioral context by naming the returned artifacts (Containerfile, provenance, SLSA level) and flagging that results vary per architecture, but it says nothing about missing-tag behavior, multi-arch result shape, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, front-loaded with the action and scope, then a compact field enumeration. Efficient overall, though the long field list partially restates what the output schema already provides.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and read-only annotations declared, the description need only frame the call, which it does: it identifies the resource, the per-architecture dimension, and the kind of content returned. Only error/empty-result behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so name, canonical and arch are fully documented in the schema, making 3 the baseline. The phrase 'per architecture' reinforces the arch parameter's role but adds no format or default semantics beyond the schema's own 'omit for all' note.

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

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

Specific verb (Get) plus resource (tag details) with an explicit scope qualifier ('container config and provenance per architecture') and a concrete enumeration of what is returned. This clearly separates it from get_sbom_tool and get_tag_vulnerabilities_tool, though it never names a sibling or states the boundary explicitly.

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

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

Usage is only implied by the scope ('per architecture') and the field list; there is no statement of when to call this versus list_tags_tool or get_image_tool, and no prerequisites. An agent can infer the intent but must guess the routing.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's added burden is light. It discloses the response shape (summary counts plus per-CVE component breakdown), but says nothing about truncation when limit caps the list, ordering, or whether an unscanned tag returns empty vs error.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single front-loaded sentence with no filler; the resource and the return payload are stated up front. It is arguably too terse for a tool with three sibling vulnerabilities variants, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values, and the schema fully covers the four parameters. The only real gap is sibling differentiation and any prerequisite/error behavior, which keeps it short of a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: name, canonical, limit (default 50) and min_severity are all documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get the CVE scan for a tag') and enumerates the payload ('summary counts and each CVE with components'). It implicitly separates itself from release- and catalog-scoped vulnerability siblings by saying 'for a tag', though it never names them explicitly.

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

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

There is no when-to-use guidance and no mention of the near-identical siblings get_release_vulnerabilities_tool and get_catalog_vulnerabilities_tool, which an agent must choose between. 'For a tag' hints at scope but leaves the routing decision to inference.

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

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

readOnlyHint=true already declares the safety profile, and the description adds useful context by enumerating the response fields (HUM key, title, status, deep_link). It says nothing about pagination, result caps, or ordering, which matter for a list operation against a remote site.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences, front-loaded with the action and source, then the return shape, then the filters. No wasted words; the enum values repeated in the description are the only mild redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained in depth, and the description still names the payload shape and the data source. Missing pagination and ordering behavior keeps it short of complete for a list tool, but it is sufficient to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are fully documented in the schema, including the enum values and the case-insensitive substring behavior. The description restates the same filtering options without adding syntax or combination semantics, so baseline 3 applies.

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

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

States a specific verb and resource ('List image requests from images.redhat.com/image-requests') and names the returned fields, so the agent knows exactly what it gets back. It never names the sibling get_image_request_tool, so the list-vs-fetch distinction is only implied by the verb.

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

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

The closing sentence implies usage contexts (filter by status or title/key substring) but gives no explicit when-to-use or when-not-to-use guidance, and does not route the agent to get_image_request_tool when a single request is wanted. Adequate but leaves the sibling decision to inference.

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

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

The readOnlyHint=true annotation already establishes the safe read-only nature, so the description only needs to add context. It usefully discloses what the response contains (streams, variants, pull URL, full category list), but says nothing about pagination, result limits, or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences with no filler; the core scope is front-loaded and the secondary note about categories follows. Every sentence carries information the agent can act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values, and it correctly avoids that. With only two optional, fully documented parameters and read-only annotations, nothing critical is missing, though a brief routing note versus get_image_tool would make it fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents both `query` (case-insensitive substring of name or summary) and `category` (exact application_category). The description adds only one marginal detail — that valid category values come from the response's own category list — which is a helpful workflow hint but no syntax beyond the schema. Baseline 3 applies.

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

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

The description gives a specific verb and resource ('List images in the Hummingbird catalog') plus the content returned ('streams, variants and pull URL'), which is more informative than the bare tool name. It is clear what the tool does, but it never names or contrasts with siblings like get_image_tool, so the differentiation is only implied by the plural/singular distinction.

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

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

Usage is only implied: 'list images' for discovery, and the note that the response lists every category 'for use as `category`' hints at a filter-discovery workflow. There is no explicit when-to-use versus get_image_tool, no when-not-to-use, and no stated prerequisites.

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

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

readOnlyHint=true already establishes this as a safe read, so the description's burden is lighter. It adds one genuine behavioral trait beyond the annotations — that only current, non-superseded tags are returned unless include_superseded is set — but says nothing about pagination, result limits, or ordering, which matter for a list operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences with no filler; the primary action and return fields come first, followed by the filtering caveat. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, and all four parameters are schema-documented. The only substantive gap for a list tool is any mention of pagination or result volume, which is left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so name, stream, variant, and include_superseded are all documented in the schema itself. The description restates the include_superseded semantics ('Only current (non-superseded) tags unless include_superseded is set') but adds no syntax or format detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('List an image's tags') and enumerates the returned fields (pull_url, digest, canonical tag, sizes), which distinguishes it from detail-oriented siblings like get_tag_details_tool. It does not explicitly contrast itself with list_images_tool or get_tag_details_tool, so sibling differentiation is implied rather than stated.

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

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

Usage is only implied by the tool's nature (enumerating tags for an image); there is no explicit when-to-use statement and no naming of alternatives such as get_tag_details_tool for a single tag. The note that superseded tags are excluded by default is the only guidance-like content, and it concerns filtering rather than tool selection.

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