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

The description adds context beyond the annotations (readOnlyHint=true, etc.) by explaining that the tool retrieves active recommendations that help identify issues affecting system availability, stability, performance, or security, and that higher impact/likelihood values indicate more critical issues. It also demonstrates typical usage patterns via examples. No contradiction with annotations is present.

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?

The description is relatively concise, starting with a clear purpose sentence followed by a brief overview of filters and numerous call examples. The examples are well-organized but somewhat lengthy. The structure is effective, though the examples could be trimmed or moved into a separate documentation section.

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?

Given that an output schema exists (not shown but stated 'Has output schema: true'), the description does not need to explain return values. It covers the tool's purpose, filter capabilities, and provides usage examples covering pagination, common filters, and sorting. The examples imply pagination and case usage. Minor gaps include no explicit mention of default sorting or the list nature of the response, but the examples compensate.

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?

The input schema has 100% description coverage for all 12 parameters, each with explicit descriptions. The description adds some value by providing specific call examples that show parameter usage (e.g., 'impact': '3,4', 'tags': ['insights-client/group=database-servers']). However, it does not significantly deepen semantic understanding beyond what the schema already 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?

The description clearly states the verb 'Get' and the resource 'active Advisor Recommendations for your account', and explains what these recommendations help identify (system availability, stability, performance, or security). It distinguishes from sibling tools like advisor__get_hosts_details_for_rule or advisor__get_recommendations_stats by focusing on active recommendations with user-controllable filtering, not host details or statistics.

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 provides numerous call examples that implicitly illustrate when to use various filters (e.g., for high risk, pagination, automatic remediation, security categories). However, it lacks explicit guidance on when to use this tool versus sibling tools, such as advisor__get_rule_details or advisor__get_rule_by_text_search. The verb 'Get' and the mention of filters imply retrieval, but no direct comparison to alternatives is given.

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?

Annotations already indicate readOnlyHint, idempotentHint, and no destructive action. The description adds value by detailing pagination, returned fields (system identification, impact metrics, RHEL version, hit counts, incident status), and no contradictions.

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?

The description is front-loaded with the main verb and resource, followed by details and examples. It is structured but slightly wordy; could be more concise.

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?

Given the presence of an output schema, the description adequately covers the return content and provides examples for common use cases, making it complete for the tool's purpose.

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?

With full schema coverage, baseline is 3. The description provides concrete call examples showing parameter combinations (pagination, filtering) and usage patterns, adding meaning 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?

The description clearly states it gets detailed information about RHEL systems affected by an Advisor Recommendation. It uses specific verbs and resource, but does not explicitly differentiate from the sibling tool advisor__get_hosts_hitting_a_rule.

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 provides usage examples and implies when to call this tool, but does not explicitly state when not to use it or name alternatives like the sibling 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?

Annotations already declare readOnlyHint=true, destructiveHint=false. Description adds call example but no additional behavioral context like permissions or rate limits. Adequate given annotations.

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?

Very concise: three sentences plus example. Front-loaded with main purpose. No unnecessary words.

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?

Output schema exists so return values not needed. For a simple read tool with one parameter, description is sufficient. Could mention if results are paginated or any limits, but not essential.

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 has 100% coverage for the one parameter with description. Description adds a call example showing the format for rule_id, adding value beyond 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?

Description states verb 'Get' and resource 'all RHEL systems affected by a specific Advisor Recommendation' clearly. Distinguishes from siblings like advisor__get_active_rules which lists rules.

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?

Says 'Use this to understand the scope of impact' but does not explicitly exclude alternatives or state when not to use. Implied but not explicit.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the description's 'Show statistics' is consistent. The description adds no additional behavioral details beyond the annotation set, meeting the baseline for transparency.

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?

The description is extremely concise with a single sentence purpose followed by three illustrative call examples. Every sentence adds value, and the structure is front-loaded for quick comprehension.

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?

Given the tool has an output schema, return values are covered externally. The description explains the tool's purpose, parameters, and typical usage patterns (all vs. filtered). It is fully complete for its complexity level and sibling context.

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 descriptions already explain parameters. The call examples add practical usage context (e.g., 'Statistics for the workspace workspace1') which enhances understanding beyond the schema, justifying a score above baseline.

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 explicitly states the tool shows statistics of recommendations across categories and risks, with a clear verb-resource combination. It distinguishes from sibling tools like advisor__get_rule_details or advisor__get_active_rules which focus on rules rather than aggregated statistics.

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?

Call examples demonstrate standard usage and filtering by groups or tags, giving clear context for parameter use. However, it does not explicitly state when not to use this tool or provide alternative suggestions, leaving some ambiguity.

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?

Annotations already indicate read-only and idempotent behavior. The description confirms exact text substring matching, which adds minimal behavioral detail beyond the annotations.

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?

Very concise: one sentence plus a usage example. No superfluous information, front-loaded with purpose.

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 need not be described. The description adequately covers the simple search functionality, though it omits details like case sensitivity.

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 covers the single parameter with a description. The tool description adds a call example demonstrating the parameter usage, providing extra context beyond the schema alone.

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 clearly states the tool finds Advisor Recommendations by exact text substring search. It distinguishes itself from siblings by specifying the search mechanism, but does not explicitly differentiate from similar advisor tools.

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 guidance on when to use this tool versus alternatives like advisor__get_rule_details or advisor__get_recommendations_stats. The example shows usage but does not provide context for choosing this search 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?

Annotations already indicate readOnly, idempotent, non-destructive. Description adds useful behavioral context by listing the types of information returned (impact, likelihood, remediation, articles), which goes beyond annotation hints.

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?

Description is concise with two sentences plus an example, front-loaded with purpose. Every sentence adds value without redundancy.

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 simple tool with one parameter and an output schema, the description adequately covers what the tool returns (impact, likelihood, etc.). It is contextually complete given the low complexity.

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% for the single parameter rule_id, which already describes the format. Description adds an example call, providing some extra context, but baseline is 3 due to full schema coverage.

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?

Description clearly states the tool retrieves detailed information about a specific Advisor Recommendation, including impact, likelihood, remediation, and articles. It distinguishes from sibling tools like advisor__get_active_rules (list) and advisor__get_rule_by_text_search (search).

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 guidance on when to use this tool versus alternatives. Sibling tools are listed but not contrasted, and no when-not-to-use scenarios are provided. Only a call example is given.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that the tool provides 'system-specific remediation steps,' which enriches the behavioral understanding without contradicting the annotations.

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?

The description is extremely concise with three short sentences: purpose, usage guideline, and an example call. Every sentence adds value, and it is front-loaded with the core action.

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 simple lookup tool with one parameter and an output schema, the description is complete. It explains the input (node_id) and the purpose (finding related Advisor Recommendations with remediation steps), which is sufficient for correct invocation.

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 describes node_id as 'Node ID of the knowledge base article or solution. Example: 123456'. The description repeats this with a call example but adds no new semantic information 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?

The description clearly states that the tool finds Advisor Recommendations using a Knowledge Base article or solution ID. It specifies the resource and action, but does not explicitly differentiate from sibling tools like 'advisor__get_rule_by_text_search' or 'advisor__get_rule_details', leaving some ambiguity.

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 explicitly says 'Use this when you have a Knowledge Base article or solution ID,' providing clear context for when to use the tool. However, it does not mention when not to use it or suggest alternative tools among the siblings.

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 and openWorldHint annotations already cover the safety profile. The description adds a behavioral cue that no information gathering is needed, but it does not describe pagination behavior, response size, or any side effects. With annotations present, this is acceptable but not deeply transparent.

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?

The description is very short and front-loads the call-to-action. However, the first sentence only repeats the tool title/name, slightly wasting the opening line. Overall, it is efficient and avoids bulk.

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?

Given the tool has a rich input schema with 100% parameter coverage and an output schema exists, the description does not need to explain return values. It adequately introduces the tool's purpose and immediate-call guidance, but does not provide deeper context like common usage patterns or relationship to other tools.

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 each parameter is already documented with its meaning and default. The description adds only generic 'filtering and pagination' context beyond the schema, which is unnecessary but not harmful.

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 clearly states 'List repositories with filtering and pagination options', identifying the specific verb, resource, and scope. It distinguishes itself from sibling tools, which target images, vulnerabilities, inventory, and RHSM, not content repositories.

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 explicitly says 'CALL IMMEDIATELY - No information gathering required,' giving clear guidance that no prerequisites are needed. It does not name alternatives or when-not-to-use, but among the siblings there is no competing repository-listing tool, so the context is sufficient.

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?

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: output varies depending on whether the latest-version check is enabled, and if so the agent should present a comparison URL rather than just the version.

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?

Four short sentences, all functional, with the scope restriction front-loaded before the usage conditions. The first line duplicates the title verbatim, which is mildly wasteful, but nothing else is 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?

An output schema exists, so return values need no further explanation, and the description already notes the conditional output behavior. For a zero-parameter read tool, the definition covers what an agent needs; only deep detail on the version-comparison mechanics is absent and that is schema territory.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No parameter-related gap exists.

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 states a specific resource and scope: 'MCP server package version only,' and explicitly excludes related-but-different concepts ('not image builds or compose status'). This distinguishes it cleanly from image-builder and other siblings that surface build/compose data.

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?

It gives an explicit, narrow trigger ('Use ONLY if the user asks for the Red Hat Insights MCP server version, or when there is an API or authentication issue'), which is exactly the when/when-not guidance an agent needs. No alternative tool competes for this purpose, so the constraint is complete.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that, the description adds nothing behavioral – no note on what happens with an unresolvable identifier, whether lookups are case-sensitive, or whether name collisions are possible, which matters for a name-or-UUID lookup.

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 short sentence with no wasted clauses, correctly front-loaded. However, it is effectively a restatement of the title, so it earns its place only marginally rather than adding new information.

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 one-parameter read tool with a full-coverage schema, an output schema (so return values need no explanation), and annotations covering the safety profile, the minimum needed to invoke it is present. The definition stops at minimum viability and omits any lookup-behavior nuances that would make it 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% and the single parameter's schema text ('The UUID, name or reply_id to query') is nearly identical to what the description states. With full coverage the baseline of 3 applies; the description adds no syntax, format, or precedence rules for choosing among the three identifier types.

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?

Tautological: description restates name/title.

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: an agent can infer it should call this after get_blueprints to drill into a single blueprint, since the description mentions reply_id 'from get_blueprints'. There is no explicit when-to-use statement and no when-not-to-use or error-handling guidance.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds one genuinely useful behavioral fact — paging hints appear in the response footer — which tells the agent how to iterate, but says nothing about scoping, rate limits, or result volume.

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?

Three short sentences, no padding, and the core action plus the paging instruction are front-loaded. The emoji consumes a little space but the text is otherwise tight.

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 cover the safety profile. Still, for a list tool with a search parameter and a sibling details tool, the definition omits when-not-to-use guidance and any scoping context.

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% with all three parameters documented, so the baseline is 3. The description references limit/offset but adds no format or range detail beyond the schema, and never mentions search_string.

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?

Tautological: description restates name/title.

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?

"Use limit/offset from the user" gives a concrete calling instruction, and the footer note implies iterative paging. But there is no guidance on when to list blueprints versus fetching a single blueprint's details, so usage context is only partially implied.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds only the identifier constraint; it says nothing about error behavior for an unknown/stale UUID or whether the compose must be finished before details are meaningful.

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 clauses, front-loaded with what the tool returns, then the identifier rule. No filler sentences, though the brevity means it is essentially the title restated rather than an expanded definition.

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 described, and annotations cover the read-only nature. For a one-parameter lookup the coverage is minimally adequate, but nothing explains failure modes or what "status & details" can include when the build is incomplete.

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 single parameter is documented as "The exact UUID string from get_composes()". The description reinforces that and adds the "not 'latest' alone" caveat, but supplies no format/syntax detail 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?

Tautological: description restates name/title.

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?

Provides a precondition (the UUID must come from get_composes()) and a negative constraint (do not pass "latest" alone), which is real routing guidance. It does not say when to call this versus get_composes or the other image-builder lookups, so usage is implied rather than fully specified.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact not in the schema: results are ordered 'newest first'. It does not mention pagination limits, rate limits, or auth needs, so it adds only modest value.

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 that wastes no words, though it is verbatim identical to the title (pure duplication) and the 'default 7, 0' phrasing is slightly compressed/awkward. Still appropriately sized for a simple list tool.

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 the read-only list behavior is straightforward. Ordering and scope are covered; only when-to-use/alternative routing is missing, which is a minor gap for a simple listing 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% and all three parameters (limit, offset, search_string) are documented in the schema. The description merely restates the limit/offset defaults already present in the schema and adds nothing about search_string 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?

Tautological: description restates name/title.

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?

It states defaults but offers no when-to-use guidance, no condition for choosing this over get_compose_details or get_blueprints, and no exclusions. The agent must infer usage from the verb alone.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and reach are covered. The description adds the aggregation rule (latest minor per major) and a negative scope constraint, which is genuine extra context, but says nothing about auth requirements or result volume/pagination.

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 the key scope constraint in parentheses and the exclusion tacked on cleanly; nothing is padded. It is essentially a restatement of the title, which slightly limits the value of the description text itself.

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-value detail is unnecessary, and a zero-parameter list tool needs little more than what is stated. The description is complete enough for correct invocation, though a note on how results relate to image building would fully close the loop.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and additionalProperties is false, so no parameter gap exists.

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?

Tautological: description restates name/title.

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 an implicit when-not signal ('No Fedora/CentOS Stream support'), which tells the agent this is RHEL-only, but no positive when-to-use guidance or named alternatives. Adequate but leaves the agent to infer the context of use.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no indication of spec size, auth requirements, or caching behavior for what can be a very large payload, which is the main practical concern for this tool.

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?

It is short, but the sentence is a near-verbatim copy of the title, including the decorative 🟢 emoji, and carries no front-loaded purpose statement. Brevity here reflects under-specification rather than efficient structure.

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, but the description still fails to say why an agent would fetch the OpenAPI spec or how it relates to the other image-builder tools. For a discovery/meta tool the missing 'use this to learn the endpoints' framing is a real 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 description coverage is 100%, so the single endpoints parameter is fully documented in the schema, including the exact format and the create/update condition. The description merely repeats the same example values, adding no meaning beyond structured data, which lands at the baseline 3.

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?

Tautological: description restates name/title.

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 phrase 'to shrink payload' hints at when the endpoints parameter is useful, but there is no guidance on when to call this tool at all versus siblings like image-builder__get_blueprints or get_blueprint_details. The more concrete 'Only needed for create_blueprint/update_blueprint' condition lives in the schema, not the 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds only the anti-fabrication warning and no behavioral context such as authentication requirements, whether the value is stable, or failure behavior.

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 resource and its purpose, with no padding. It is efficient, though one sentence is essentially a verbatim echo of the title.

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-value documentation is unnecessary, and with no parameters the surface is small. Still, the description never says when this lookup is needed or what the returned ID is used for downstream, leaving a real gap for a registration-related 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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate beyond its empty 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?

Tautological: description restates name/title.

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?

'Never invent org IDs' is a real usage directive that tells the agent to retrieve rather than fabricate the value, which is meaningfully better than nothing. It still doesn't contrast with any sibling or say when in a workflow this call is required (e.g., before registering a blueprint).

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?

Annotations already indicate readOnlyHint=true, so safety is clear. Description adds no behavioral details (e.g., case sensitivity, exact match, single result). With annotations covering the risk profile, this is acceptable but not enhanced.

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 verb+resource+method. No wasted words; efficient and clear.

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 simple lookup tool with an output schema, the description covers the essential purpose. Minor improvement could specify return granularity (single vs. list) but not necessary given output 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 description coverage is 100%, so the schema already documents the 'hostname' parameter well. The tool description adds no extra semantics or format guidance, earning the baseline 3.

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?

Description clearly states verb 'Find', resource 'a host', and method 'by hostname/display name'. It effectively distinguishes from sibling tools like inventory__list_hosts which do broader listing.

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: use when you have a hostname. No explicit when-not-to-use or alternatives are given, leaving the agent to infer from context. This is minimally adequate but lacks guidance compared to siblings.

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?

Annotations declare readOnlyHint=true, and the description is consistent (get operation). Description adds specific return fields, enhancing transparency. No mention of limits or errors, but the simple nature of the tool (1 param, output schema) makes this acceptable.

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?

Description is concise (2-3 sentences) with a clear purpose statement followed by a bullet-like list of return data categories. Every sentence adds value, no redundancy.

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?

Given the tool has one parameter, an output schema exists, and annotations declare readonly, the description covers all necessary context: what it does, what it returns, and how to call it. The agent has sufficient information to select and invoke the tool 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?

The sole parameter (host_ids) is described in the schema as 'Comma-separated list of host IDs (UUIDs) to retrieve.' The description adds context by listing the expected fields in the response, which helps the agent understand the value of using this tool. With 100% schema coverage, baseline is 3; additional context raises to 4.

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?

Description clearly states 'Get detailed information for specific hosts by their IDs' and lists the types of data returned (identifiers, network info, cloud provider, etc.). This distinguishes it from sibling tools like inventory__find_host_by_name (search by name) and inventory__list_hosts (list with filters).

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?

Description implicitly tells when to use (when you have host IDs and need comprehensive details). It does not explicitly mention when not to use or compare to alternatives, but the sibling names provide context. A clear usage scenario is evident.

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?

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context by warning about large response sizes and recommending input limits. No contradictions with annotations.

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?

The description is reasonably concise, with a clear first sentence followed by a bullet-like list of data included. It is front-loaded with the core purpose, though the list could be slightly tightened.

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?

Given the presence of an output schema and annotations, the description is fairly complete: it explains what data is returned, warns about response size, and provides input recommendations. It covers the essential context for a read-only data retrieval 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% for the single parameter 'host_ids', and its description already includes the key usage guidance. The tool description adds no additional parameter semantics 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?

The description clearly states the tool gets 'detailed system profile information for specific hosts' and enumerates specific data categories (CPU, memory, network, etc.), which precisely defines its scope and distinguishes it from simpler sibling tools like inventory__get_host_details.

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 input schema description provides a crucial usage guideline: 'ALWAYS supply one or two UUIDs at a time! Expect really large responses which will overload your context.' However, the main description lacks explicit guidance on when to use this tool versus alternatives or when not to use it.

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?

Annotations already declare readOnlyHint=true. The description is consistent but adds no additional behavioral context (e.g., permissions, error handling, or side effects).

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?

The description is a concise single sentence that immediately conveys the tool's purpose. No wasted words, but could be slightly expanded for clarity.

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 simple with one parameter and an output schema. The description is minimally adequate but does not explain the structure of returned tags or any non-obvious behavior.

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% with a clear parameter description. The tool description does not add any parameter-level 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?

The description clearly states the verb 'Get' and resource 'tags for specific hosts'. It is clear but does not differentiate from sibling tools like inventory__get_host_details or inventory__list_hosts.

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 provides no guidance on when to use this tool versus alternatives, nor any context about prerequisites or limitations.

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?

Annotations declare readOnlyHint=true, and the description aligns with that by stating 'Get details' and listing returned fields. The description adds value by disclosing the required permission ('inventory:groups:read (Workspace viewer)') and the exact return fields, which goes beyond the annotation. No contradiction.

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?

The description is concise and front-loaded. The first sentence states the core purpose, the second lists return fields, and the third gives permission and usage guidance. Every sentence earns its place with no redundancy.

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 description is complete for a read-only lookup tool. It covers purpose, input format, return fields, and permission requirements. The output schema exists, so return values are already structured. The only minor gap is not explicitly stating when to use this over inventory__list_workspaces, but the ID-based lookup is clear enough.

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 the schema already documents the parameter. The description adds meaning by explaining the comma-separated format and the preference for IDs over names, which is not in the schema. This compensates well for the single parameter.

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 clearly states the tool's function: 'Get details for one or more workspaces by ID.' It specifies the resource (workspaces), the action (get details), and the input method (by ID). It also lists the returned fields, which distinguishes it from sibling tools like inventory__list_workspaces.

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 when to use this tool: when you need details for specific workspaces by ID. It doesn't explicitly exclude alternatives, but the presence of sibling inventory__list_workspaces and the focus on ID-based lookup provides clear context. It also gives a practical guideline: 'Prefer IDs over names; names can be duplicated.'

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context by warning about performance degradation and context overflow with larger per_page values, which goes beyond the annotation and helps the agent make safer calls.

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?

The description is compact and front-loaded with the core purpose, followed by a high-priority usage warning. Every sentence earns its place, and the critical warning is clearly separated and emphasized without redundancy in the description (the schema also repeats it, but that does not hurt this dimension).

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 15 parameters but 100% schema coverage and an output schema present, the description covers the key non-obvious operational constraint (per_page). It is sufficient for correct invocation, though it could have briefly pointed to sibling tools for alternative list/find use cases to be fully complete in context.

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 the description does not need to re-document each parameter. It adds extra semantic value specifically for per_page by explaining the performance and context implications and the rule for changing the default, which is not present in the schema alone.

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 clearly states the verb and resource: 'List hosts with filtering and sorting options.' This is specific and unambiguous. However, it does not explicitly distinguish itself from sibling tools like inventory__find_host_by_name or inventory__list_workspace_hosts, so it misses the top score for sibling differentiation.

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 provides strong parameter-level usage guidance by mandating per_page=10 on the first call and restricting larger values to explicit user requests. However, it gives no guidance on when to choose this tool over alternative inventory tools such as find_host_by_name or list_workspace_hosts, so the 'vs alternatives' aspect is only implied by the purpose.

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?

Annotations already mark the operation as read-only. The description adds useful behavioral context by stating the required permission (inventory:hosts:read) and the prerequisite workflow of calling list_workspaces first. This goes beyond the annotation and helps the agent understand access and sequencing requirements.

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?

The description is compact and front-loaded with the core purpose, followed by the key prerequisite and permission. Every sentence contributes necessary information with no redundancy or filler.

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, full parameter descriptions, and a read-only annotation, the description covers the essential workflow and authorization details. It does not discuss when to prefer inventory__list_hosts over this tool, but the workspace-scoped purpose is sufficiently clear for correct invocation.

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 the baseline is 3. The description adds meaning for the required workspace_id parameter by explaining how to obtain it via list_workspaces, which is beyond the schema's simple 'Workspace ID (UUID)' definition.

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 opens with 'List hosts that belong to a workspace,' which is a specific verb, resource, and scope. This clearly differentiates the tool from the sibling inventory__list_hosts, which appears to cover hosts without the workspace constraint.

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?

It explicitly instructs to use list_workspaces first to obtain the workspace ID, giving a clear prerequisite and workflow. It does not explicitly state when not to use it or name alternatives, but the usage context is clear and actionable.

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 annotation already signals a safe read operation. The description adds value by specifying the required permission (inventory:groups:read), noting that names can be duplicated (so IDs are preferred), and specifying the returned fields. No contradictions with the annotation.

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?

The description contains six sentences, but each adds information: purpose, when to call, a warning, output fields, a best-practice note, and a permission requirement. It is front-loaded with the primary purpose and remains reasonably concise.

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?

Given the tool is a read-only list operation with all parameters optional and annotated as read-only, the description covers when to use it, permission, output structure, and potential pitfalls (duplicate names). It is complete for an agent to invoke it correctly without further investigation.

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?

The input schema already provides full descriptions for all 6 parameters (100% coverage), so the baseline for added value is 3. The description's note to prefer workspace IDs in later calls is general advice, not parameter-specific detail, so it doesn't elevate the score further.

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 opens with a precise verb and resource: 'List Inventory workspaces', and clarifies the naming ('console UI name for Inventory groups'). It also states the trigger condition ('Call this tool whenever the user asks to list, show, or get workspaces') which distinguishes it from more specific tools like inventory__get_workspace. The purpose is immediately understandable.

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?

Explicit usage guidance is given: 'Call this tool whenever the user asks to list, show, or get workspaces.' It also warns against inventing workspace names without calling the API and specifies a required permission. While it doesn't contrast with a single-workspace tool, the instruction is clear and actionable.

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?

Annotations already mark the tool read-only; the description adds meaningful behavioral context: the dashboard fetches data directly from the server and all filter parameters are optional. This goes beyond the schema and annotation without contradicting them, though it does not detail the output format or pagination behavior.

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?

The description is short, front-loaded with the core purpose, and every sentence earns its place. The preference rule, alternative usage, and key invocation note are presented cleanly without redundancy or filler.

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 13-parameter read-only dashboard tool with no output schema, the description covers purpose, selection criteria, data source, and parameter optionality. It could more explicitly describe what the returned dashboard or response looks like, but the guidance is otherwise sufficient for correct invocation.

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 the schema already documents all 13 parameters. The description adds only a general statement that all filter parameters are optional, which does not provide deeper per-parameter meaning beyond what the schema already contains.

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 uses specific verbs ('show, list, or display') tied to a concrete resource ('fleet inventory in an interactive dashboard'). It also names the sibling it is not (list_hosts), making the tool's distinct role clear.

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?

Explicitly states when to prefer this tool over list_hosts ('whenever the user wants to see, show, list, or display hosts or fleet inventory') and when to use the alternative ('only when you need the raw data for analysis or processing'). This is unambiguous guidance.

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?

Annotations already indicate read-only and idempotent behavior. The description adds substantial context: explains the return format, modes, and parameter roles. It also includes a 'CALL IMMEDIATELY' note, reinforcing the safe, non-destructive nature. No contradiction with annotations.

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?

The description is well-structured with sections and bullet points, making it easy to scan. However, it is somewhat lengthy; some details could be condensed while retaining clarity.

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?

Given the tool's complexity (6 parameters, multiple modes), the description is thorough. It covers usage context, parameter selection, and return structure comprehensively. The presence of an output schema does not undermine the description's completeness as it still adds interpretive value.

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%, but the description goes beyond by providing usage rules for each parameter (e.g., using 'application_stream_name' for human-friendly names, 'name' for technical names). This adds significant practical meaning.

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 title and description clearly state it retrieves Application Streams lifecycle information. It specifies the resource (Application Streams) and action (get lifecycle), but does not explicitly differentiate from sibling tools like planning__get_relevant_appstreams, leaving some ambiguity.

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 provides explicit when-to-use guidance ('Use this tool when the user asks about Application Streams lifecycle') and parameter selection advice. However, it lacks explicit when-not-to-use context or alternative tool references.

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 description adds context beyond annotations: explains that relevance is computed backend based on actual host data, no client-side filtering. This aligns with readOnlyHint and idempotentHint. No contradiction.

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?

Well-structured and front-loaded: starts with 'CALL IMMEDIATELY,' then usage scenarios, parameter instructions, and output schema. Every section serves a purpose; no wasted text.

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?

Given the tool's complexity (inventory-based relevance, lifecycle dates, sibling tool), the description fully covers purpose, usage, parameters, and output schema. No gaps remain.

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?

Despite 100% schema coverage, the description enriches parameter meaning: major/minor restrict relevance to specific RHEL versions, include_related distinguishes current usage vs. upgrade recommendations. Provides concrete guidance that the schema alone doesn't capture.

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 clearly states the tool retrieves relevant Application Streams from the user's inventory, including lifecycle/support dates. It distinguishes itself from the sibling tool `get_appstreams_lifecycle` by specifying it focuses on inventory relevance vs. an exhaustive catalog view.

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?

Provides explicit guidance: 'CALL IMMEDIATELY - No information gathering required,' example queries, when to use vs. lifecycle tool, and how to set parameters for scoping (major/minor) and include_related. Also explains when not to use (exhaustive catalog).

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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by explaining the return schema, parameter behaviors (e.g., related=true for include_related), and response guidance. No contradictions with annotations.

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?

The description is well-structured: purpose, call indicator, examples, parameter guidance, response guidance, and return schema. Every section adds value. Slightly long but justified by the tool's complexity.

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 description covers all essential aspects: purpose, when to use, parameter semantics, response structure, and response guidance. No significant gaps. Sibling differentiation is clear from the title and description.

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 descriptions cover all parameters at 100%, but the description enhances with practical usage guidance: how to scope with major/minor and the meaning of include_related with the related flag. This adds significant value 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?

The description clearly states the tool returns RHEL lifecycle information for systems in the requester's inventory. It uses specific verbs and resources, and distinguishes from sibling planning__get_rhel_lifecycle by focusing on inventory relevance. Examples further clarify the purpose.

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 provides explicit use cases with example questions and parameter guidance (e.g., setting major/minor, include_related). It does not explicitly name the alternative tool for general lifecycle questions, but the presence of sibling planning__get_rhel_lifecycle implies the distinction.

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?

Annotations already indicate read-only, idempotent, and open-world hints. The description adds value by detailing the return structure (meta and data fields) and explaining what a count of 0 means. No contradictions are present.

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?

The description is concise and well-structured: a short summary, a call-to-action, usage guidance, and a detailed output description. Every sentence adds value, and it is front-loaded with the most important information.

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?

Given the rich annotations and detailed output schema in the description, the description is complete. It covers purpose, usage, behavior, and return format without missing critical information.

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% (both parameters have descriptions). The description does not add any additional meaning to the parameters beyond what the schema already provides. Baseline of 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?

The description clearly states the tool's function: 'List relevant upcoming package changes, deprecations, additions and enhancements to user's systems.' It specifies the verb 'List' and the resource, and distinguishes from the sibling tool 'get_upcoming_changes' by indicating when to use this one.

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?

Explicit instructions are provided: 'Use this tool to answer questions about upcoming package changes...' and 'Use this tool over get_upcoming_changes when the user asks about upcoming changes for their systems.' It also includes a 'CALL IMMEDIATELY' directive. However, it doesn't cover when not to use the tool explicitly.

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?

Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint, which cover safety and idempotency. The description reinforces this with 'CALL IMMEDIATELY - No information gathering required' and details the return structure, adding context beyond the annotations. No contradictions.

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?

The description is somewhat lengthy but well-structured with headings, bullet points, and emojis. It front-loads the core purpose and call-to-action. Some redundancy exists, but overall it is easy to scan and interpret.

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?

Given no parameters and comprehensive annotations, the description covers all necessary context: what the tool returns, how to interpret results for different use cases, and that it is a safe read operation. The return structure is detailed in the description, making it fully self-contained.

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?

There are no parameters in the input schema, and schema coverage is 100%. The description does not need to add parameter semantics. Baseline score of 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?

The description clearly states it returns life cycle dates for all RHEL majors and minors, using a specific verb and resource. It distinguishes from sibling tools like planning__get_appstreams_lifecycle by focusing on RHEL, and the extensive usage guidance reinforces the purpose.

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 explicitly tells the agent when to use this tool (e.g., user asks for RHEL versions and lifecycle timelines) and provides step-by-step instructions for different query types (major-only, specific minor, date windows). It also says to call immediately with no information gathering, which is excellent guidance.

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?

Annotations already set readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral guidance like 'CALL IMMEDIATELY' and post-filtering instructions. No contradictions.

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?

The description is well-structured with an emoji for emphasis, a clear instruction line, usage note, and return format. Slightly lengthy due to return details, but still concise and 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?

Given no parameters, full annotations, and an output schema, the description is complete. It covers purpose, usage, and behavior. Minor missing detail on what 'upcoming' means, but not critical.

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?

There are zero parameters, and schema coverage is 100%. The description does not need to add parameter details. Baseline for no parameters is 4.

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 clearly states the tool lists upcoming package changes, deprecations, additions, and enhancements. It uses specific verbs and resources, and distinguishes from siblings by emphasizing that it provides a full list, with filtering instructions for specific versions.

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 explicitly says 'CALL IMMEDIATELY - No information gathering required' and instructs when to use it for full lists or specific RHEL versions. It does not explicitly mention when not to use, but the context is clear.

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?

Beyond the readOnlyHint annotation, the description discloses that only missing console role names are returned and adds an important authentication caveat: the principal is usually the MCP service account, not the console user. This is valuable behavioral context an agent would not otherwise know.

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?

Three short sentences, each earning its place: the action, the constrained output, and the auth-context caveat. The most important usage guidance is front-loaded before the auth note.

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 description is complete for a diagnostic tool with a rich output schema and fully documented parameters. It covers when to use it, what it returns, and a crucial identity caveat; nothing essential is missing for an agent to invoke it 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 description coverage is 100%, so the input schema already documents all four parameters well. The description does not add parameter-level detail beyond the schema, which is acceptable given the high coverage baseline.

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 clearly states the tool's job: diagnosing a 403 access denial for a specific MCP tool call and returning missing console role names. It does not explicitly name or distinguish sibling tools like rbac__lookup_tool_requirements or rbac__get_caller_access, so it stops short of full sibling differentiation.

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 gives clear context for use: when a 403 occurs on a specific tool call, use this instead of guessing role or permission names. It does not explicitly contrast with sibling RBAC tools, but it provides actionable guidance about when the tool is appropriate.

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 annotation already signals a safe read operation. The description adds meaningful context beyond that by clarifying the identity used is the MCP server's service account or Bearer token, not necessarily the human user. This is genuinely useful behavioral context for interpreting results.

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 carry the essential purpose and the critical identity caveat without any wasted words. The main action is front-loaded and the caveat is placed immediately after.

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 simple read-only tool with a full parameter schema and an output schema, the description covers the necessary behavioral context: what it returns, for whom, and that it is scoped to one application. Nothing essential is missing.

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 the schema fully documents all four parameters. The description adds minimal parameter-specific meaning beyond reinforcing that the application parameter is in scope, which is sufficient given the complete schema coverage.

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 names a specific verb ('Get'), a specific resource ('RBAC access'), a specific subject ('authenticated caller'), and a scope ('one application'). It also distinguishes itself from the sibling rbac__get_caller_access_all by explicitly limiting to a single application.

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 clearly states the tool is for retrieving access for one application, which implies use cases where a single application scope is needed. It does not explicitly name alternatives or exclusions, but the 'one application' scoping provides clear contextual guidance against the 'all' sibling.

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 annotation already signals a safe read operation, and the description adds meaningful behavioral details beyond that: the paginated nature of the fetch and the crucial identity-scoping caveat about MCP's service account versus the console user. This adds real context that annotations do not provide, with no contradiction.

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 succinct sentences with no wasted words. The core function—'List all RBAC permissions for the authenticated MCP caller'—is front-loaded, and the second sentence earns its place by clarifying a non-obvious identity nuance that could otherwise cause misuse.

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, single optional-parameter tool with an output schema and a readOnlyHint annotation, the description covers all the essential context an agent needs: what is listed, pagination, and the identity boundary. Nothing critical is missing for a successful call.

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 single 'username parameter is already fully described in the input schema, including its default value and admin requirement. The description does not add additional parameter-level meaning beyond the schema, so the baseline of 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?

The description states a specific verb ('List'), a precise resource ('all RBAC permissions'), and a clear scope ('for the authenticated MCP caller'). The parenthetical '(paginated fetch)' further distinguishes it from any simple or non-paginated listing variant, and the wording makes it easy to tell apart from sibling tools like rbac__get_caller_access.

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 gives important context about which identity permissions apply to, clarifying that results apply to the MCP service account or Bearer identity, not the console user. However, it does not explicitly state when to choose this tool over the similar sibling rbac__get_caller_access or mention any alternative alternatives, leaving the tool-selection decision mostly implicit.

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 annotation already signals safety, and the description adds important behavioral context by stating that this tool reports required roles without checking the authenticated caller's access. This clarifies a likely source of confusion with RBAC tools and augments what the annotations alone convey.

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?

The description is two crisp sentences with no filler. The first sentence states the purpose, and the second adds the key behavioral distinction and the routing to the alternative tool. Every sentence 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?

For a single-parameter, read-only lookup tool with an output schema available, this description is complete. It explains what the tool returns, what it does not do, and how it relates to the relevant sibling tool, so an agent has enough information to invoke it 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?

The schema already provides 100% coverage for the single parameter, including a descriptive example ('inventory__find_host_by_name'). The description does not need to add parameter detail, and the baseline of 3 is appropriate since the schema carries the semantic weight.

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 states a specific verb ('Return') and a specific resource ('console role names required for an MCP tool'), making the tool's function immediately clear. It also distinguishes itself from the sibling rbac__explain_access_denied by explicitly noting it does not check the caller's current access.

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 gives clear context for when to use this tool: when you need required roles rather than current access evaluation. It explicitly names the alternative tool to use after a 403 response, leaving no ambiguity about the appropriate choice between these related RBAC tools.

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?

Annotations already indicate readOnlyHint=true, so the description's behavioral claim is consistent. It adds no new behavioral traits (e.g., rate limits, auth) beyond the expected read operation, but is adequate.

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?

The description is mostly concise but contains slight redundancy (the 'Returns' section summarizes information already in the preceding sentence). The emoji and call-to-action are helpful but add token count.

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?

Given the presence of an output schema (which documents return values), the description sufficiently covers what the tool does and what details are returned. It is complete for a simple retrieval 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?

The input schema already describes the 'name' parameter with a clear description ('The name of the activation key to retrieve'). With 100% schema coverage, the description adds no new meaning, placing it at baseline 3.

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 clearly states it retrieves a specific activation key by name, using a strong verb ('Get') and specifying the resource. It differentiates from the sibling 'rhsm__get_activation_keys' which lists all keys.

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 includes 'CALL IMMEDIATELY - No information gathering required,' indicating no prerequisites. It implies usage when you have a key name, but does not explicitly mention the alternative list endpoint when the name is unknown.

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?

Annotations already declare readOnlyHint=true, so the description adds value with the 'CALL IMMEDIATELY' behavioral cue. It explains the purpose of activation keys for RHEL registration, which supplements the annotation without contradiction.

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?

The description is relatively concise with a clear opening, a call-to-action flag, and a brief explanation. It could be slightly more concise, but overall well-structured and 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?

Given the low complexity, full schema coverage, presence of annotations, and existence of an output schema, the description provides all necessary context: what the tool does, when to call, and what it returns (list of activation keys with details).

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?

The input schema has 100% description coverage for both parameters (limit, offset) with defaults and descriptions. The description does not add any additional parameter semantics beyond what is already in the schema, so baseline score 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 states 'Get the list of activation keys available to the authenticated user,' which clearly specifies the action (get) and resource (activation keys). It distinguishes from sibling tools like 'rhsm__get_activation_key' (singular) by indicating it returns a list.

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?

Includes a 'CALL IMMEDIATELY - No information gathering required' flag, guiding the agent to invoke without prior steps. However, it does not explicitly mention alternative tools for getting a single key or when not to use this 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?

Annotations already indicate readOnlyHint=true. The description adds context about using VMAAS and explains the meaning of 'affected_packages', enhancing transparency beyond the annotation's simple read hint.

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?

The description is somewhat repetitive ('Explain why CVEs...' appears twice) and could be more concise. However, it is front-loaded with the main purpose and structured coherently.

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?

Given the presence of an output schema, the description sufficiently covers what the tool does, required inputs, and even suggests a next step (Remediations). It provides complete context for a tool explaining CVEs per system.

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% with examples for both parameters. The description adds context about needing system UUID from inventory and CVEs, but this doesn't significantly augment the semantic meaning already provided by 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?

The description clearly states the tool explains why CVEs affect the environment, detailing affected packages and fix info. It uses specific verbs like 'explain' and references VMAAS, distinguishing it from sibling tools that list CVEs or systems.

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 mentions prerequisites (system UUID and CVEs) and suggests using the Remediations tool for updates. However, it does not explicitly specify when to use this tool versus alternatives like vulnerability__get_cve_systems or vulnerability__get_cves.

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?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful context beyond annotations by listing the specific metadata returned (CVSS scores, severity, advisories, known exploits, etc.), which helps the agent understand the tool's behavior without contradiction.

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?

The description is concise (4 sentences) and front-loaded with the main purpose. It clearly lists the metadata items but has some redundancy (e.g., 'description' mentioned twice). Overall efficient with minimal waste.

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?

Given the presence of an output schema (as per context signals) and comprehensive annotations, the description covers the tool's purpose, key parameters, and returned data fields adequately. It references the OpenAPI spec for more details. No major gaps for a read-only 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?

Input schema coverage is 100% and both parameters are well-described in the schema (cve with example, advisory_available with boolean string interpretation). The description does not add any new semantic meaning beyond what the schema already provides, so a baseline score of 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?

The description clearly states the tool's purpose: 'Get details about specific CVE.' It lists the specific metadata returned, distinguishing it from sibling tools like vulnerability__get_cves which likely lists CVEs. The verb 'Get' combined with 'details' precisely defines the action and resource.

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 use when needing detailed CVE information, but does not explicitly state when to use this tool versus alternatives like vulnerability__get_cves or vulnerability__get_cve_systems. No when-not or alternative guidance is provided.

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?

Annotations already provide readOnlyHint=true, so the description's disclosure of returning 'CVE metadata, how many systems are affected by each CVE, and more' adds some output context but no significant new behavioral traits (e.g., pagination limits, authorization). The description does not contradict annotations, and the disclosure is adequate but minimal.

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?

The description is three sentences, which is moderately concise. The second sentence ('This provides an overview...') largely restates the first sentence, adding redundancy. The third sentence refers to an OpenAPI spec, which is a weak crutch. It could be condensed to one or two sentences without losing meaning.

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?

Given the tool has 11 optional parameters with many filters, the description is quite generic. It states it's an overview but doesn't hint at the extensive filtering, sorting, or pagination capabilities (though schema descriptions exist). An agent might underestimate the tool's flexibility. The description is minimally complete for a basic understanding but not comprehensive.

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 high (91%), so the baseline is 3. The description adds no parameter-level details beyond what the schema provides. It mentions 'CVE metadata' and 'systems affected' but does not explain how to use filters like cvss_from, impact, or known_exploit. The description does not compensate for the one undocumented parameter (filter_).

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 clearly states 'Get list of CVEs affecting the account' with a specific verb and resource. It indicates an overview of vulnerabilities across the entire system inventory, which distinguishes it from sibling tools like vulnerability__get_cve (single CVE details) and vulnerability__get_cve_systems (systems per CVE). However, it does not explicitly differentiate from siblings, so it's not 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 says 'Use this endpoint to get an overview' but provides no guidance on when not to use it or alternatives. Given siblings like vulnerability__get_cve and vulnerability__get_cve_systems, the lack of explicit exclusions or comparisons leaves an agent without clear decision criteria.

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?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds minimal behavioral context (it's a 'report'), but does not disclose pagination behavior or output format beyond what annotations and 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?

The description is short (three lines) but has slight redundancy between the first two sentences. It conveys the core purpose efficiently without unnecessary details.

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?

Given the tool's simplicity, an output schema exists, and parameters are fully described in the schema, the description is sufficient. It does not explain return values, but the output schema fills that 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 description coverage is 100%, so the schema already documents all parameters. The description does not add additional meaning beyond stating the overall purpose, so baseline score of 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?

The description clearly states the verb ('Get'), the resource ('list of systems'), and the constraint ('affected by a given CVE'). This distinguishes it from sibling tools like vulnerability__get_systems which lists all systems without a CVE filter.

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 explicitly says 'Use this tool to obtain list of all affected systems for a given CVE.' This provides clear context for when to use the tool, though it does not explicitly mention alternatives or when not to use it.

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 annotation already indicates a safe read operation. The description adds no extra behavioral details such as rate limits, authentication, or response size. It confirms JSON format but goes no further.

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?

The description is a single sentence of 10 words with no fluff. It is front-loaded and 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?

Given no parameters, an output schema exists (though not provided), and the tool is a simple OpenAPI spec retrieval, the description is complete enough. It tells the user exactly what to expect.

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?

There are no parameters, so the description need not add parameter meaning. The schema coverage is 100% trivially. The baseline for 0 parameters is 4, and the description meets it.

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 clearly states the verb 'Get', the resource 'Red Hat Insights Vulnerability OpenAPI specification', and the format 'JSON'. It distinguishes the tool from sibling tools like image-builder__get_openapi by specifying the service.

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 provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or when not to use it. For a simple tool, some context could be added.

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?

Annotations already declare `readOnlyHint: true`, so the tool is known to be read-only. The description adds no new behavioral traits (e.g., no mention of pagination details, performance, or side effects) but does not contradict annotations.

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?

The description is concise with 6 sentences, but includes some redundancy (e.g., 'This is a report...' restates the first sentence) and a mention to refer to the OpenAPI spec, which is of limited value. Still, it is front-loaded with the key guidance.

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?

Given the existence of an output schema, the description covers the tool's purpose, usage, and distinguishing guidance. No critical gaps are present for a read-only list endpoint with well-documented parameters.

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% with all parameters described in the input schema. The description does not add meaning beyond what the schema provides, so 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?

The description states 'Get list of CVEs affecting a given system', which clearly identifies the verb and resource. It differentiates from siblings by noting that `get_cves` is preferred for filtered results, but the core purpose is unambiguous.

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 explicitly states 'IMPORTANT: Prefer `get_cves` as `get_cves` can filter for CVEs with available advisories.' This provides clear when-to-use and when-not-to-use guidance, naming an alternative 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?

The annotations already indicate readOnlyHint=true, so the description doesn't need to restate. It adds that both affected and not affected systems are returned, and lists returned fields. However, it does not disclose pagination behavior, rate limits, or sorting default beyond what the schema provides.

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?

The description is two sentences plus a note about the OpenAPI spec. It is front-loaded with the core purpose and conveys key information without redundancy.

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?

Given the 6 parameters (all optional with descriptions), an existing output schema, and no nested objects, the description sufficiently covers the tool's behavior. It mentions the returned fields and the scope (both affected and not affected), providing a complete picture for a list endpoint.

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?

The input schema has 100% description coverage, so the baseline is 3. The description does not add meaning beyond the schema; it mentions response fields (last check-in, etc.) but not input parameters. No additional value for parameter semantics.

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?

Description clearly states it retrieves a list of systems from the Vulnerability inventory, including specific fields like last check-in, system name, workspace name, RHEL version, and CVE count. It distinguishes from siblings like vulnerability__get_cve_systems by noting it returns both affected and not affected systems, but could be more 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?

No guidance provided on when to use this tool versus alternatives (e.g., vulnerability__get_cve_systems, vulnerability__get_system_cves). The description only states what it does, not the context or 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?

The description adds context beyond the readOnlyHint annotation by specifying it is an interactive dashboard that fetches data directly from the server, with no write behavior implied. No contradictions.

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?

The description is structured with a clear purpose statement, usage guidelines, and technical details. It is slightly redundant with schema but overall concise and well-organized.

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 description adequately explains input and behavior but does not mention return format or output details, which would be helpful given no output schema. The dashboard concept implies a list of CVEs but is not explicit.

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 parameters are already well-documented. The description adds no new semantic information beyond restating system_uuid behavior, which is already in 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?

The description clearly states the tool shows, lists, or displays CVEs in an interactive dashboard, at account or system level. It explicitly distinguishes from sibling tools get_cves and get_system_cves by indicating this tool is for display and those are for raw data.

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 explicitly says to prefer this tool over get_cves and get_system_cves for displaying CVEs, and to use those only when raw data is needed. It also explains behavior based on system_uuid parameter.

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